00:02 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
00:03 Consolatis: ah, nvm
00:03 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
00:04 Consolatis: forgot that it wasn't a switch-between-client-and-server-side but hide-decoration-or-not
02:03 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?
02:11 JoshuaAshton: if the other surface calls set_cursor, yes
02:11 JoshuaAshton: or it should on a typical compositor
02:14 danieldg: as a client, you should call set_cursor on every entry plus when you want it changed
02:17 danieldg: though I guess it's optional if you get an enter+leave in a single frame on two of your surfaces
02:39 yshui`: so when the pointer leaves a surface, the cursor is unchanged? or is the compositor allowed to change it to some default cursor?
02:39 yshui`: * a surface (and enters nothingness), the
02:39 zamundaaa[m]: The compositor is allowed to do whatever wants
02:40 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
02:40 danieldg: there doesn't need to be 'nothingness' anyway - backgrounds are usually a thing
02:40 zamundaaa[m]: That other thing may set a cursor
02:42 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
02:45 yshui`: i see.
03:31 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
03:31 YaLTeR[m]: Normally it sets a nil input region
05:58 wlb: weston Merge request !1475 closed (ivi-shell: Delay desktop surface creation notification until commit)
08:36 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
08:37 soreau: either way, you could file a bug with $component depending on what WAYLAND_DEBUG reveals
08:37 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...
08:37 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
08:42 kchibisov: YaLTeR[m]: does it happen on mutter?
08:42 kchibisov: Or on compositor with fractional scaling?
08:42 YaLTeR[m]: mutter sends (0, 0) initial, no?
08:43 kchibisov: So if you send (0,0) it's fixed?
08:43 YaLTeR[m]: Yes, as far as I can tell this happens when you both have viewporter, and send nonzero initial size
08:43 kchibisov: I was just curious if their code wants fractional scaling in some area.
08:44 kchibisov: because they likely have viewporter due to it, so some check might be faulty.
08:44 kchibisov: you can probably check that by advertising fractional scale, but just using integer scales in it.
09:03 davidre: garnacho: Is there anything left to do in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/228 ? I assume you are happy with the protocol so you could add the GNOME ack and we would have the required amount of three acks :D
09:39 Ermine: Sorry if this is a wrong place to ask, but do you have enough nominees to conduct X.org Board elections?
10:24 kennylevinsen: pq: do you remember what the intended behavior of desync subsurfaces with sync ancestors (rather than parents) was? https://gitlab.freedesktop.org/wayland/wayland/-/issues/447#note_2319833
10:24 kennylevinsen: subsurface edge-cases :|
10:27 garnacho: davidre: hey :), I think that's good to go, indeed. I'll poke for last minute opinions on the GNOME side and ack.
10:28 davidre: Cool
10:45 pq: yshui`, because I was younger and more naive.
10:46 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
10:46 yshui`: XD
10:47 kennylevinsen: MrCooper: The other way around: It's a desync descendant, possibly several subsurface layers removed
10:47 MrCooper: all descendants of synced sub-surfaces are implicitly synced as well
10:51 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
10:51 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
10:52 MrCooper: yep, indeed
10:52 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...
10:54 kennylevinsen: Julian apparently had yet another interpretation - which definitely feels wrong - but at least it suggests lack of clarity. :)
10:56 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.
11:01 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.
11:04 pq: kennylevinsen, the sub-surface sync rule applies recursively. Grep for "recurs" in the spec.
11:05 yshui`: @pq Hmm, I see. Maybe a bit of hysteresis time will help
11:06 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?
11:07 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". :-)
11:08 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.
11:09 pq: MrCooper, quite likely I did not.
11:09 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.
11:09 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
11:11 MrCooper: pq: I wonder if it's too late to change this in the spec
11:12 pq: MrCooper, can always change it with a version bump.
11:13 pq: or maybe someone would be annoyed enough on sub-surfaces to write an alternative, simpler extension?
11:13 MrCooper: having to maintain both paths in the compositor hardly seems like fun though
11:14 pq: would it not be just "if (version) propagate_update();"?
11:14 pq: plus all the tests that we should be having anyway
11:14 yshui`: How do existing compositors deal with multilevel nested subsurfaces?
11:15 yshui`: > since the Weston implementation cannot handle those correctly.
11:15 yshui`: What would weston do if I do it anyway?
11:16 MrCooper: mutter: using implicit transactions, weston: badly
11:16 MrCooper: those are the two I know about :)
11:16 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.
11:17 yshui`: Hmm, does this mean I get to do whatever I want 🤔
11:17 pq: IOW, Weston does not cache sub-surface committed state in its parent but in the sub-surface itself.
11:18 MrCooper: yshui`: nice try ;)
11:18 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"
11:22 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
11:22 Consolatis: ke the kde one, "educated guesses" (or dirty hacks) like this would not be necessary.
11:24 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.
11:25 yshui`: I think "set_sync makes all descendants sync" is the easiest for me to implement
11:25 MrCooper: as it happens, that's also what the spec says
11:26 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.
11:27 yshui`: Also once a surface becomes desync its parent should remove its cached state from the parent's pending changes
11:27 MrCooper: why?
11:28 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.
11:28 yshui`: Otherwise you can kind of rewind its state which feels odd
11:29 MrCooper: not sure what you mean by that, only committed state is cached
11:29 yshui`: pq, I think some sort of transaction mechanism would be good
11:30 yshui`: MrCooper, there's an example in my issue
11:30 pq: there is a protocol extension proposal for transactions
11:30 MrCooper: and guess what, sync'd sub-surfaces are problematic for that as well
11:31 pq: sounds like a plan forming
11:32 kennylevinsen: Transactions for a group of equal surfaces that form the logical surface seems more reasonable than subsurfaces
11:32 MrCooper: getting rid of sync'd sub-surfaces in favour of explicit transactions?
11:32 pq: MrCooper, yes. I'd be happy with that.
11:34 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.
11:34 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)
11:36 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.
11:36 pq: and then there will be clients with EGL on a sub-surface...
11:37 pq: but what I like the most about that plan is, I don't have to be part of it personally :-)
11:38 yshui`: Sooo we just leave the exact semantic of desync ambiguous?
11:39 pq: what's ambiguous?
11:39 pq: desync is how surfaces normally operate
11:40 yshui`: desync'd subsurfaces l mean
11:40 pq: yes?
11:40 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)
11:40 kennylevinsen: pq: either way, thanks for clarifying the intent :)
11:41 yshui`: I really just need to know the answer to this question https://gitlab.freedesktop.org/wayland/wayland/-/issues/447#note_2319461
11:42 pq: I agree with MrCooper. The sub-surface design was too focused on using Wayland for intra-client inter-library "communication".
11:43 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...
11:43 pq: hmm... a step towards X11'ish design, wouldn't it
11:52 YaLTeR[m]: that sounds very painful for libraries
11:54 pq: both?
11:57 MrCooper: pq: a transaction for the whole connection would have the same issue above, not possible to prepare multiple transactions in parallel
11:59 pq: sure, but I did not even try to consider that problem. I was thinking of the library API changes needed.
11:59 pq: like Qt API, libdecor API, etc.
12:00 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
12:00 MrCooper: wonder which poison tastes better
12:00 pq: yeah, I didn't think it would make much sense to allow the same surface in multiple transactions simulatenously.
12:01 pq: it's kinda obvious to me that a surface cannot be in multiple transactions directly, because if it was, the result would be ????
12:02 pq: however, you could perhaps add transactions into a transaction, as long as there are no cycles.
12:24 wlb: wayland Merge request !372 opened by Derek Foreman (derekf) libs: Don't allow static libraries to be built https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/372 [Build system], [Cursor library], [IPC library]
12:37 wlb: weston/main: Marius Vlad * backend-pipewire: Move region initialization at the start https://gitlab.freedesktop.org/wayland/weston/commit/b93335a741e0 libweston/backend-pipewire/pipewire.c
12:37 wlb: weston/main: Marius Vlad * stream-pipewire: Add a helper script for the pipewire backend https://gitlab.freedesktop.org/wayland/weston/commit/1eae99b2eefe doc/scripts/stream-pipewire.sh
12:37 wlb: weston Merge request !1474 merged \o/ (backend-pipewire: minor fix and a streaming pipewire script https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1474)
14:09 wlb: wayland Merge request !373 opened by Jordan Williams (jwillikers) egl: Fix symbols check for static builds https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/373
14:24 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
14:26 pq: MrCooper, what's the use for removing a surface from a transaction? Aren't transaction objects one-shot?
14:26 MrCooper: the use would be making it possible to prepare multiple transactions in parallel, before committing the first one
14:27 pq: why would one want to do that?
14:27 MrCooper: I don't have any specific use case offhand, just something that's possible with nested sync'd sub-surfaces
14:28 pq: it is?
14:29 MrCooper: yes, there can be multiple cached commits for nested sync'd sub-surfaces
14:29 pq: isn't that "feature" also a problem? :-)
14:29 MrCooper: that's why the weston implementation can't be correct, per the pigeon hole principle
14:30 MrCooper: pq: I'm not saying it's needed, just pointing out a difference
14:31 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.
14:33 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.
14:34 emersion: right, wayland is a message protocol, not a library
14:35 emersion: that's why i wanted to disallow sending the set_acquire_point twice in the same commit
14:35 emersion: in the explicit sync protocol
14:35 emersion: clients shouldn't need to "change their mind", if they really need to, they can buffer their state until the commit
14:58 wlb: wayland-protocols Merge request !288 opened by Louis Goyard (Louis_Goyard) tablet-v2: add axis event to tablet_tool https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/288
18:21 wlb: wayland Issue #448 opened by Derek Foreman (derekf) libwayland static builds aren't well supported https://gitlab.freedesktop.org/wayland/wayland/-/issues/448 [Build system], [IPC library], [Cursor library]