ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Leopold_ has joined #wayland
Brainium has joined #wayland
Leopold_ has quit [Remote host closed the connection]
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
mort_ has quit [Quit: Ping timeout (120 seconds)]
Brainium has quit [Quit: Konversation terminated!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
lockywolf has quit []
sgm has joined #wayland
<sgm>
Hi. Is there any way to interrupt `libinput debug-events --grab`? Unfortunately I can't ssh to this host to kill the process.
<sgm>
And of course Ctrl+C is being captured by the libinput itself.
<sgm>
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 ;-)
Leopold_ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
fossdd has joined #wayland
fossdd has quit [Remote host closed the connection]
fossdd has joined #wayland
mtj has quit [Quit: mtj]
iomari891 has quit [Remote host closed the connection]
neniagh has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
vincejv has quit [Quit: Bye bye! Leaving for now...]
neniagh has joined #wayland
vincejv has joined #wayland
neniagh has quit [Read error: No route to host]
neniagh has joined #wayland
iomari891 has joined #wayland
sgm has quit [Remote host closed the connection]
sgm has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<ManMower>
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"
<ManMower>
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.
kts has joined #wayland
<MrCooper>
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
<ManMower>
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.
<MrCooper>
it is sufficient, the last child commit just may be delayed due to those before set_sync
<ManMower>
true, but it could be delayed "forever"
<ManMower>
because there's really nothing putting a bound on how far into the future a timestamp could be
<ManMower>
or how many strict commits could be queued up
<MrCooper>
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
<ManMower>
and set_sync is likely to be in response to something like a corner drag resize?
<llyyr>
How should clients handle receiving negative size xdg_toplevel configure?
<llyyr>
It doesn't seem to be illegal according to the spec
<ManMower>
llyyr: I'd love to call that a compositor bug, and also make it illegal in the spec...
<llyyr>
seems to be a sway bug, but I also looked at the spec and it's not illegal so
<ManMower>
MrCooper: it's definitely going to race with the queue of upcoming events... is that actually bad though?
glennk has quit [Ping timeout: 480 seconds]
<MrCooper>
seems too weird / surprising to me
<MrCooper>
also seems tricky to implement in the compositor
<ManMower>
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?
<MrCooper>
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
<ManMower>
I'm not sure I see a way to collapse a queue of future events without any races
<ManMower>
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
<ManMower>
so I'm not sure what protocol knob to turn to make these disjoint requirements meet in the middle :/
<MrCooper>
the queue being too long seems like a "doctor, it hurts if I do this" kind of issue
<MrCooper>
not enthusiastic about making the protocol more complex to cater to that
<ManMower>
for a video player, I could imagine being commited several frames into the future.
<MrCooper>
then there may be some initial delay before the window starts resizing
<ManMower>
I suppose we could ignore this for now and hope nobody complains :)
<MrCooper>
for a video player, the alternative would be some frames getting presented too early, which doesn't seem great either
iomari891 has quit [Ping timeout: 480 seconds]
bodiccea_ has joined #wayland
<ManMower>
hrm, wouldn't the player "just" seek to the appropriate time before posting the frame immediately before the parent commit?
<MrCooper>
"just" win the race, you mean?
<MrCooper>
and if there are multiple frames still queued at set_sync time, all but the last one are skipped
<ManMower>
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"
<ManMower>
and yes, they'd be skipped, and many of their buffers released, at set_sync time
<MrCooper>
not great either for a video player
<ManMower>
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
<MrCooper>
k, I can see it being at least theoretically possible to get that right
bodiccea_ has quit [Quit: Leaving]
<MrCooper>
would this also apply to commits being deferred due to fences not having signaled yet for a buffer attachment?
<ManMower>
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.
<MrCooper>
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
<MrCooper>
so not clear what making them cached again buys
<MrCooper>
with bad timing, the updates might even miss the refresh cycle they would have hit otherwise
<ManMower>
honestly, in my head that made it easier to implement
<ManMower>
it certainly wasn't "this fixes a problem with dmabuf"
<ManMower>
(thought it does make set_sync _immediate_ by definition again, which it hasn't really been for a long time)
<MrCooper>
it might make some sense with explicit sync, not really with implicit sync though
<MrCooper>
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"
<ManMower>
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?
neniagh has quit []
<MrCooper>
which distinction? explicit or implicit sync?
<ManMower>
sorry - immediate meaning "can't be delayed" vs "doesn't require commit", in the context of set_sync