ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<Consolatis>
I don't quite follow the logic for frame_priv->decoration_mode == ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE but I don't know the codebase
<Consolatis>
ah, nvm
<Consolatis>
i guess it handles hiding the CSD when in client side mode internally and only needs help to hide server side decorations, makes sense
<Consolatis>
forgot that it wasn't a switch-between-client-and-server-side but hide-decoration-or-not
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
navi has quit [Quit: WeeChat 4.1.2]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
<yshui`>
does cursor stay unchanged until the next time set_cursor is called? say cursor changed because user moved pointer over a surface, does it change back when the pointer leaves the surface?
<JoshuaAshton>
if the other surface calls set_cursor, yes
<JoshuaAshton>
or it should on a typical compositor
<danieldg>
as a client, you should call set_cursor on every entry plus when you want it changed
<danieldg>
though I guess it's optional if you get an enter+leave in a single frame on two of your surfaces
<yshui`>
so when the pointer leaves a surface, the cursor is unchanged? or is the compositor allowed to change it to some default cursor?
<yshui`>
* a surface (and enters nothingness), the
<zamundaaa[m]>
The compositor is allowed to do whatever wants
<zamundaaa[m]>
Usually when the mouse is moved outside of a window, it's on top of some other thing - the window decoration, or another window
<danieldg>
there doesn't need to be 'nothingness' anyway - backgrounds are usually a thing
<zamundaaa[m]>
That other thing may set a cursor
<danieldg>
if you're writing a compositor, making a cursor change to a default on leave might be a nice thing to do, but it's not mandatory
<yshui`>
i see.
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
mblenc has quit [Remote host closed the connection]
mblenc has joined #wayland
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #wayland
silverpower has joined #wayland
<YaLTeR[m]>
Hm, I'm seeing a weird problem with chromium and electron. If I have a viewporter global available, and I send a nonzero initial configure, then chromium/electron will set an input region then never ever update it, so if you resize it to be bigger, mouse input won't work on the right side
<YaLTeR[m]>
Normally it sets a nil input region
silverpower_ has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
silverpower_ has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
silverpower_ has quit [Read error: Connection reset by peer]
i509vcb has quit [Quit: Connection closed for inactivity]
mxz has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
kts has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
gallo has quit [Quit: Lost terminal]
gallo has joined #wayland
sima has joined #wayland
luna_ has joined #wayland
Company has quit [Read error: Connection reset by peer]
luna_ has left #wayland [#wayland]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mart has joined #wayland
kts_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
daissi has joined #wayland
<soreau>
YaLTeR[m]: it seems the input region protocol makes it pretty clear this is a client bug, barring the possibility that the client is setting the correct input region and the compositor is doing the wrong thing
<soreau>
either way, you could file a bug with $component depending on what WAYLAND_DEBUG reveals
flokli has quit [Read error: Connection reset by peer]
<YaLTeR[m]>
soreau: yeah, it seems very much a client bug, since the input region never changes even after resizes. Just... this is electron with this kind of issue...
<YaLTeR[m]>
I only checked vscode so far but if it's present in older versions then that's pretty bad since apps update very reluctantly
<kchibisov>
YaLTeR[m]: does it happen on mutter?
<kchibisov>
Or on compositor with fractional scaling?
<YaLTeR[m]>
mutter sends (0, 0) initial, no?
<kchibisov>
So if you send (0,0) it's fixed?
<YaLTeR[m]>
Yes, as far as I can tell this happens when you both have viewporter, and send nonzero initial size
<kchibisov>
I was just curious if their code wants fractional scaling in some area.
<kchibisov>
because they likely have viewporter due to it, so some check might be faulty.
<kchibisov>
you can probably check that by advertising fractional scale, but just using integer scales in it.
<garnacho>
davidre: hey :), I think that's good to go, indeed. I'll poke for last minute opinions on the GNOME side and ack.
<davidre>
Cool
mceier has quit [Remote host closed the connection]
mceier has joined #wayland
Guest2386 has quit [Ping timeout: 480 seconds]
<pq>
yshui`, because I was younger and more naive.
<MrCooper>
kennylevinsen: doesn't seem like much of an edge case really? A commit to a sync sub-surface S of desync parent D is applied together with the following commit to D
<yshui`>
XD
<kennylevinsen>
MrCooper: The other way around: It's a desync descendant, possibly several subsurface layers removed
<MrCooper>
all descendants of synced sub-surfaces are implicitly synced as well
<kennylevinsen>
yes, but the exact intention is a bit unclear - it's very intrusive if this is identical to "set_sync" on all children. Say you have a tree, A -> B -> C, B and C is desync. If A is a regular surface or desync subsurface, committing C is sufficient. If A is a sync subsurface, and this is equivalent to set_sync, then not only A must commit, but also B
<MrCooper>
possible alternative semantics might be having commits to desync sub-surfaces get promoted up to the first sync ancestor, IIRC that would require some spec editing though, and changes to mutter at least
<MrCooper>
yep, indeed
<kennylevinsen>
and in this case, I'm not really sure why the exception would exist at all as it's super inconvenient for the client in either case...
<kennylevinsen>
Julian apparently had yet another interpretation - which definitely feels wrong - but at least it suggests lack of clarity. :)
<pq>
Consolatis, if protocol associates something per wl_surface (or other object), you should not assume the same applies to all objects (of the same type). So using a dummy surfaec to get "compositor preference" is not the best idea.
<pq>
yshui`, a compositor changing the cursor to default on leave might also cause cursor flicker, if the the thing where it entered next took a little bit of time to set it.
Leopold has quit [Remote host closed the connection]
txtsd_ has joined #wayland
<pq>
kennylevinsen, the sub-surface sync rule applies recursively. Grep for "recurs" in the spec.
<yshui`>
@pq Hmm, I see. Maybe a bit of hysteresis time will help
<MrCooper>
pq: I do agree with kennylevinsen that this seems too strict for multiple levels of nested desync'd sub-surfaces though; did you consider semantics like what I described above instead?
txtsd has quit [Remote host closed the connection]
txtsd_ is now known as txtsd
<pq>
yshui`, maybe the entered next will take a little more time to set it. Or maybe it won't, and the user wonders why the cursor image seems to "lag". :-)
Leopold_ has joined #wayland
<pq>
yshui`, IOW, a compositor should be engineered to not rely on setting default cursor image on leave. Either it enters another client which then sets the cursor, or if it enters some compositor-internal thing, then that sets the cursor.
<pq>
MrCooper, quite likely I did not.
<pq>
MrCooper, I think the Weston implementation proves that I never really thought about multiply nested cases, since the Weston implementation cannot handle those correctly.
<yshui`>
I was thinking the compositor can wait a little bit before falling back to default. But if set_cursor is called the change happens immediately
<MrCooper>
pq: I wonder if it's too late to change this in the spec
<pq>
MrCooper, can always change it with a version bump.
<pq>
or maybe someone would be annoyed enough on sub-surfaces to write an alternative, simpler extension?
<MrCooper>
having to maintain both paths in the compositor hardly seems like fun though
<pq>
would it not be just "if (version) propagate_update();"?
<pq>
plus all the tests that we should be having anyway
<yshui`>
How do existing compositors deal with multilevel nested subsurfaces?
<yshui`>
> since the Weston implementation cannot handle those correctly.
<yshui`>
What would weston do if I do it anyway?
<MrCooper>
mutter: using implicit transactions, weston: badly
<MrCooper>
those are the two I know about :)
<pq>
Weston has a single cache per wl_surface, and in some cases it would promote the cache to screen when it should have been moved to another cache instead.
<yshui`>
Hmm, does this mean I get to do whatever I want 🤔
<pq>
IOW, Weston does not cache sub-surface committed state in its parent but in the sub-surface itself.
<MrCooper>
yshui`: nice try ;)
<pq>
I'd been explaining quite a lot of these things in the email thread "Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston"
qaqland has quit [Remote host closed the connection]
kts has joined #wayland
<Consolatis>
pq: re xdg-deco, while I understand (and agree to) your argument in principle, in the case of a compositor preference for either server or client side decorations I don't really see a practical issue with using a dummy surface + unset_mode() and assuming the same preference being applied for a follow up surface. Especially if it is treated as a hint only. Side note: if the xdg-deco protocol would have a manager based compositor preference event li
<Consolatis>
ke the kde one, "educated guesses" (or dirty hacks) like this would not be necessary.
<pq>
Consolatis, propose to the extension designers that you need general preference reply that is not tied to a surface. However, since DE-specific extensions have it, and it was very likely discussed during design, it was probably left out intentionally for some reason.
<yshui`>
I think "set_sync makes all descendants sync" is the easiest for me to implement
<MrCooper>
as it happens, that's also what the spec says
<pq>
I can certainly see the problem of needing commits on the intermediate desync sub-surfaces being a problem, when you expected that desync allows content updates to propagate without commits.
<yshui`>
Also once a surface becomes desync its parent should remove its cached state from the parent's pending changes
<MrCooper>
why?
cmichael has quit [Quit: Leaving]
<pq>
I always go through the same thought cycle: deprecate sync mode completely, make everything always desync in a version bump; oh, but how do you sync on resize then.
<yshui`>
Otherwise you can kind of rewind its state which feels odd
cmichael has joined #wayland
<MrCooper>
not sure what you mean by that, only committed state is cached
<yshui`>
pq, I think some sort of transaction mechanism would be good
<yshui`>
MrCooper, there's an example in my issue
<pq>
there is a protocol extension proposal for transactions
<MrCooper>
and guess what, sync'd sub-surfaces are problematic for that as well
cool110 has joined #wayland
<pq>
sounds like a plan forming
cool110 is now known as Guest2433
<kennylevinsen>
Transactions for a group of equal surfaces that form the logical surface seems more reasonable than subsurfaces
<MrCooper>
getting rid of sync'd sub-surfaces in favour of explicit transactions?
<pq>
MrCooper, yes. I'd be happy with that.
fmuellner has joined #wayland
<pq>
then transactions extension can also say "don't use sync'd sub-surfaces here" and leave those problems unsolved, and throw a protocol error.
<MrCooper>
hmm, one potential issue with the transactions protocol proposal just occurred to me: A wl_surface is always either in a transaction or not, so it's not possible to prepare multiple transactions in parallel for the same surface(s)
mblenc has quit [Remote host closed the connection]
<pq>
It does require applications/library APIs to evolve, so that all surfaces can be added in the transaction when needed, but I think that's a good thing, because I believe sub-surfaces allowed too much to be just yolo'd by relying on the sync mode.
mblenc1 has quit [Remote host closed the connection]
mblenc has joined #wayland
<pq>
and then there will be clients with EGL on a sub-surface...
<pq>
but what I like the most about that plan is, I don't have to be part of it personally :-)
<yshui`>
Sooo we just leave the exact semantic of desync ambiguous?
<pq>
what's ambiguous?
<pq>
desync is how surfaces normally operate
rasterman has joined #wayland
<yshui`>
desync'd subsurfaces l mean
<pq>
yes?
<MrCooper>
I don't think there's any real ambiguity with the current (de)sync'd sub-surface semantics, they're just arguably not what clients want (and not implemented correctly in some compositors yet)
<kennylevinsen>
pq: either way, thanks for clarifying the intent :)
<pq>
I agree with MrCooper. The sub-surface design was too focused on using Wayland for intra-client inter-library "communication".
<pq>
maybe transactions should be modelled completely differently, as setting state *on the connection*. IOW, all commits between these two requests shall be part of the transaction. That would avoid having to evolve app library APIs, but it also has huge potential of having unwanted things in the transaction...
<pq>
hmm... a step towards X11'ish design, wouldn't it
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
<YaLTeR[m]>
that sounds very painful for libraries
<pq>
both?
<MrCooper>
pq: a transaction for the whole connection would have the same issue above, not possible to prepare multiple transactions in parallel
<pq>
sure, but I did not even try to consider that problem. I was thinking of the library API changes needed.
<pq>
like Qt API, libdecor API, etc.
<MrCooper>
conversely, if it's possible to prepare multiple transactions in parallel for the same surface, it's possible to apply committed state out of order
<MrCooper>
wonder which poison tastes better
<pq>
yeah, I didn't think it would make much sense to allow the same surface in multiple transactions simulatenously.
<pq>
it's kinda obvious to me that a surface cannot be in multiple transactions directly, because if it was, the result would be ????
<pq>
however, you could perhaps add transactions into a transaction, as long as there are no cycles.
kts has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
<MrCooper>
pq: my thinking was that a surface could be removed from a transaction before the latter is committed, and surface commits would become part of a transaction only while the surface is associated with that transaction; that allows surface commits to be applied in a different order than they were committed though, which might be too dangerous
<pq>
MrCooper, what's the use for removing a surface from a transaction? Aren't transaction objects one-shot?
<MrCooper>
the use would be making it possible to prepare multiple transactions in parallel, before committing the first one
<pq>
why would one want to do that?
<MrCooper>
I don't have any specific use case offhand, just something that's possible with nested sync'd sub-surfaces
<pq>
it is?
<MrCooper>
yes, there can be multiple cached commits for nested sync'd sub-surfaces
<pq>
isn't that "feature" also a problem? :-)
<MrCooper>
that's why the weston implementation can't be correct, per the pigeon hole principle
<MrCooper>
pq: I'm not saying it's needed, just pointing out a difference
<pq>
The sub-surface design came from the idea that different client components could run mostly independently and sync through Wayland, which has shown to be a problem and no benefit. The client components must cooperate anyway outside of Wayland, so tying some things to Wayland just makes it more difficult to operate.
<pq>
We don't usually design Wayland interfaces to help with client-internal communications, e.g. there are no state getters, and I think that is a good decision.
<emersion>
right, wayland is a message protocol, not a library
<emersion>
that's why i wanted to disallow sending the set_acquire_point twice in the same commit
<emersion>
in the explicit sync protocol
<emersion>
clients shouldn't need to "change their mind", if they really need to, they can buffer their state until the commit