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.
lockywolf has joined #wayland
sgm has quit [Remote host closed the connection]
sgm has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
sevz has joined #wayland
overholts has quit [Quit: overholts]
overholts has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
lockywolf has quit []
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
lockywolf has joined #wayland
co1umbarius has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Dami_Lu has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
luna has quit [Remote host closed the connection]
mxz has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
Company has quit [Quit: Leaving]
sima has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
<whot> sgm: there isn't... the debug-gui has Esc as the quit key but debug-events doesnt
<whot> might be a worthwhile addition
TheCaptain82970403198578 has joined #wayland
TheCaptain8297040319857 has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
Dami_Lu has joined #wayland
garnacho has joined #wayland
tzimmermann has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
sgm has quit [Remote host closed the connection]
sgm has joined #wayland
kts has joined #wayland
kts_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
kts has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
rgallaispou has joined #wayland
iomari891 has joined #wayland
qaqland has joined #wayland
kts has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
privacy has joined #wayland
alatiera has joined #wayland
iomari891 has joined #wayland
Hypfer is now known as Guest14404
Hypfer has joined #wayland
Guest14404 has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
kts has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
abcdw has joined #wayland
staceee has joined #wayland
tsujp has joined #wayland
moses has joined #wayland
cpli has joined #wayland
sumoon has joined #wayland
mainiomano has joined #wayland
kuruczgy has joined #wayland
ifreund has joined #wayland
geemili has joined #wayland
dorkbutt has joined #wayland
novakane has joined #wayland
c7s has joined #wayland
ogromny has joined #wayland
jonesv has joined #wayland
raghavgururajan has joined #wayland
pitust has joined #wayland
rpigott has joined #wayland
dubiousness has joined #wayland
kchibisov_ has joined #wayland
kennylevinsen has joined #wayland
leon-p has joined #wayland
txtsd has joined #wayland
rosefromthedead has joined #wayland
tommybomb has joined #wayland
kindablue has joined #wayland
WhyNotHugo_ has joined #wayland
cat has joined #wayland
dnkl has joined #wayland
fabiancodes has joined #wayland
elibrokeit_ has joined #wayland
raghavgururajan is now known as Guest14409
leon-anavi has joined #wayland
cmichael has joined #wayland
kts has quit [Ping timeout: 480 seconds]
neniagh has quit [Read error: No route to host]
rasterman has joined #wayland
neniagh has joined #wayland
neniagh has quit [Read error: No route to host]
neniagh has joined #wayland
sima is now known as Guest14417
sima has joined #wayland
AnuthaDev has joined #wayland
Guest14417 has quit [Read error: Connection reset by peer]
WhyNotHugo_ has quit [Remote host closed the connection]
sima is now known as Guest14418
sima has joined #wayland
Guest14418 has quit [Ping timeout: 480 seconds]
neniagh has quit []
neniagh has joined #wayland
kchibisov has quit [Remote host closed the connection]
kchibisov_ is now known as kchibisov
kts has joined #wayland
eroc1990 has quit [Read error: Connection reset by peer]
eroc1990 has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit [Remote host closed the connection]
mclasen has joined #wayland
<wlb> wayland Merge request !362 merged \o/ (build: add a gen-scanner-test target https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/362)
<wlb> 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
fossdd has quit [Remote host closed the connection]
kts has joined #wayland
AnuthaDev has quit []
Leopold_ has joined #wayland
<wlb> 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
<wlb> 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
<wlb> weston Merge request !1435 merged \o/ (renderer-gl: Fix stride errors https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1435)
<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> [ 118974.818] xdg_toplevel@26.configure(0, -26, array[16])
<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
<MrCooper> have to defer to others on that
<ManMower> yeah, me too
tzimmermann has quit [Quit: Leaving]
Company has joined #wayland
glennk has joined #wayland
Leopold has joined #wayland
kts has quit [Quit: Leaving]
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
andyrtr has joined #wayland
jlco has quit [Quit: No Ping reply in 180 seconds.]
jlco has joined #wayland
kts has joined #wayland
AnuthaDev has joined #wayland
zxrom has quit [Quit: Leaving]
Company has quit [Read error: Connection reset by peer]
Company has joined #wayland
<wlb> 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
zxrom has joined #wayland
kts has quit [Quit: Leaving]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
rv1sr has quit []
AnuthaDev has quit []
leon-anavi has quit [Quit: Leaving]
fmuellner has quit [Ping timeout: 480 seconds]
sgm has left #wayland [#wayland]
qaqland_ has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
qaqland_ is now known as qaqland
___nick___ has quit [Ping timeout: 480 seconds]
rgallaispou has left #wayland [#wayland]
sima has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
checkfoc_us has joined #wayland
fmuellner has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium has joined #wayland
nerdopolis has joined #wayland
Leopold has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]