01:57sgm: Hi. Is there any way to interrupt `libinput debug-events --grab`? Unfortunately I can't ssh to this host to kill the process.
01:58sgm: And of course Ctrl+C is being captured by the libinput itself.
06:24whot: sgm: there isn't... the debug-gui has Esc as the quit key but debug-events doesnt
06:24whot: might be a worthwhile addition
11:58wlb: wayland Merge request !362 merged \o/ (build: add a gen-scanner-test target https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/362)
11:58wlb: wayland/main: Simon Ser * build: add a gen-scanner-test target https://gitlab.freedesktop.org/wayland/wayland/commit/0e139cfbc710 tests/ data/README.md scanner-test-gen.sh meson.build
12:14wlb: weston/main: Jeffy Chen * renderer-gl: Fix wrong stride error when reading pixels https://gitlab.freedesktop.org/wayland/weston/commit/623c7b5202b6 libweston/renderer-gl/gl-renderer.c
12:14wlb: weston/main: Jeffy Chen * renderer-gl: Fix segfault when reading pixels https://gitlab.freedesktop.org/wayland/weston/commit/e454de5af3d0 libweston/renderer-gl/gl-renderer.c
12:14wlb: weston Merge request !1435 merged \o/ (renderer-gl: Fix stride errors https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1435)
12:32sgm: whot: yes, unfortunately hard reset was needed; I've tried to connect secondary keyboard, but debug-events immediately took over, so... yeah, lots of fun ;-)
15:20ManMower: now that several protocols (commit-queue, commit-timing... anything that provides a fence?) are creating deferred state updates, does wayland's subsurface.set_sync need a bit of a change? I'm pondering set_sync -> "any currently deferred state updates will be placed in the cache"
15:22ManMower: in my mind this is an easy way to coalesce future state changes into one cached update that can be committed "immediately" when a parent surface commit occurs.
15:32MrCooper: not sure that makes sense, since the updates were committed while the sub-surface was desynchronized, so they shouldn't require an additional parent commit to be applied
15:36ManMower: MrCooper: that's kind of what I'm trying to define my way out of. I'm wanting <child commit> <child commit> <child commit> <set_sync> <child commit> <parent commit> to be sufficient, even if some of those early child commits were playing with strict queuing or timestamps.
15:37MrCooper: it is sufficient, the last child commit just may be delayed due to those before set_sync
15:38ManMower: true, but it could be delayed "forever"
15:38ManMower: because there's really nothing putting a bound on how far into the future a timestamp could be
15:38ManMower: or how many strict commits could be queued up
15:39MrCooper: to put it another way: if set_sync and the rest never happens, the previous commits will get applied eventually; set_sync preventing that again seems like a race condition
15:39ManMower: and set_sync is likely to be in response to something like a corner drag resize?
15:39llyyr: How should clients handle receiving negative size xdg_toplevel configure?
15:39llyyr: [ 118974.818] xdg_toplevel@26.configure(0, -26, array[16])
15:40llyyr: It doesn't seem to be illegal according to the spec
15:41ManMower: llyyr: I'd love to call that a compositor bug, and also make it illegal in the spec...
15:42llyyr: seems to be a sway bug, but I also looked at the spec and it's not illegal so
15:42ManMower: MrCooper: it's definitely going to race with the queue of upcoming events... is that actually bad though?
15:43MrCooper: seems too weird / surprising to me
15:44MrCooper: also seems tricky to implement in the compositor
15:45ManMower: I guess the alternative is that most protocols that allow deferred state should provide their own way to asynchronously collapse their queue of state, and the client can call that explicitly after set_sync?
15:46MrCooper: and since it's a race condition, there could again be different behaviour with different compositors, and clients starting to rely on any specific behaviour
15:48ManMower: I'm not sure I see a way to collapse a queue of future events without any races
15:48ManMower: and I'm fairly confident waiting for the queue to play out before a synchronous commit can happen is not something any application developer would want
15:49ManMower: so I'm not sure what protocol knob to turn to make these disjoint requirements meet in the middle :/
15:49MrCooper: the queue being too long seems like a "doctor, it hurts if I do this" kind of issue
15:51MrCooper: not enthusiastic about making the protocol more complex to cater to that
15:51ManMower: for a video player, I could imagine being commited several frames into the future.
15:52MrCooper: then there may be some initial delay before the window starts resizing
15:52ManMower: I suppose we could ignore this for now and hope nobody complains :)
15:54MrCooper: for a video player, the alternative would be some frames getting presented too early, which doesn't seem great either
15:58ManMower: hrm, wouldn't the player "just" seek to the appropriate time before posting the frame immediately before the parent commit?
16:01MrCooper: "just" win the race, you mean?
16:02MrCooper: and if there are multiple frames still queued at set_sync time, all but the last one are skipped
16:03ManMower: the race would just be "I stopped the queue after the buffer intended for time N presented at time N because I called set_sync at N+.001"
16:04ManMower: and yes, they'd be skipped, and many of their buffers released, at set_sync time
16:05MrCooper: not great either for a video player
16:06ManMower: they were targetting times in the future, so there's still time to queue them back up, except possibly at the correct size since we probably set_sync'd to change that
16:11MrCooper: k, I can see it being at least theoretically possible to get that right
16:12MrCooper: would this also apply to commits being deferred due to fences not having signaled yet for a buffer attachment?
16:14ManMower: I was thinking it would. and that the timing and queue mode extensions would have the "<dependency> is ignored for state being added to the cache" language, but fence related stuff would not have that language.
16:18MrCooper: again seems a bit odd though — the updates were going to be presented ASAP, and the client can't reliably present anything else instead at the same time
16:18MrCooper: so not clear what making them cached again buys
16:19MrCooper: with bad timing, the updates might even miss the refresh cycle they would have hit otherwise
16:19ManMower: honestly, in my head that made it easier to implement
16:20ManMower: it certainly wasn't "this fixes a problem with dmabuf"
16:20ManMower: (thought it does make set_sync _immediate_ by definition again, which it hasn't really been for a long time)
16:20MrCooper: it might make some sense with explicit sync, not really with implicit sync though
16:24MrCooper: my understanding is that "immediate" in the protocol spec doesn't mean "can't be delayed for any reason", just "doesn't require a surface commit"
16:25ManMower: fair - but is that an intentionally made distinction, or is that a side effect of being written in the stone age before we had nice fences?
16:27MrCooper: which distinction? explicit or implicit sync?
16:29ManMower: sorry - immediate meaning "can't be delayed" vs "doesn't require commit", in the context of set_sync
16:30MrCooper: have to defer to others on that
16:30ManMower: yeah, me too
18:27wlb: weston Merge request !1445 opened by Robert Mader (rmader) backend-drm: Sort planes by faked zpos https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1445