ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
zebrag has quit [Remote host closed the connection]
zebrag has joined #wayland
remanifest has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
leon-p has quit [Quit: leon-p]
zebrag has quit [Remote host closed the connection]
jgrulich has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
pnowack has joined #wayland
dcz has joined #wayland
tzimmermann has joined #wayland
manuel1985 has joined #wayland
MrCooper_ is now known as MrCooper
rgallaispou has joined #wayland
rasterman has joined #wayland
hendursa1 has joined #wayland
hendursaga has quit [Ping timeout: 480 seconds]
floof58_ has quit []
floof58 has joined #wayland
<pq>
kennylevinsen, damage without setting a new buffer might not actually be a no-op, I wrote some language in the protocol spec about the last buffer remaining until replaced. Would need to check...
<kennylevinsen>
pq: it does seem underspecified at least - maybe we should update to specify that one shouldn't do that as it makes no sense...
<pq>
kennylevinsen, there is a corner-case where it would make sense: the compositor released the buffer and client re-uses it, but since spec says the buffer remains until replaced, the client could send damage with no attach.
<pq>
however, there is no reason to not attach the buffer again, so
<kennylevinsen>
Hmm true. It is tricky - damage specifies that it's for the pending buffer (which shouldn't apply to old buffers), but also says that pending damage is made current on commit (which could apply to old buffers)
<pq>
wasn't there wording saying the pending buffer remains also pending on commit, or something?
<pq>
unless attach changes it
<pq>
that's a Weston implementation detail seeping through, in hindsight
<pq>
I should have used bit flags to denote which state fields need to be processed on commit, but instead I relied on the fields maintaining their values so re-apply doesn't hurt.
<pq>
and now weston has this "newly attached" flag instead, ugh
<pq>
funny how 5-10 years of additinal experience changes you :-)
<emersion>
"pending buffer remains also pending on commit"
<emersion>
that's kind of not possible for wlroots
<emersion>
because doing this would make it so wl_shm buffers are not released on commit
<pq>
it's just semantics, you don't have to implement it literally
<emersion>
right, but maybe there's a way to describe how the compositor should behave, instead of how it should implement it
<pq>
in weston, the pending buffer reference is special, and does not count against keeping the buffer reserved.
<emersion>
that sounds like implementation details
<pq>
sure, sure - we're talking to me something like 8 years ago :-)
<emersion>
ahah :P
<pq>
at last I'm relatively sure I wrote those pieces...
<pq>
if we still can make the spec more clear and drop the awkward bits, I'm all for it