00:33 riteo: all right, status update: I think that it's just sway/wlroots downscaling stuff fractionally differently than the compositor's cursor
00:33 riteo: foot doesn't have this problem on my HEAD build exactly because it uses the pointer manager protocol
00:34 riteo: damn, I should really recover my freedesktop gitlab account
00:40 kchibisov: riteo: I think this bug in sway is rather old, and it's probably just a sway issue.
00:41 kchibisov: it always had issues with cursor scaling.
01:31 rayrapetyan: is there any documented or undocumented way to simulate mouse movements and key presses without creating a virtual input device (/dev/input) in wayland? Something similar to XTestFakeKeyEvent.
01:34 Max1: rayrapetyan https://gitlab.freedesktop.org/libinput/libei might be helpful if your compositor implements the server side
01:51 rayrapetyan: Thanks Max1!
02:38 wlb: wayland-protocols Merge request !264 opened by Matthias Klumpp (mak) staging: Add xdg-placement protocol for window positioning in "workspaces" (second version) https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
02:46 wlb: wayland-protocols Merge request !249 closed (Draft: Add xdg-alignment protocol for window-placement control)
09:12 Company: just been reading through the drm-syncobj MR and wondered:
09:12 Company: What happens if I attach a new buffer but don't set new acquire/release points?
09:16 Company: pq, swick[m]: I cam across https://front-end.social/@leaverou/111491942156530717 today, things in css land seem to be heating up about that - no idea if you're aware of that
09:37 MrCooper: Company: I'm arguing we shouldn't allow attaching a buffer to an explicit sync surface without acquire & release points
09:38 MrCooper: if we do allow it, it means no synchronization
09:38 Company: I've been wondering that about all those recent wayland protocols anyway
09:39 Company: each of those protocols add 1 or 2 things that influence how all the other things work
09:39 Company: and then in the end it gets real confusing if one of those protocols isn't selected
09:39 Company: the buffer placement stuff with viewport and fractional-scaling and whatnot has similar confusion
09:41 MrCooper: this isn't quite the same though, explicit sync has to be enabled for the surface in the first place, or the sync points can't be set anyway
09:41 Company: yeah
09:42 Company: but once it is enabled, you shouldn't use it without
09:42 emersion: i still think the release point should be optional
09:42 MrCooper: yep, I'm arguing that should be a protocol error
09:42 Company: like, I'm not sure if enabling explicit sync and then using wl_buffer.release is a good idea
09:42 Company: or not setting sync points
09:43 emersion: maybe the buffer is already ready
09:43 emersion: for acquire
09:43 MrCooper: emersion: the client is free not to wait for it to signal
09:43 emersion: but why the artificial restriction?
09:43 MrCooper: because it's required in the common case
09:43 emersion: why force clients to allocate and manage an extra useless timeline?
09:44 emersion: especially if it's not more work for the compositor
09:44 MrCooper: the protocol should be designed for the common case, not for special cases
09:44 emersion: it's not a special case
09:45 MrCooper: seriously?
09:45 Company: emersion: what does it mean if there's no release point?
09:45 Company: emersion: that the client says "I'm gonna reuse the buffer right now while it's still attached"?
09:45 emersion: it means the client uses the regular release events
09:45 emersion: no
09:46 Company: oh hm
09:46 MrCooper: it means no synchronization takes place on release
09:46 Company: yeah, that's what I think is a bad idea
09:46 Company: when you start to mix and match, you end up with too many combinations nobody thought about
09:47 emersion: the combination needs to work either way
09:47 emersion: release isn't going away from core wl
09:47 emersion: and i think most clients won't care about the fenced release anyways
09:47 Company: you could say "once an explicit sync is created, buffers attached to here are not going to emit release events"
09:47 emersion: they have a swapchain, they want to know when it's safe to re-use
09:48 MrCooper: emersion: you're saying most clients won't care about corruption artifacts?
09:48 emersion: that is not the case
09:49 MrCooper: what do you think the release points are for then?
09:50 MrCooper: if the client starts drawing the next frame before the compositor has finished reading from the buffer, you get artifacts
09:52 emersion: it seems there is a misunderstanding here
09:54 Company: emersion wants to use wl_buffer.release() instead of the release point
09:54 Company: right?
09:54 emersion: the compositor sends core release when it's finished operating on the buffer
09:55 emersion: (doing other things now, brb)
09:59 Company: MrCooper: I was reading through your comment on https://gitlab.com/qemu-project/qemu/-/issues/1973 and was wondering how you'd design such an API
10:00 MrCooper: the release event doesn't mean the GPU has finished reading from the buffer, that's what the release point is for (or implicit sync handles it magically)
10:00 Company: Would you treat buffers as pre-created object like in Wayland and essentially establish a pool?
10:00 Company: Or would you just send dmabuf fds?
10:01 MrCooper: haven't really thought about that
10:01 Company: I've been very interested in how those things are handled across graphics APIs recently
10:02 Company: because I'm wondering if GTK should have a bufferpool abstraction
10:02 MrCooper: my point is mainly that there needs to be explicit ownership transfer
10:02 Company: yeah, that one is obvious
10:02 Company: you need acquire/release
10:06 Company: the Vulkan and Wayland model do buffer pooling - Vulkan does it internally inside the swapchain, Wayland makes the client create/destroy wl_buffers as needed and also allows mixing and matching those buffers between surfaces
10:08 Company: GStreamer has explicit GstBufferPool objects
10:10 Company: which kinda work like Vulkan swapchains, if you look at Vulkan as the consumer and not Wayland (and the application as producer)
10:12 Company: I didn't look too dep into pipewire, but I think pipewire has some pool-like concepts for producers (ie the screencast portal), but not for consumers
10:14 Company: and GPUs have been using timeline semaphores recently to do the acquire/release thing
10:14 Company: and now it's coming to Wayland
10:15 Company: but I have no idea how far this should go - like, should GTK, GStreamer, pipewire, etc all switch to that? Why/Why not?
11:04 staceee: hello o/ what should I marshal send to the compositor if an argument is null? example here: get_layer_shell *output
11:04 staceee: I tried u32 0
11:35 staceee: an empty array of course!
11:35 MrCooper: Company: to me the Wayland (& X Present) model seems the most flexible, I guess I'm biased though :)
11:36 Company: we're all biased
11:36 MrCooper: Company: you mean why should GTK, GStreamer, pipewire etc. switch to explicit sync? The biggest incentive right now is probably to avoid glitches with the nvidia driver (without doing synchronous CPU waits)
11:38 Company: so you're saying we let the VM allocate buffers, register them with the host (and allow the host to reject them), and then the buffers can be set as the current contents
11:38 Company: and the host releases them when done
11:38 MrCooper: yeah
11:39 Company: that's slightly different from Vulkan and GL
11:39 Company: because Vulkan and GL do not let the client manage the unused buffers
11:40 Company: Vulkan and GL also do the allocation and just let the client set a min/max amount of buffers
11:41 Company: MrCooper: as for the timelines, I wasn't as much thinking about explicit vs implicit sync (to me that's just a question of how attach/release is implemented), but about using timeline syncobjs in particular
11:42 Company: or drm_syncobjs or whatever that fd thing is called
11:44 MrCooper: that's required for some Vulkan use cases involving presentation before submitting the corresponding GPU work; might not be strictly required for other APIs, but if you do explicit sync anyway, might want to keep the option available
11:44 Company: how do drm_syncobjs relate to dmabuf sync files?
11:45 Company: are they different things?
11:45 MrCooper: explicit sync which requires the GPU work to be flushed first doesn't buy any fundamental benefit over implicit sync
11:46 MrCooper: yep, different primitives
11:47 MrCooper: in a nutshell, a sync file represents a single concrete fence, a timeline syncobj a sequence of (possibly future) fences
11:48 Company: so there will be a question about attaching drm_syncobjs to dmabufs
11:48 Company: in some form
11:49 Company: because if Boxes gets a buffer from the VM, we want it to come with a syncobj
11:49 Company: so that we can pass it right through to the compositor
11:50 MrCooper: specifically acquire and release points on the timeline, yeah
11:50 Company: yeah, I guess that's a separate thing and not really part of the dmabuf
11:51 MrCooper: not really
11:51 MrCooper: the acquire & release points are what define the transfers of GPU ownership
11:53 Company: I'm thinking about ownership transfers between VM, Boxes/GTK and host compositor here
11:53 MrCooper: the consumer's GPU work must not read from the buffer before the acquire point has signaled, and the producer's GPU work must not write to it again before the release point has signaled
11:54 Company: though technically it's application in VM, VM compositor, CM kernel, Boxes, host compositor and host kernel
11:54 Company: *VM kernel
11:55 Company: if you run a maximized app in a maximized Boxes VM, that should give you direct scanout on the host - but you need to pass the acquire/release steps through all those subsystems
11:56 Company: ideally you want to pass through the acquire/release points everywhere
11:56 Company: but that requires you to have previously setup the syncobj fd
11:58 Company: and attach it to some object - on Wayland that's the wp_linux_drm_syncobj_surface_v1 but that needs an equivalent in the qemu API
11:59 MrCooper: yep
11:59 MrCooper:→ lunch, bbl
11:59 Company: GTK's graphics offload doesn't have that either
12:01 MrCooper: technically it's not required with Wayland, it's just that nvidia doesn't handle implicit sync, so you get glitches with that combination
12:02 Company: the biggest thing with GTK's API is that we have a wrapper object around the buffer that we keep alive while the buffer is in use
12:03 Company: which means we use wl_buffer.release() to confirm that we're done with the buffer and only would pass that info onwards
12:05 Company: because our buffer objects are read-only (unlike wl_buffer), so that API works different
12:57 pq: Company, I had't seen that, thanks. That gamut clipping things reminds me of the gamut parameters in HDR static metadata; no(?) computer monitors make use of them, so games can put garbage there.
14:15 emersion: MrCooper: so my understanding was that implicit sync was disabled when the protocol is used, so core release would be sent when the release point is signalled
14:16 emersion: and so the release point would just be an optimisation
14:17 emersion: but yeah, reading the protocol again nothing is really said about core release
14:18 emersion: so we'd have to pick an option (undefined, never sent, sent on release point signalling) and specify that
14:34 jadahl: can't core release be left to what it is, i.e. when the compositor itself is done with it, just that it doesn't mean anything about the DMA buf resource backing it, i.e. unreliable when explicit sync is needed
14:36 emersion: so a compositor sending release immediately would be correct?
14:36 emersion: same as undefined from my PoV
14:40 MrCooper: to me it's always been clear that it's as jadahl describes, explicit sync is for the same thing as implicit sync, it doesn't directly affect the release event
14:41 MrCooper: which means the release point is required for correct explicit synchronization in the common use case
14:42 emersion: wl_buffer.release relies on implicit sync for DMA-BUFs, the extension explicitly disables implicit sync, so wl_buffer.release is impacted either way
14:44 MrCooper: wl_buffer.release relies on separate GPU synchronization, which can be implicit or explicit
14:46 MrCooper: note that a client using the syncobj protocol doesn't have to listen to release events at all, it can just wait for the release points to signal
14:47 emersion: my point is that wl_buffer.release is meaningless when used with explicit sync, if it's not sent on point release
14:47 emersion: meaningless as in, the compositor can send it anytime, it doesn't change anything for the client
14:48 MrCooper: that is true and basically the same with implicit sync, the only constraint being it cannot be sent before flushing the last GPU work reading from it
14:49 emersion: that's very different from implicit sync
14:49 MrCooper: for similar reasons, a compositor which sends out the release event before a fence has materialized for all release points would be kind of mean
14:50 emersion: why?
14:50 MrCooper: emersion: I'm afraid you're making some assumptions which aren't universally shared, nor written down AFAIK
14:50 emersion: i'm afraid nothing is written down at this point, your assumptions aren't either
14:50 MrCooper: emersion: because it could result in the client submitting GPU work which then has to wait indefinitely for a release point to signal
14:51 jadahl: I think what makes most sense is to define 'release' as either undefined or "when the compositor is done" (a.k.a. what it does now), so that compositors don't need to special case .release when the explicit sync extension is in use
14:51 emersion: "when the compositor is done" is meaningless
14:51 emersion: maybe the compositor passes on the unmaterialised syncobj from a parent compositor
14:51 jadahl: pretty meaningless, true, but I'd like to avoid having to special case it
14:52 MrCooper: I propose "not before a fence has materialized for all release points"
14:52 emersion: no
14:52 MrCooper: yes, I do
14:53 emersion: wait-before-signal is a major reason why we're using drm_syncobj here
14:53 emersion: you're just removing half of the protocol's reason for existing here
14:53 MrCooper: this doesn't prevent wait-before-signal
14:53 emersion: this is the worst of both worlds
14:54 emersion: compositors now need to CPU-wait to send wl_buffer.release, but clients can't really use that in any meaningful way
14:54 MrCooper: if we can't require that, clients have to wait for fences to materialize, and the release event is useless with explicit sync
14:56 emersion: why would clients need to wait for fences to materialize?
14:56 emersion: as opposed to either waiting for the fence to complete, or just using the syncobj as-is
15:07 wlb: weston Merge request !1410 opened by Loïc Molinari (molinari) gl-renderer: Async output capture support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1410
15:21 wlb: weston/main: Arnaud Vrac * gl-renderer: do not use glTexImage3D directly https://gitlab.freedesktop.org/wayland/weston/commit/9c637d70ebea libweston/renderer-gl/ gl-renderer-internal.h gl-renderer.c gl-shader-config-color-transformation.c
15:21 wlb: weston Merge request !1395 merged \o/ (gl-renderer: do not use glTexImage3D directly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1395)
15:44 riteo: kchibisov: I see, thanks for letting me know. So wlroots is probably fine?
15:44 kchibisov: riteo: yeah, pretty much.
15:44 riteo: great
15:45 kchibisov: I remember sway has like a dozen issues around cursor scaling, and some more around fractional scaling.
15:46 kchibisov: So if you use fractional scaler, and you never see an event comming for the surface you've created a manager in WAYLAND_DEBUG logs, it's not your issue.
15:46 kchibisov: Assuming you actually did `set_cursor` call, since you still must commit cursor to actually get event.
15:49 zamundaaa[m]: MrCooper: I don't think the release event being useless with explicit sync is a problem. Why would you need it?
15:50 zamundaaa[m]: If a client wants to know when the buffer is available to use on the CPU side, it can just wait on the release point being signalled, instead of waiting for the release event
15:52 zamundaaa[m]: Which also avoids the release event's race condition with the case where a buffer is used on multiple surfaces
16:51 MrCooper: emersion zamundaaa[m]: waiting for the fence to complete first means less CPU & GPU concurrency than possible; using the syncobj as-is means the GPU work may be delayed longer than necessary (if there's another buffer available which doesn't have outstanding GPU work or at least has a fence for it)
16:53 zamundaaa[m]: Sure, there's tradeoffs. Tradeoffs that the client can make just fine without retroactively changing what the release event means
16:53 MrCooper: the client can avoid both by waiting for a fence to materialize, but then the release event is useless
16:53 zamundaaa[m]: Yes. Where's the problem?
16:54 MrCooper: it's a performance trap for clients which needs to be clearly documented at least
16:55 MrCooper: unless you want to see Phoronix benchmarks showing that explicit sync is slower than implicit ;)
16:55 zamundaaa[m]: It would be exactly the same if the client uses the release event. Documenting that the time at which the buffer gets released is up to the compositor implementation and not predictable would certainly be good though
16:56 zamundaaa[m]: Oh, I see what you mean now
16:56 MrCooper: zamundaaa[m]: if the release event was specified to be sent only once there are fences for all release points, the client could rely on that instead of waiting for fences to materialize itself
16:57 emersion: i don't understand
16:58 emersion: clients can easily wait for the fence to materialize if that's good for their use-case
16:58 emersion: with the timeline point
16:58 zamundaaa[m]: emersion: When the client receives the release event, it can safely use the buffer for submitting graphics work, with the release point being used as a semaphore before the GPU can actually start accessing the buffer
16:58 emersion: no need to force compositors to do weird stuff with wl_buffer.release
16:58 MrCooper: I agree it's not hard for clients to do the right thing, they just need to know to avoid the trap
16:58 zamundaaa[m]: Without running into the risk that the compositor will still hold the buffer for a few more frames
17:00 MrCooper: *traps
17:00 zamundaaa[m]: Iow, if a compositor would release the buffer a long time before it signals the release point, the client would get stalled unnecessarily. Fixing that doesn't necessarily require a hard definition of when the release event must be sent, but the protocol should mention that the compositor needs to take care with this
17:02 zamundaaa[m]: Otoh, it's the exact same situation as we have now. If the compositor releases a buffer just after submitting a lot of graphics work in advance, implicit sync might slow down the client
17:03 MrCooper: I don't see what purpose the release event would serve though (other than being something that could make things go wrong), if the client has to wait for fences to materialize anyway
17:05 MrCooper: zamundaaa[m]: true, so explicit sync gives the client the means to do better than implicit in this respect, by preferring buffers with no outstanding GPU work
17:06 zamundaaa[m]: yeah
17:07 MrCooper: I guess in principle that could be done with implicit sync by polling a dma-buf fd
18:49 riteo: kchibisov: btw the cursor was indeed mapped but I asked the request _before_ setting its surface as such
18:49 riteo: anyways that's a non-problem as I don't plan to reload the cursor theme "fractionally", instead letting the compositor downscale it for me from a higher scale one.
18:50 kchibisov: Then you don't even need fsr if you want to do so.
18:50 riteo: indeed
18:50 riteo: I thought I had to do some weird thing to let it scale properly but it's just a bug as you said
18:51 kchibisov: sway can't downscale cursor with fractional scaling eithir.
18:51 kchibisov: unless it was fixed, but last time I checked it was still an issue.
18:51 riteo: it looks like the issue's still there with HEAD
18:52 kchibisov: https://github.com/swaywm/sway/issues/5202
18:53 kchibisov: there's also https://github.com/swaywm/sway/issues/5203
18:53 riteo: mh I see
18:53 riteo: I wouldn't mind giving a help if needed
18:54 riteo: I've never worked with this stuff though, so I don't know if that'd be excessively hard
18:54 riteo: anyways, thanks for the clarification!
18:55 kchibisov: You can ask in #wlroots on irc.libera.chat, but right now sway is pretty bad target to test fractional scaling.
18:56 kchibisov: https://github.com/swaywm/sway/issues/7463 like this thing is a bigger problem.
19:00 riteo: mhh, I understand
19:00 riteo: I thought that this was wlroot's responsibility, why's sway managing it?
19:00 kchibisov: I was told that it's sway bug.
19:01 emersion: there's a lot of legacy in sway
19:01 emersion: hopefully scene-graph conversion will help
19:02 riteo: I already tried that PR (funnily, I already had it but I switched back to be sure)
19:02 riteo: doesn't fix the weird cursor size inconsistency
19:02 riteo: sadly
19:02 kchibisov: The only way to deal with legacy is to `rm -rf` it.
19:02 riteo: indeed
19:03 kchibisov: sadly noone has resources to do such things.
19:03 riteo: oh look at that, the MR linked by emersion indeed confirms that the cursor doesn't send frac scale events: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4065
19:04 kchibisov: yeah, but it has nothing to do with 2 issues about cursor I've linked.
19:04 riteo: yeah
19:04 riteo: but at least I didn't mess up with manually attempting to frac scale it (the original issue I talked about here)
19:05 emersion: i don't think sway should use ceil
19:05 kchibisov: no-one should use ceil.
19:05 emersion: but that's what you suggest in the issue?
19:05 kchibisov: in which one?
19:05 emersion: first linked
19:06 riteo: the issue's different than what you think I mean
19:06 kchibisov: emersion: could you link where I'm talking about ceil.
19:06 kchibisov: I don't have `ceil` matched with firefox search.
19:06 riteo: the thing is that sway's "built in" cursor is different than a similar n-scaled one where n is a buffer scale > 1
19:06 emersion: https://github.com/swaywm/sway/issues/4927#issuecomment-612043427
19:07 kchibisov: emersion: client doesn't know about FSR.
19:07 riteo: then that's a buffer scale
19:07 kchibisov: you're sending clients the scale which is ceil(fsr).
19:08 kchibisov: So sway should use the same scale it sended to clients to look consistent.
19:08 emersion: "FSR" is super confusing lol
19:08 emersion: i was thinking you were talking about AMD FSR the whole time
19:08 kchibisov: I mean, in 2020 we only had integer scale.
19:08 kchibisov: So sway using 1.3333 means that clients get scale 2.
19:08 kchibisov: So they use that to _size_ the cursor.
19:08 riteo: yeah, but that's a buffer scale
19:08 riteo: the compositor should scale it down further, no?
19:08 emersion: kchibisov: yeah, hence i think it's not relevant anymore
19:09 kchibisov: yes, but not fractional scaling clients will do things around the same.
19:09 riteo: emersion: there's still a scaling difference though
19:09 riteo: looks to be a few pixels off, so perhaps it's some rounding thing
19:09 emersion: kchibisov: it's an impossible situation to fix: fix one, break the other
19:09 kchibisov: You don't need to use ceil, you should ensure that the end size of the cursor wil be consisnent.
19:10 emersion: there is no way to do this, since some clients will use ceil()'ed scale, and some not
19:10 kchibisov: I mean, you have a target size of X * Y.
19:11 emersion: sure. and "old" clients use ceil(X) * Y
19:11 kchibisov: So good clients will match it, the ones using `ceil` will have downscaling, and ones using one will upscale.
19:11 kchibisov: fsr will have it _exact_.
19:11 kchibisov: fractional scaling clients*
19:11 emersion: yeah
19:11 riteo: but shouldn't the compositor down/up-scale any integer scaled buffer?
19:12 kchibisov: it's impossible to solve without scaling, but nothing stops you from doing so.
19:12 emersion: fractional-scale clients will match, wl_surface.preferred_buffer_scale clients won't
19:12 kchibisov: The linked issues was about different visual sizes, not bluriness in particular.
19:12 emersion: i'm not sure i'm following, kchibisov
19:12 emersion: yes
19:12 emersion: i don't think there is a way to fix it for all clients
19:13 riteo: why's that? The mouse cursor surfaces are all integer ("buffer") scaled AFAICT
19:13 kchibisov: because client can set larger cursor intentionally?
19:13 emersion: hm, maybe that's the missing piece:
19:14 emersion: libwayland-cursor will not return a cursor whose scale matches the input size necessarily
19:14 emersion: it'll return a theme with size >= the one passed in
19:14 riteo: ok
19:14 riteo: I'm aware of that
19:14 kchibisov: Like I don't see issue of 1. ratio to scale 2x to fractional scale and then downscale by that amount.
19:15 riteo: but, if a "dumb" window gets scaled up/down to accomodate fracscale, why not do the same thing for a cursor?
19:15 kchibisov: Or, you mean that sizes will break, because request to libcursor is different.
19:15 riteo: since it's not fractional, however big that is, we can just up/down scale it accordingly, no?
19:15 emersion: that should be the case…
19:15 riteo: sway's cursor is sligtly smaller/blurrier while application cursors are not
19:15 kchibisov: yeah, the issue is sway internal cursor is bugged.
19:16 kchibisov: cliets look fine-ish.
19:16 riteo: and I confirmed that a cursor smaller than 24 doesn't exist in my theme, so it's not the xcursor behaviour doesn't justify this weird quirk
19:16 riteo: (oops I malformed a the phrase, sorry)
19:16 riteo: (again)
19:16 kchibisov: Well, the only way is to use cursor-shape.
19:16 kchibisov: but sway should at least always render its cursor crisp.
19:16 riteo: indeed, with cursor-shape clients look fine, like foot
19:17 riteo: emersion: don't hesitate to ask if you are having trouble staying on the same page with us
19:17 riteo: (or if you are already and _we_ are misundeerstanding something)
19:17 emersion: yeah, sorry, i'm lost here, and ENOTIME
19:17 riteo: oh
19:17 riteo: if you don't have time nw
19:18 riteo: we can discuss about it later
19:18 kchibisov: emersion: both issues I've linked were about sway builtin cursor.
19:18 emersion: ty for taking the time to try to discuss
19:18 kchibisov: I do understand now that you can't really scale to the same sizes, because the way cursors are picked.
19:18 riteo: emersion: nw :)
19:19 kchibisov: So to solve issues I've linked sway should just render its cursor at the scale it uses.
19:19 kchibisov: When using fractional scaling, if it's the case already, you can close issues.
19:20 kchibisov: But it clearly wasn't the case even a year ago.
19:20 riteo: kchibisov: I think it's probably just some weird edge case with frac scale. I don't know wlroots/sway well so I can't really say anything more specific than that
19:20 kchibisov: riteo: the issues I've linked has nothing to do with the protocol itself.
19:21 kchibisov: because it's when the cursor over sway's decorations, like borders, titlebars.
19:21 riteo: I haven't talked about the protocol
19:21 kchibisov: I mean, I know that it's a fractional scaling issue.
19:21 riteo: like, literally what wlroots or sway do to scale "dumbly scaled" surfaces
19:21 riteo: you know, the "fallback" serverside frac scale thing
19:22 Nefsen402: sway doesn't do that. It supports fractional scale and viewporter protocols
19:23 kchibisov: doens't do anymore?
19:23 riteo: yeah, but what if a client doesn't create fractional surfaces and only buffer scales them?
19:23 riteo: IIRC it downscales them to the fractional scale as a last resort
19:23 Nefsen402: no compositor is able to deal with that properly
19:23 kchibisov: be aware that sway used fractional scaling way before protocols/viewporter.
19:23 riteo: mh
19:24 riteo: it's a bit weird though that for some reason the downscaled server cursor is different than the downscaled client cursor
19:24 riteo: might be because of buffer scale differences perhaps
19:24 kchibisov: riteo: server shouldn't downscale anything.
19:24 riteo: wait, why?
19:24 kchibisov: it's literally picking the cursor out of the theme and passes to render, it's just what the bug was about, since sway started scaling, etc.
19:25 riteo: sorry, I'm getting a bit confused
19:25 kchibisov: I mean, compositor doesn't have a concept of scaling in itself.
19:25 kchibisov: unless toolkit defined it.
19:25 emersion: the server may need to downscale, because the XCursor size doesn't match the configured size
19:25 riteo: I'm noticing a difference in the cursor when setting the global scale to, for example, 1.5
19:26 kchibisov: yeah, it can downscale, but generally, server side created elements can't be blurry unless you did that on purpose.
19:26 riteo: now, if I add a, for example, cursor with a _buffer_ scale of 2, the resulting cursor is definitely differently scaled
19:26 riteo: they're both clearly downscaled, just in a different way for some reason
19:26 riteo: oh wait sorry, upscaled
19:27 riteo: as emersion noted the XCursor theme can offer only certain sizes, so it's not guaranteed that you get a cursor with the exact size you ask
19:27 kchibisov: I'm not even sure that you know what you got.
19:27 emersion: you do
19:27 riteo: you can know
19:27 kchibisov: The target size?
19:28 kchibisov: Cursor could be lower than that.
19:28 emersion: hm, maybe not from a client
19:28 riteo: just query the cursor size, the wayland-cursor library's structs are "open"
19:28 riteo: you can get the cursor image and look for its width/height members
19:28 kchibisov: you know, all cursor sizes are dividable by 2, yet we have crashes due to buffer scale missmatch.
19:29 kchibisov: riteo: you can, but you don't know whether it's 24 theme or 16 theme.
19:29 riteo: mh? You _can_ query the resulting image
19:29 riteo: so you can ask for, dunno, 26 and check what you actually got
19:29 kchibisov: it's not 24x24.
19:29 kchibisov: you can have 1x1 cursor in 24x24 theme.
19:29 riteo: yes
19:29 riteo: but my current theme _doesn't_
19:30 riteo: and I can (and _did_) query for what the library could get
19:30 riteo: I found out about this while experimenting around this issue
19:31 kchibisov: is it just `size` field in libxcursor?
19:31 kchibisov: yeah, seems like nominal is passed around.
19:31 riteo: I'm talking about the `wl_cursor_image` struct
19:31 riteo: what's returned by wayland-cursor
19:31 riteo: it has width, height, delay and hotspot coordinates
19:31 kchibisov: my clients don't use that thing.
19:32 riteo: ¯\_(ツ)_/¯
19:32 riteo: (oops, used the /shrug command and it's way more smiley than I remembered)
19:32 riteo: (didn't mean to sound rude or anything)
19:33 riteo: I don't really know anything about using that library directly, sorry
19:33 kchibisov: I don't even use that library directly,
19:33 kchibisov: I just parse themes myself.
19:33 riteo: oh cool
19:35 kchibisov: but yeah, libXCursor seems like communicates whether it picked what you requested or not.
19:36 riteo: indeed
19:36 kchibisov: Anyway, nothing of that justifies blurry server side cursor.
19:36 riteo: maybe it does some magic with the way it loads the theme? I'll take a look into wlroots, I can't really find a lot in sway
19:37 kchibisov: I mean, it was discussed, and last time I checked it had a bit weird conversions.
19:37 kchibisov: And the way it picked a theme.
19:37 emersion: right now, it's supposed to pick a theme >= config*scale
19:37 emersion: if > that size, scale it down to exactly match the config
19:38 kchibisov: yeah, and in the past it did something like that, but upscaled it.
19:38 kchibisov: so cursor was very big compared to anything else.
19:38 emersion: that shouldn't be the case anymore
19:38 kchibisov: If you can run sway with 1.5 scale and the cursor over borders will be crisp you can close my issue.
19:39 kchibisov: I don't have sway around, so it'll take me _time_ to build/figure out.
19:39 riteo: I don't think the issue is it even being crisp
19:39 kchibisov: before it was just massive blurry cursor.
19:39 riteo: oh it's not massive at all
19:40 emersion: it matches nautilus for me
19:40 kchibisov: like it was 48x48 and not scaled.
19:40 emersion: at 1.75 scale
19:40 riteo: it's small and blurry, but that's to be expected
19:40 riteo: but it's now indeed small
19:40 riteo: the issue I'm having is how it scales the client's buffer scaled cursor surfaces
19:40 kchibisov: emersion: then you can close the issue, if it's around the same size.
19:40 riteo: I think we're talking about different issues
19:41 kchibisov: if it works accross `swaymsg scale 2 -> 1.75` and results in the same looking cursor as with 1.75 scale, you can close other one as well.
19:41 emersion: kchibisov: i consolidated a lot of the cursor code inside wlroots in this release cycle
19:43 emersion: yep, all of these work fine now
19:43 kchibisov: Then close both issues.
19:43 emersion: there is still a small difference in size, but that's because nautilus uses integer scale and sway doesn't
19:44 emersion: but yeah the scale changes are handled in wlr_cursor now
19:45 riteo: emersion: would it be possible to fix the difference in size?
19:45 riteo: just asking to see if it's known or not so that I don't waste anybody's (including mine) timme
19:46 riteo: *time
19:46 kchibisov: riteo: only with shape protocol.
19:46 emersion: i don't think it's possible to fix the difference in size between clients using fractional-scale and clients using integer scale
19:46 emersion: (latter being same as compositor-side cursors rn)
19:47 emersion: (same size, that is)
19:47 riteo: emersion: clients with int-scale and sway's cursors are differently sizes
19:47 riteo: lightly though
19:48 emersion: yup
19:48 kchibisov: you can't fix it because of how cursor themes work.
19:48 emersion: you could fix it maybe on the client side
19:48 riteo: emersion: so it should be possible to fix at least that issue (int client -> compositor)?
19:49 emersion: if you go through the trouble of upscaling the cursor to the proper 2x size before sending them to the compositor
19:49 emersion: but libwayland-cursor can't do that
19:49 kchibisov: emersion: you should at least know what you got though?
19:49 kchibisov: I don't think it's exposed anywhere except libXcursor.
19:49 emersion: kchibisov: libwayland-client is pretty opaque… only gives you a buffer and that's it
19:49 riteo: emersion: oooooh now I think I get it
19:50 emersion: -cursor*
19:50 emersion: maybe clients could use viewporter?
19:50 kchibisov: Yeah, we do around the same in wayland-rs.
19:50 emersion: just throwing ideas around
19:50 kchibisov: viewporter is a good way to protect against buffer missmatches.
19:50 emersion: at some point, just use cursor-shape tbh
19:50 emersion: yeah
19:51 emersion: we can't do this in libwayland-cursor directly sadly
19:51 riteo: no wait I'm seriously failing to understand why a 2sized buffer with, eg, a 24x2 =48 sized buffer couldn't get properly forcibly "upscaled" to 1.5x by the compositor
19:51 riteo: or is that already happening and it's not the same thing that the compositor does on its own cursor
19:51 kchibisov: themes are weird.
19:51 emersion: riteo: the problem is likely that sway uses a 32 xcursor theme and the client uses a 48 xcursor theme
19:52 kchibisov: Buffers of the cursors between theme sizes couldn't change linearly.
19:52 emersion: or something
19:52 riteo: emersion: my setup uses 24
19:52 riteo: as the default theme size
19:52 emersion: but that size is multiplied
19:52 kchibisov: yes, but once you start scaling you pick multiplied.
19:52 emersion: by 1.5 in sway, and 2 in the client
19:52 riteo: oh
19:52 riteo: so sway does indeed do something differently, doesn't it?
19:52 kchibisov: And 32 and 48 could have buffers which you can't scale by 48 / 32.
19:52 riteo: does it scale the buffer's contents manually?
19:52 emersion: yes, because it knows the fractional scale
19:53 riteo: oh I see
19:53 kchibisov: just use shape protocol, and custom cursors are not an issue.
19:53 riteo: yeah I think we're going to do that with Godot once it becomes a bit more widespread
19:54 kchibisov: I mean, you should have fallback path.
19:54 riteo: indeed
19:54 riteo: we're prioritizing other stuff rn as it's still very WIP
19:54 riteo: there are also some API incompatibilities between godot and wayland that we'll have to tackle somehow, but that's another story
19:54 riteo: still, by 4.3 we'll have something merged in
19:55 kchibisov: I know that bevy has fractional scale/shape stuff :p
19:55 kchibisov: never looked how it ends up looking for them though.
19:56 riteo: oh we have frac scale too
19:56 q234rty: well, I just built my cursor theme with support for 24*1.75=42 xcursor size :)
19:56 riteo: that's why I stumbled on this issue :P
19:56 riteo: q234rty: you're playing 4D chess lmao
19:57 riteo: btw last day I was talking with orowith2os[m] about the idea of a simplified vector format for cursor themes
19:57 riteo: (also some interesting pointer wrapping/warping stuff but I still have to recover my gitlab account :( )
19:58 q234rty: well, it was super simple for the cursor theme I have used, as it's build script allows building any size
19:59 q234rty: linking my issue here as I believe its relevant: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3643
20:00 riteo: indeed
20:00 riteo: that's exactly what I noticed