ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<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.
<MrCooper>
Company: I'm arguing we shouldn't allow attaching a buffer to an explicit sync surface without acquire & release points
<MrCooper>
if we do allow it, it means no synchronization
<Company>
I've been wondering that about all those recent wayland protocols anyway
<Company>
each of those protocols add 1 or 2 things that influence how all the other things work
<Company>
and then in the end it gets real confusing if one of those protocols isn't selected
rgallaispou has joined #wayland
<Company>
the buffer placement stuff with viewport and fractional-scaling and whatnot has similar confusion
<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
<Company>
yeah
<Company>
but once it is enabled, you shouldn't use it without
<emersion>
i still think the release point should be optional
<MrCooper>
yep, I'm arguing that should be a protocol error
<Company>
like, I'm not sure if enabling explicit sync and then using wl_buffer.release is a good idea
<Company>
or not setting sync points
<emersion>
maybe the buffer is already ready
<emersion>
for acquire
<MrCooper>
emersion: the client is free not to wait for it to signal
<emersion>
but why the artificial restriction?
<MrCooper>
because it's required in the common case
<emersion>
why force clients to allocate and manage an extra useless timeline?
<emersion>
especially if it's not more work for the compositor
<MrCooper>
the protocol should be designed for the common case, not for special cases
mohit8158 has quit [Quit: mohit8158]
<emersion>
it's not a special case
<MrCooper>
seriously?
<Company>
emersion: what does it mean if there's no release point?
mohit8158 has joined #wayland
<Company>
emersion: that the client says "I'm gonna reuse the buffer right now while it's still attached"?
<emersion>
it means the client uses the regular release events
<emersion>
no
<Company>
oh hm
<MrCooper>
it means no synchronization takes place on release
<Company>
yeah, that's what I think is a bad idea
<Company>
when you start to mix and match, you end up with too many combinations nobody thought about
<emersion>
the combination needs to work either way
<emersion>
release isn't going away from core wl
<emersion>
and i think most clients won't care about the fenced release anyways
<Company>
you could say "once an explicit sync is created, buffers attached to here are not going to emit release events"
<emersion>
they have a swapchain, they want to know when it's safe to re-use
<MrCooper>
emersion: you're saying most clients won't care about corruption artifacts?
<emersion>
that is not the case
Net147 has joined #wayland
<MrCooper>
what do you think the release points are for then?
<MrCooper>
if the client starts drawing the next frame before the compositor has finished reading from the buffer, you get artifacts
<emersion>
it seems there is a misunderstanding here
<Company>
emersion wants to use wl_buffer.release() instead of the release point
<Company>
right?
<emersion>
the compositor sends core release when it's finished operating on the buffer
<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)
<Company>
Would you treat buffers as pre-created object like in Wayland and essentially establish a pool?
<Company>
Or would you just send dmabuf fds?
<MrCooper>
haven't really thought about that
<Company>
I've been very interested in how those things are handled across graphics APIs recently
<Company>
because I'm wondering if GTK should have a bufferpool abstraction
<MrCooper>
my point is mainly that there needs to be explicit ownership transfer
<Company>
yeah, that one is obvious
<Company>
you need acquire/release
<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
<Company>
GStreamer has explicit GstBufferPool objects
<Company>
which kinda work like Vulkan swapchains, if you look at Vulkan as the consumer and not Wayland (and the application as producer)
<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
<Company>
and GPUs have been using timeline semaphores recently to do the acquire/release thing
<Company>
and now it's coming to Wayland
<Company>
but I have no idea how far this should go - like, should GTK, GStreamer, pipewire, etc all switch to that? Why/Why not?
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
kts has joined #wayland
fmuellner has joined #wayland
<staceee>
hello o/ what should I marshal send to the compositor if an argument is null? example here: get_layer_shell *output
<staceee>
I tried u32 0
juergbi has quit []
juergbi has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
<staceee>
an empty array of course!
<MrCooper>
Company: to me the Wayland (& X Present) model seems the most flexible, I guess I'm biased though :)
<Company>
we're all biased
<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)
<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
<Company>
and the host releases them when done
<MrCooper>
yeah
<Company>
that's slightly different from Vulkan and GL
<Company>
because Vulkan and GL do not let the client manage the unused buffers
<Company>
Vulkan and GL also do the allocation and just let the client set a min/max amount of buffers
<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
<Company>
or drm_syncobjs or whatever that fd thing is called
<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
<Company>
how do drm_syncobjs relate to dmabuf sync files?
<Company>
are they different things?
<MrCooper>
explicit sync which requires the GPU work to be flushed first doesn't buy any fundamental benefit over implicit sync
<MrCooper>
yep, different primitives
<MrCooper>
in a nutshell, a sync file represents a single concrete fence, a timeline syncobj a sequence of (possibly future) fences
<Company>
so there will be a question about attaching drm_syncobjs to dmabufs
<Company>
in some form
Net147 has quit [Ping timeout: 480 seconds]
<Company>
because if Boxes gets a buffer from the VM, we want it to come with a syncobj
<Company>
so that we can pass it right through to the compositor
<MrCooper>
specifically acquire and release points on the timeline, yeah
<Company>
yeah, I guess that's a separate thing and not really part of the dmabuf
<MrCooper>
not really
<MrCooper>
the acquire & release points are what define the transfers of GPU ownership
<Company>
I'm thinking about ownership transfers between VM, Boxes/GTK and host compositor here
<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
<Company>
though technically it's application in VM, VM compositor, CM kernel, Boxes, host compositor and host kernel
<Company>
*VM kernel
Moprius has joined #wayland
<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
<Company>
ideally you want to pass through the acquire/release points everywhere
<Company>
but that requires you to have previously setup the syncobj fd
<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
<MrCooper>
yep
* MrCooper
→ lunch, bbl
<Company>
GTK's graphics offload doesn't have that either
<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
<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
<Company>
which means we use wl_buffer.release() to confirm that we're done with the buffer and only would pass that info onwards
<Company>
because our buffer objects are read-only (unlike wl_buffer), so that API works different
shoragan has quit [Quit: quit]
Moprius has quit [Quit: bye]
kts has quit [Quit: Leaving]
Brainium has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
Net147 has joined #wayland
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #wayland
privacy has quit [Quit: Leaving]
<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.
<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
<emersion>
and so the release point would just be an optimisation
<emersion>
but yeah, reading the protocol again nothing is really said about core release
<emersion>
so we'd have to pick an option (undefined, never sent, sent on release point signalling) and specify that
<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
<emersion>
so a compositor sending release immediately would be correct?
<emersion>
same as undefined from my PoV
lsd|2 has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
<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
<MrCooper>
which means the release point is required for correct explicit synchronization in the common use case
<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
<MrCooper>
wl_buffer.release relies on separate GPU synchronization, which can be implicit or explicit
<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
<emersion>
my point is that wl_buffer.release is meaningless when used with explicit sync, if it's not sent on point release
<emersion>
meaningless as in, the compositor can send it anytime, it doesn't change anything for the client
<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
nerdopolis has joined #wayland
<emersion>
that's very different from implicit sync
tzimmermann has quit [Quit: Leaving]
<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
<emersion>
why?
<MrCooper>
emersion: I'm afraid you're making some assumptions which aren't universally shared, nor written down AFAIK
<emersion>
i'm afraid nothing is written down at this point, your assumptions aren't either
<MrCooper>
emersion: because it could result in the client submitting GPU work which then has to wait indefinitely for a release point to signal
<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
<emersion>
"when the compositor is done" is meaningless
<emersion>
maybe the compositor passes on the unmaterialised syncobj from a parent compositor
<jadahl>
pretty meaningless, true, but I'd like to avoid having to special case it
<MrCooper>
I propose "not before a fence has materialized for all release points"
<emersion>
no
<MrCooper>
yes, I do
<emersion>
wait-before-signal is a major reason why we're using drm_syncobj here
<emersion>
you're just removing half of the protocol's reason for existing here
<MrCooper>
this doesn't prevent wait-before-signal
Brainium has quit [Quit: Konversation terminated!]
<emersion>
this is the worst of both worlds
<emersion>
compositors now need to CPU-wait to send wl_buffer.release, but clients can't really use that in any meaningful way
<MrCooper>
if we can't require that, clients have to wait for fences to materialize, and the release event is useless with explicit sync
<emersion>
why would clients need to wait for fences to materialize?
bim9262 has quit [Ping timeout: 480 seconds]
<emersion>
as opposed to either waiting for the fence to complete, or just using the syncobj as-is
bim9262 has joined #wayland
iomari891 has quit [Remote host closed the connection]
<riteo>
kchibisov: I see, thanks for letting me know. So wlroots is probably fine?
<kchibisov>
riteo: yeah, pretty much.
<riteo>
great
<kchibisov>
I remember sway has like a dozen issues around cursor scaling, and some more around fractional scaling.
<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.
<kchibisov>
Assuming you actually did `set_cursor` call, since you still must commit cursor to actually get event.
<zamundaaa[m]>
MrCooper: I don't think the release event being useless with explicit sync is a problem. Why would you need it?
<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
<zamundaaa[m]>
Which also avoids the release event's race condition with the case where a buffer is used on multiple surfaces
<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)
<zamundaaa[m]>
Sure, there's tradeoffs. Tradeoffs that the client can make just fine without retroactively changing what the release event means
<MrCooper>
the client can avoid both by waiting for a fence to materialize, but then the release event is useless
<zamundaaa[m]>
Yes. Where's the problem?
<MrCooper>
it's a performance trap for clients which needs to be clearly documented at least
<MrCooper>
unless you want to see Phoronix benchmarks showing that explicit sync is slower than implicit ;)
nerdopolis has quit [Ping timeout: 480 seconds]
<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
<zamundaaa[m]>
Oh, I see what you mean now
<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
<emersion>
i don't understand
<emersion>
clients can easily wait for the fence to materialize if that's good for their use-case
<emersion>
with the timeline point
<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
<emersion>
no need to force compositors to do weird stuff with wl_buffer.release
<MrCooper>
I agree it's not hard for clients to do the right thing, they just need to know to avoid the trap
<zamundaaa[m]>
Without running into the risk that the compositor will still hold the buffer for a few more frames
<MrCooper>
*traps
<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
<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
<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
<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
<zamundaaa[m]>
yeah
<MrCooper>
I guess in principle that could be done with implicit sync by polling a dma-buf fd
fmuellner has joined #wayland
rgallaispou has quit [Quit: Leaving.]
leon has joined #wayland
leon-anavi has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
molinari has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Moprius has joined #wayland
rgallaispou has left #wayland [#wayland]
glennk has joined #wayland
greg21 has joined #wayland
leon has quit [Ping timeout: 480 seconds]
blathijs has quit [Quit: WeeChat 4.0.5]
Moprius has quit [Quit: bye]
nerdopolis has joined #wayland
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
leon has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<riteo>
kchibisov: btw the cursor was indeed mapped but I asked the request _before_ setting its surface as such
<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.
<kchibisov>
Then you don't even need fsr if you want to do so.
<riteo>
indeed
<riteo>
I thought I had to do some weird thing to let it scale properly but it's just a bug as you said
<kchibisov>
sway can't downscale cursor with fractional scaling eithir.
<kchibisov>
unless it was fixed, but last time I checked it was still an issue.
<riteo>
it looks like the issue's still there with HEAD
<kchibisov>
emersion: client doesn't know about FSR.
<riteo>
then that's a buffer scale
<kchibisov>
you're sending clients the scale which is ceil(fsr).
<kchibisov>
So sway should use the same scale it sended to clients to look consistent.
<emersion>
"FSR" is super confusing lol
<emersion>
i was thinking you were talking about AMD FSR the whole time
<kchibisov>
I mean, in 2020 we only had integer scale.
<kchibisov>
So sway using 1.3333 means that clients get scale 2.
<kchibisov>
So they use that to _size_ the cursor.
<riteo>
yeah, but that's a buffer scale
<riteo>
the compositor should scale it down further, no?
<emersion>
kchibisov: yeah, hence i think it's not relevant anymore
<kchibisov>
yes, but not fractional scaling clients will do things around the same.
<riteo>
emersion: there's still a scaling difference though
<riteo>
looks to be a few pixels off, so perhaps it's some rounding thing
<emersion>
kchibisov: it's an impossible situation to fix: fix one, break the other
<kchibisov>
You don't need to use ceil, you should ensure that the end size of the cursor wil be consisnent.
<emersion>
there is no way to do this, since some clients will use ceil()'ed scale, and some not
<kchibisov>
I mean, you have a target size of X * Y.
<emersion>
sure. and "old" clients use ceil(X) * Y
<kchibisov>
So good clients will match it, the ones using `ceil` will have downscaling, and ones using one will upscale.
<kchibisov>
fsr will have it _exact_.
<kchibisov>
fractional scaling clients*
<emersion>
yeah
<riteo>
but shouldn't the compositor down/up-scale any integer scaled buffer?
<kchibisov>
it's impossible to solve without scaling, but nothing stops you from doing so.
<emersion>
fractional-scale clients will match, wl_surface.preferred_buffer_scale clients won't
<kchibisov>
The linked issues was about different visual sizes, not bluriness in particular.
<emersion>
i'm not sure i'm following, kchibisov
<emersion>
yes
<emersion>
i don't think there is a way to fix it for all clients
<riteo>
why's that? The mouse cursor surfaces are all integer ("buffer") scaled AFAICT
<kchibisov>
because client can set larger cursor intentionally?
<emersion>
hm, maybe that's the missing piece:
<emersion>
libwayland-cursor will not return a cursor whose scale matches the input size necessarily
<emersion>
it'll return a theme with size >= the one passed in
<riteo>
ok
<riteo>
I'm aware of that
<kchibisov>
Like I don't see issue of 1. ratio to scale 2x to fractional scale and then downscale by that amount.
<riteo>
but, if a "dumb" window gets scaled up/down to accomodate fracscale, why not do the same thing for a cursor?
<kchibisov>
Or, you mean that sizes will break, because request to libcursor is different.
<riteo>
since it's not fractional, however big that is, we can just up/down scale it accordingly, no?
<emersion>
that should be the case…
<riteo>
sway's cursor is sligtly smaller/blurrier while application cursors are not
<kchibisov>
yeah, the issue is sway internal cursor is bugged.
<kchibisov>
cliets look fine-ish.
<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
<riteo>
(oops I malformed a the phrase, sorry)
<riteo>
(again)
<kchibisov>
Well, the only way is to use cursor-shape.
<kchibisov>
but sway should at least always render its cursor crisp.
<riteo>
indeed, with cursor-shape clients look fine, like foot
<riteo>
emersion: don't hesitate to ask if you are having trouble staying on the same page with us
<riteo>
(or if you are already and _we_ are misundeerstanding something)
<emersion>
yeah, sorry, i'm lost here, and ENOTIME
<riteo>
oh
<riteo>
if you don't have time nw
<riteo>
we can discuss about it later
<emersion>
ty for taking the time to try to discuss
<kchibisov>
emersion: both issues I've linked were about sway builtin cursor.
<kchibisov>
I do understand now that you can't really scale to the same sizes, because the way cursors are picked.
<riteo>
emersion: nw :)
leon has joined #wayland
<kchibisov>
So to solve issues I've linked sway should just render its cursor at the scale it uses.
<kchibisov>
When using fractional scaling, if it's the case already, you can close issues.
<kchibisov>
But it clearly wasn't the case even a year ago.
<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
<kchibisov>
riteo: the issues I've linked has nothing to do with the protocol itself.
<kchibisov>
because it's when the cursor over sway's decorations, like borders, titlebars.
<riteo>
I haven't talked about the protocol
<kchibisov>
I mean, I know that it's a fractional scaling issue.
<riteo>
like, literally what wlroots or sway do to scale "dumbly scaled" surfaces
<riteo>
you know, the "fallback" serverside frac scale thing
<Nefsen402>
sway doesn't do that. It supports fractional scale and viewporter protocols
<kchibisov>
doens't do anymore?
<riteo>
yeah, but what if a client doesn't create fractional surfaces and only buffer scales them?
<riteo>
IIRC it downscales them to the fractional scale as a last resort
<Nefsen402>
no compositor is able to deal with that properly
<kchibisov>
be aware that sway used fractional scaling way before protocols/viewporter.
<riteo>
mh
<riteo>
it's a bit weird though that for some reason the downscaled server cursor is different than the downscaled client cursor
<riteo>
might be because of buffer scale differences perhaps
<kchibisov>
riteo: server shouldn't downscale anything.
<riteo>
wait, why?
<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.
<riteo>
sorry, I'm getting a bit confused
<kchibisov>
I mean, compositor doesn't have a concept of scaling in itself.
<kchibisov>
unless toolkit defined it.
<emersion>
the server may need to downscale, because the XCursor size doesn't match the configured size
<riteo>
I'm noticing a difference in the cursor when setting the global scale to, for example, 1.5
<kchibisov>
yeah, it can downscale, but generally, server side created elements can't be blurry unless you did that on purpose.
<riteo>
now, if I add a, for example, cursor with a _buffer_ scale of 2, the resulting cursor is definitely differently scaled
<riteo>
they're both clearly downscaled, just in a different way for some reason
<riteo>
oh wait sorry, upscaled
<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
<kchibisov>
I'm not even sure that you know what you got.
<emersion>
you do
<riteo>
you can know
<kchibisov>
The target size?
<kchibisov>
Cursor could be lower than that.
<emersion>
hm, maybe not from a client
<riteo>
just query the cursor size, the wayland-cursor library's structs are "open"
<riteo>
you can get the cursor image and look for its width/height members
<kchibisov>
you know, all cursor sizes are dividable by 2, yet we have crashes due to buffer scale missmatch.
<kchibisov>
riteo: you can, but you don't know whether it's 24 theme or 16 theme.
<riteo>
mh? You _can_ query the resulting image
<riteo>
so you can ask for, dunno, 26 and check what you actually got
<kchibisov>
it's not 24x24.
<kchibisov>
you can have 1x1 cursor in 24x24 theme.
<riteo>
yes
<riteo>
but my current theme _doesn't_
<riteo>
and I can (and _did_) query for what the library could get
<riteo>
I found out about this while experimenting around this issue
<kchibisov>
is it just `size` field in libxcursor?
<kchibisov>
yeah, seems like nominal is passed around.
<riteo>
I'm talking about the `wl_cursor_image` struct
<riteo>
what's returned by wayland-cursor
<riteo>
it has width, height, delay and hotspot coordinates
<kchibisov>
my clients don't use that thing.
<riteo>
¯\_(ツ)_/¯
<riteo>
(oops, used the /shrug command and it's way more smiley than I remembered)
<riteo>
(didn't mean to sound rude or anything)
<riteo>
I don't really know anything about using that library directly, sorry
<kchibisov>
I don't even use that library directly,
<kchibisov>
I just parse themes myself.
<riteo>
oh cool
<kchibisov>
but yeah, libXCursor seems like communicates whether it picked what you requested or not.
<riteo>
indeed
<kchibisov>
Anyway, nothing of that justifies blurry server side cursor.
<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
<kchibisov>
I mean, it was discussed, and last time I checked it had a bit weird conversions.
<kchibisov>
And the way it picked a theme.
<emersion>
right now, it's supposed to pick a theme >= config*scale
<emersion>
if > that size, scale it down to exactly match the config
<kchibisov>
yeah, and in the past it did something like that, but upscaled it.
<kchibisov>
so cursor was very big compared to anything else.
<emersion>
that shouldn't be the case anymore
<kchibisov>
If you can run sway with 1.5 scale and the cursor over borders will be crisp you can close my issue.
lsd|2 has quit [Remote host closed the connection]
<kchibisov>
I don't have sway around, so it'll take me _time_ to build/figure out.
<riteo>
I don't think the issue is it even being crisp
<kchibisov>
before it was just massive blurry cursor.
<riteo>
oh it's not massive at all
<emersion>
it matches nautilus for me
lsd|2 has joined #wayland
<kchibisov>
like it was 48x48 and not scaled.
<emersion>
at 1.75 scale
<riteo>
it's small and blurry, but that's to be expected
<riteo>
but it's now indeed small
<riteo>
the issue I'm having is how it scales the client's buffer scaled cursor surfaces
<kchibisov>
emersion: then you can close the issue, if it's around the same size.
<riteo>
I think we're talking about different issues
<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.
<emersion>
kchibisov: i consolidated a lot of the cursor code inside wlroots in this release cycle
<emersion>
yep, all of these work fine now
<kchibisov>
Then close both issues.
<emersion>
there is still a small difference in size, but that's because nautilus uses integer scale and sway doesn't
<emersion>
but yeah the scale changes are handled in wlr_cursor now
<riteo>
emersion: would it be possible to fix the difference in size?
<riteo>
just asking to see if it's known or not so that I don't waste anybody's (including mine) timme
<riteo>
*time
<kchibisov>
riteo: only with shape protocol.
<emersion>
i don't think it's possible to fix the difference in size between clients using fractional-scale and clients using integer scale
<emersion>
(latter being same as compositor-side cursors rn)
<emersion>
(same size, that is)
<riteo>
emersion: clients with int-scale and sway's cursors are differently sizes
<riteo>
lightly though
<emersion>
yup
<kchibisov>
you can't fix it because of how cursor themes work.
<emersion>
you could fix it maybe on the client side
<riteo>
emersion: so it should be possible to fix at least that issue (int client -> compositor)?
<emersion>
if you go through the trouble of upscaling the cursor to the proper 2x size before sending them to the compositor
<emersion>
but libwayland-cursor can't do that
<kchibisov>
emersion: you should at least know what you got though?
blathijs has joined #wayland
<kchibisov>
I don't think it's exposed anywhere except libXcursor.
<emersion>
kchibisov: libwayland-client is pretty opaque… only gives you a buffer and that's it
<riteo>
emersion: oooooh now I think I get it
<emersion>
-cursor*
<emersion>
maybe clients could use viewporter?
<kchibisov>
Yeah, we do around the same in wayland-rs.
<emersion>
just throwing ideas around
<kchibisov>
viewporter is a good way to protect against buffer missmatches.
<emersion>
at some point, just use cursor-shape tbh
<emersion>
yeah
<emersion>
we can't do this in libwayland-cursor directly sadly
<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
<riteo>
or is that already happening and it's not the same thing that the compositor does on its own cursor
<kchibisov>
themes are weird.
<emersion>
riteo: the problem is likely that sway uses a 32 xcursor theme and the client uses a 48 xcursor theme
<kchibisov>
Buffers of the cursors between theme sizes couldn't change linearly.
<emersion>
or something
<riteo>
emersion: my setup uses 24
<riteo>
as the default theme size
<emersion>
but that size is multiplied
<kchibisov>
yes, but once you start scaling you pick multiplied.
<emersion>
by 1.5 in sway, and 2 in the client
<riteo>
oh
<riteo>
so sway does indeed do something differently, doesn't it?
<kchibisov>
And 32 and 48 could have buffers which you can't scale by 48 / 32.
<riteo>
does it scale the buffer's contents manually?
<emersion>
yes, because it knows the fractional scale
<riteo>
oh I see
<kchibisov>
just use shape protocol, and custom cursors are not an issue.
<riteo>
yeah I think we're going to do that with Godot once it becomes a bit more widespread
<kchibisov>
I mean, you should have fallback path.
<riteo>
indeed
<riteo>
we're prioritizing other stuff rn as it's still very WIP
<riteo>
there are also some API incompatibilities between godot and wayland that we'll have to tackle somehow, but that's another story
<riteo>
still, by 4.3 we'll have something merged in
kyomawolf has quit [Ping timeout: 480 seconds]
<kchibisov>
I know that bevy has fractional scale/shape stuff :p
<kchibisov>
never looked how it ends up looking for them though.
<riteo>
oh we have frac scale too
q234rty has joined #wayland
<q234rty>
well, I just built my cursor theme with support for 24*1.75=42 xcursor size :)
<riteo>
that's why I stumbled on this issue :P
<riteo>
q234rty: you're playing 4D chess lmao
<riteo>
btw last day I was talking with orowith2os[m] about the idea of a simplified vector format for cursor themes
<riteo>
(also some interesting pointer wrapping/warping stuff but I still have to recover my gitlab account :( )
<q234rty>
well, it was super simple for the cursor theme I have used, as it's build script allows building any size