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
nerdopolis has quit []
nerdopolis has joined #wayland
nerdopolis has quit []
nerdopolis has joined #wayland
cabal705 has quit []
ybogdano has quit [Ping timeout: 480 seconds]
sozuba_tmp has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Guest580 is now known as bluepenquin
bcheng has quit [Remote host closed the connection]
bcheng has joined #wayland
gspbirel56 has quit [Read error: Connection reset by peer]
gspbirel56 has joined #wayland
anomalous_creator[m] has quit []
MatrixTravelerbot[m]1 has quit []
psydroid[m] has quit []
Guest581 has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
<RAOF>
Urgh. How do compositors handle clients that a create shm buffers, attach it, and then immediately delete the buffer? Do you all just immediately copy out of the wl_shm_buffer on surface.commit()?
<RAOF>
Keeping the pointer into the shm buffer around (and `ref`ing the underlying shm_pool) breaks clients that expect to be able to resize the shm pool :(
bluepenquin has quit [Quit: issued !quit command]
<RAOF>
I guess I could only pull out a pointer and ref the underlying shm_pool if the buffer is being destroyed while we've still got a reference to it, maybe?
<i509VCB>
Per the specification in wl_surface.attach: if the client destroys the wl_buffer before receiving the wl_buffer.release event and mutates the underlying buffer storage, the surface contents become undefined immediately.
<i509VCB>
The compositor can try to read from the mmaped shm memory I think, so if the client wrote stuff to the buffer it may still be readable
<RAOF>
Right, but if the client destroys the wl_buffer but doesn't mutate the underlying buffer storage you need to handle it.
<RAOF>
If you don't take a reference to the underlying shm_pool then when the client destroys the buffer it unrefs the shm_pool and it's unmapped, right?
<i509VCB>
I believe munmap does not free the underlying memory until all processes release it?
<i509VCB>
So the client calling munmap will do nothing if the compositor hasn't processed the destroy requests yet
<RAOF>
Right, but the compositor has processed the destroy requests, and the server-end of libwayland has unreffed the shm_pool, because the wl_buffer has been destroyed.
<i509VCB>
do you have an example of such a client by chance?
<RAOF>
swaybg
<i509VCB>
you are registered with NickServ I assume?
<i509VCB>
IRC folks can't hear you unless you register with NickServ
<RAOF>
creates a pool, creates a buffer from it, destroys the pool, attaches the buffer, commits the surface, destroys the buffer.
<RAOF>
Now, maybe this is (or should be) a protocol error - swaybg is not mutating the underlying buffer storage as such, but it's making every effort to ensure the underlying storage goes away :)
<RAOF>
But it's a client that works in at least some compositors, and at least some people think that sequence should work :)
<i509VCB>
KDE appears to keep the buffer around. Trying to test in anvil quickly
jryans has quit []
bluepenquin has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
<RAOF>
Hm. Maybe I can make this code radically simpler and only slurp out the wl_shm_pool when the buffer is destroyed while we might still need to render from it. That would be nice!
<RAOF>
Oh, no, can't do the simplest thing because buffers can be submitted to multiple surfaces at once. This is why we can't have nice things.
sozuba_tmp has quit [Read error: Connection reset by peer]
slattann has joined #wayland
slattann has quit [Read error: Connection reset by peer]
Ordoviz has joined #wayland
tzimmermann has joined #wayland
dcz_ has joined #wayland
<emersion>
swaybg never re-uses the underlying storage
<emersion>
yes, i believe create buffer + attach + commit + destroy must work, per the spec
<emersion>
it's used to consume as little memory as possible: the buffer underlying storage is released as soon as the compositor is done with the upload
danvet has joined #wayland
rv1sr has joined #wayland
danie1dg has joined #wayland
<RAOF>
Right, but this requires that the compositor eagerly upload on commit.
<RAOF>
If the compositor doesn't (because, say, the background is completely occluded and so doesn't need to be composited at all), then the underlying storage goes away. Which is a little annoying!
hardening has joined #wayland
<RAOF>
It's a perfectly sensible thing for swaybg to do, it's just annoying that libwayland doesn't provide tools to deal with it.
<RAOF>
(And the obvious tools have non-obvious side-effects)
danieldg has quit [Ping timeout: 480 seconds]
<emersion>
nope
<emersion>
it requires the compositor to keep a ref to the buffer's underlying data even if the object is destroyed
<emersion>
just like many other things really
<emersion>
wl_region is another example
<emersion>
many clients will create a region, use it on the surface, then destroy it
<RAOF>
That's less of an issue as regions are simple.
<RAOF>
The annoying thing is that the obvious solution - just unconditionally take a ref to the shm pool - breaks clients that want to resize the pool.
<emersion>
yes, that's a defect of the libwayland API
<RAOF>
It's also annoying that wl_shm_buffer_begin_access stops working.
<emersion>
wlroots takes a ref on buffer object destroy iirc
<RAOF>
Yeah, that's what I'll end up doing.
<RAOF>
How does wlroots handle clients doing this, but with broken buffers?
<RAOF>
Do you install your own SIGBUS handler?
<emersion>
in my experience wl_shm_buffer_begin_access keeps working?
<emersion>
we'll likely end up just doing our own impl at some point
<RAOF>
wl_shm_buffer_end_access will try and send a protocol error on a null wl_resource if you ever hit it.
<emersion>
ah, sounds like a bug in libwayland
<RAOF>
(This is also slightly annoying - wl_shm_buffer almost still works 😃)
<RAOF>
Yeah, I was pondering what the right PR would be.
<emersion>
it should null-check
<RAOF>
Yeah, that'd be the simplest patch.
<emersion>
if we really wanted to send a protocol error we could keep a wl_client
<emersion>
but i don't think it's worth it
<RAOF>
I'd like to make it so that wl_shm_buffer handles keeping the underlying storage around, but that's an API break.
<emersion>
(client could go away, too, in which case we still cannot send the error)
<emersion>
i'd like to add wl_shm_buffer_ref or something
<emersion>
which doesn't prevent the pool from growing
<RAOF>
There's a slightly different API nearby in API-space that's much nicer :)
<emersion>
but still ensures the buffer struct is not destroyed
<RAOF>
Yeah, maybe just adding a new wl_shm_buffer_ref type would be sufficient.
<RAOF>
Doesn't even need to ensure the buffer struct remains; it just needs to take an internal ref on the pool?
<emersion>
maybe find a better name because "ref" is already used for something different
<RAOF>
The second hard problem.
<emersion>
ah, i was thinking about making it a function
<emersion>
so that all existing wl_shm_buffer functions can still be called as usual
<RAOF>
Well, if the function took an internal ref on the pool then all the existing wl_shm_buffer functions could be called as usual.
<RAOF>
(That's what's frustrating about wl_shm_buffer)
<RAOF>
With the exception of end_access trying to send a protocol error
<emersion>
sometimes i wonder why i still do standardization work
<emersion>
one of these things where 50% of your efforts will go no-where
<emersion>
this protocol is ill-defined, we need it for two different use-cases
<emersion>
one is IM/activity tracker and such, where idle-inhibit should not matter
<emersion>
one is swayidle, where idle-inhibit should matter
<emersion>
if the compositor picks a side (as compositor policy), then the other use-case is broken
<romangg>
There are other reasons to question standardization work. Mainly that companies want to avoid paying engineers to do it (no differentiation/profit factor of their products!).
<romangg>
swayidle is for controlling dpms?
<emersion>
swayidle is a generic deamon to execute commands when entering or leaving idle
<emersion>
it's often used by sway users for dpms
<romangg>
if it's generic why do you think it should pick a side?
<romangg>
I.e. a generic daemon would need to serve both cases: with and without idle-inhibit.
<romangg>
Otherwise it's not "generic".
<romangg>
So let's say it's "generic" but de facto it's for dpms, true?
<emersion>
maybe we should just add a "ignore inhibitor" flag or something
<emersion>
yeah, ignoring inhibitors in swayidle would break our users
<emersion>
(at least by default)
<romangg>
We could add a flag OR say these are two totally different use cases and the use case that our "idle-protocol" covers is the one where we have idle inhibition.
<romangg>
The use case we usually care about in the context of compositor communication: dpms
<romangg>
Which questions the generic idea behind the "idle-protocol" of course but there might be other applications similar to dpms.
<romangg>
Just not so generic to provide a way to opt out of idle inhibition.
<romangg>
*just no applicaiton that likes to opt out of idle inhibition.
<emersion>
for the IM case, i think it's a bit more complicated than "opt out of inhibitors"
<emersion>
if the user is playing a fullscreen game for instance, maybe they should be marked away
<zubzub>
08:30 < emersion> i'd like to add wl_shm_buffer_ref or something
<zubzub>
08:30 < emersion> which doesn't prevent the pool from growing
<romangg>
The message also mentions chat applications but I wouldn't give too much about that. The chat application code can be changed and currently the kde idle protocol also honors inhibitors. so there would actually not be any regression when changing to the upstream one.
<emersion>
yea that makes sense
<emersion>
thanks for bugging me about this, i'll update the protocol to make it clear this initial version is not for the IM use-case
<romangg>
Thanks for letting me bug you about it (and doing all that protocol work nobody else wants to do for reasons mentioned above!).
<emersion>
RAOF: i think atm we just crash if the client shrinks the backing file :/
<RAOF>
:)
* RAOF
is currently writing a temporary SIGBUS handler
<emersion>
yeah
<emersion>
i think i'll just ditch libwayland
<RAOF>
We actually have some special handling for libwayland's SIGBUS handler, because it interacts badly with trying to run multiple tests in the same process.
<RAOF>
Maybe the correct response is just to never call wl_shm_buffer_begin_access()? 🤔
<RAOF>
Hm. I guess the use case shm_pool.get_buffer / buffer attach / surface commit / shm_pool resize is just unavoidably broken.
<pq>
emersion, yay Weston RC, thank you!
<RAOF>
You can sometimes grow the shm_pool without invalidating the backing storage, but I'm happy to let clients that try to do that just die.
<RAOF>
Demi: Nah, you need to hold the FD open. The only case that's broken is where the client creates the buffer, commits it, deletes it, and *then* tries to resize the shm_pool it came from.
rasterman has joined #wayland
<RAOF>
I guess we could support that with changes to libwayland (wl_shm_buffer_retain/wl_shm_buffer_release).
<emersion>
Demi, your messages aren't getting through
<emersion>
pq, np!
DemiMarieObenour[m] is now known as DemiMarie
Ordoviz has left #wayland [#wayland]
<DemiMarie>
emersion: fixed, but damn OFTC needs to support SASL.
<DemiMarie>
emersion: why ditch libwayland? Also, could a SIGSEGV handler be added (with signal chaining) alongside the SIGBUS one?
<pq>
well, a client doing *anything* to the wl_shm_pool (except destroying it) after destroying the wl_buffer that came from it counts as mutating the storage.
<pq>
DemiMarie, in-process SEGV handlers only produce fallacy.
<RAOF>
pq: Why? Resizing it (to larger) needn't invalidate the backing store.
<pq>
RAOF, no, but when it next allocated a new buffer (why else would it resize), it's going mutate the storage contents.
<pq>
...when writing into the new buffer
<RAOF>
I mean "why, other than it being annoying for us and kinda defeating the purpose of deleting the original buffer" :)
<RAOF>
pq: Writing to a memory address in a shm fd invalidates the whole backing store? Even when those accesses don't overlap?
<pq>
RAOF, no. I'm not talking about invalidating the storage. I'm talking about changing the content of the storage, which IIRC is explicitly forbidden (but no way to reliably enforce).
<pq>
a.k.a writing into a wl_buffer that is currently reserved by the compositor -type of situation
safinaskar has joined #wayland
<RAOF>
Right but if you have two buffers from the same shm pool, writing to one (which the compositor had release()d, it which you haven't submitted yet) while the other is in use by the compositor is fine, no?
<pq>
yes
<pq>
also not what I'm talking about
<pq>
you destoryed your old wl_buffer, resized the pool, allocate a new buffer from the pool, and write into that
<emersion>
DemiMarie: because libwayland's implementation of wl_shm is just getting in our way more often than not
<pq>
logically, the new wl_buffer could be using the old one's storage
<pq>
since the old one was freed
<RAOF>
Ah, right. You can't guarantee that the new buffer does have disjoint storage.
<pq>
exactly
<pq>
so IMO that whole sequence is illegal, meaning I wouldn't care what happens to the client attempting it.
<pq>
and IMO I could accept disconnecting the client at the resize step already
<emersion>
DemiMarie: SIGSEGV handlers are just a way to ask for trouble
<emersion>
DemiMarie: reminds me that i made this as a joke some time ago https://l.sr.ht/diDZ.png
<pq>
however, I don't disagree with emersion in that maybe wl_shm implementation in libwayland-server was a mistake in the long run.
<emersion>
with some setjmp/SIGSEGV handler magic of course
* zubzub
is confused on what the SHM problem is and why his MR is insufficient to fix the issue
<zubzub>
(admitted I don't fully understand the problem)
<emersion>
zubzub, the shm problem is: how can we handle a wl_buffer being destroyed by the client but still in-use by the compositor (for later upload)
<pq>
zubzub, wl_shm has several problems: needing a signal handle in a library; not being able to validate pixel format/width/height vs. buffer size
<pq>
*signal handler
idkrn[m] has quit []
feta has quit []
ashketchum[m] has quit []
<i509VCB>
emersion I recall opening a PM on irc to ask a question about the wl_shm implementation in the wayland repo but I'm not sure if the matrix bridge broke there?
<zubzub>
right, and my MR just keeps pointers into shm pool valid after a resize, which is too limited in scope for the issue?
<emersion>
zubzub: the issue above is not about resizes
<emersion>
i509VCB: hm I also may have missed it
<emersion>
if you want to report a vuln, please create a confidential issue on GitLab
<emersion>
in general I'm not the person to look at these reports
<i509VCB>
Worst case it isn't actually a vulnerability I guess
<i509VCB>
I'll look into that tomorrow
<zubzub>
emersion: oh I just assumed it was because of all the resize pool examples, I guess the issue is that compositor has pointer into shm pool, client destroys buffer, creates new buffer that has overlap with memory from old buffer?
<emersion>
nope
<emersion>
the issue is not with overlaps
MajorBiscuit has joined #wayland
<emersion>
it's purely with wl_shm_buffer being destroyed
<emersion>
but the compositor still needing access
<RAOF>
Client commits the buffer, client destroys the buffer, client destroys the pool, compositor still needs access.
<emersion>
a similar situation happens when the client exits, but the compositor needs to keep access to the buffer to perform an animation of instance
<emersion>
or wait for other clients to submit an updated buffer
<emersion>
(on tiling compositors)
<zubzub>
ok, and the current pool ref mechanism is insufficient for that use case?
<emersion>
indeed
<RAOF>
Hmm. Implementing shm ourselves would make a bunch of things easier…
<zubzub>
what are it's shortcomings?
<emersion>
no SIGBUS handler for one
spstarr has joined #wayland
<pq>
...how do you get rid of SIGBUS completely, even for old clients? using pread() instead of mmap()?
<emersion>
you just install the SIGBUS handler yourself?
<emersion>
also it's not just "old clients"
<emersion>
i'm not adding support for Linux-specific APIs in all of my clients
<DemiMarie>
Using sealed memfds is the best option, but it should be abstracted behind a library.
<DemiMarie>
emersion: nobody will get that right.
<emersion>
i disagree, i think MAP_NOSIGBUS is the best option
<DemiMarie>
emersion pq: The reason I wanted a SIGSEGV handler is that I am extending wl_shm to support read-only buffers, and that will cause compositors to crash if they try to write to the buffer.
<emersion>
if a compositor tries to write to a read-only buffer, then it's on them
<DemiMarie>
emersion: yeah, that is even better. Just replace the buffer with zeros. Should just be a page table entry swap, no allocation needed.
<emersion>
same as double-destroying a struct
<RAOF>
Crashing seems like the good behaviour there?
<DemiMarie>
emersion: I would agree except that this means that this feature of wl_shm would need opt-in on the compositor side
<emersion>
yes
<RAOF>
It's going to need to be opt-in anyway, right? The compositor silently doing the wrong thing isn't better.
<emersion>
d_ed[m]: thanks for the reply!
<DemiMarie>
pq: could libwayland at least validate strides for known DRM formats?
cmeissl[m] has quit []
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
ahmadraniri[m] has quit []
Standreas[m] has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
frytaped[m] has quit []
underpantsgnome[m] has quit []
flyingketh[m] has quit []
ki[m] has quit []
toggleton[m] has quit []
cb5r[m] has quit []
ujineli[m] has quit []
jacobcrypusa[m] has quit []
nielsdg has quit []
hasebastian[m] has quit []
Nico has quit []
deknos82[m] has quit []
unrelentingtech has quit []
ozwald1[m] has quit []
MarcusBritanicus[m] has quit []
Mershl[m] has quit []
robertmader[m] has quit []
gnustomp[m] has quit []
GeorgesStavracasfeaneron[m] has quit []
tleydxdy has quit [Quit: Bridge terminating on SIGTERM]
pac85[m] has quit []
JosExpsito[m] has quit []
yshui` has quit []
YaLTeR[m] has quit []
Guest605 has quit []
doras has quit []
halfline[m] has quit []
Sumera[m] has quit []
xerpi[m] has quit []
niecoinny[m] has quit []
rails[m] has quit []
BilalElmoussaoui[m] has quit []
ongy[m] has quit []
pitsch[m] has quit []
ttancos[m] has quit []
apol[m] has quit []
d_ed[m] has quit []
GrahamPerrin[m] has quit []
Shimmy[m] has quit []
ammen99[m] has quit []
teh1[m] has quit []
j-james[m] has quit []
Levans has quit []
Poly[m] has quit []
varlad[m] has quit []
rubo_[m] has quit []
shadowninja55[m] has quit []
Guest612 has quit []
diamondburned[m] has quit []
edrex[m] has quit []
danburd[m] has quit []
Florian[m]1 has quit []
cousinofthor[m] has quit []
[old]freshgumbubbles[m] has quit []
davidre has quit []
emilio[m] has quit []
scriptingdad[m] has quit []
hex[m]1 has quit []
jmariondev[m] has quit []
RomanGilg[m] has quit []
inkbottle[m] has quit []
japchae[m] has quit []
arichardson[m] has quit []
Guest588 has quit []
jasyuiop[m] has quit []
i509VCB has quit [Quit: Bridge terminating on SIGTERM]
unix has quit []
RAOF has quit [Quit: Bridge terminating on SIGTERM]
hch12907 has quit []
zamundaaa[m] has quit []
nazarewk[m] has quit []
bdaase[m] has quit []
junglerobba[m] has quit []
vchernin[m] has quit []
drakulix[m] has quit []
AndrewAylett[m] has quit []
windowsxp[m] has quit []
FbioPacheco[m] has quit []
smasher_tati[m] has quit []
botiapa[m] has quit []
unix-supremacist[m] has quit []
Kelseyjgilbert[m] has quit []
zaibon[m] has quit []
bluepenquin has quit [Quit: Bridge terminating on SIGTERM]
DemiMarieObenour[m] has joined #wayland
ahmadraniri[m] has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #wayland
<pq>
emersion, oh, I thought you had a way to not need handle SIGBUS at all. E.g. sealed fds and pread() as fallback.
<emersion>
maybe there's a way
<emersion>
but i'm not sure i want to use that way
<emersion>
for GL uploads it may be easy enough
<emersion>
but for our pixman renderer it'll become painful
<pq>
DemiMarieObenour[m], we're been over the wl_shm validation in Gitlab, I believe.
<pq>
emersion, MAP_NOSIGBUS would sure be nice.
<emersion>
zzag: that was fast :D
<emersion>
i'll do a client impl
<emersion>
and wlroots too
ppascher has quit [Quit: Gateway shutdown]
<zzag>
heh it was easy one to implement because we had idle detection infra already prepared
<zzag>
implementing wl_surface.get_release may not be so easy peasy, but I didn't look into that yet tbh
<MrCooper>
just send out the pending wl_surface.get_release events at the same time as the old release event
<emersion>
yeah. and when you gain infra for explicit-sync maybe you can send them earlier
<emersion>
but it's not a big deal
<MrCooper>
what's the connection with explicit sync?
<emersion>
explicit sync brings your compositor closer to the wl_surface.get_release() model
<emersion>
for instance, weston has a "buffer release" object
<MrCooper>
the client still can't reuse the buffer before the compositor stops using it though
<emersion>
it gets passed on to the KMS atomic commit function for instance
<emersion>
MrCooper: wl_surface.get_release indicates when the usage for the commit no longer needs to access the buffer
<emersion>
if there is another usage at the same time, the client must wait for that one as well
<emersion>
it would be the same if you used the same KMS FB on two CRTCs, for instance
<MrCooper>
let me rephrase: the client needs to keep a reference count of pending wl_surface.get_release events, and can only reuse the buffer when it drops to 0; so what difference does it make if some of them are sent earlier?
<emersion>
it doesn't -- but it might be easier to implement that way once you support explicit sync
<MrCooper>
k
<emersion>
but both are correct, from a protocol spec PoV
<MrCooper>
the compositor still needs to keep track of when to send the old release event though, just sending all pending new events at that point seems pretty simple
<emersion>
yes, it depends how your internal compositor architecture is
<emersion>
ah, and one more thing
<emersion>
wl_buffer.release is undefined when the buffer is used multiple times
<emersion>
so it would also be valid for a compositor to send wl_buffer.release without any kind of ref'counting, afaik
<MrCooper>
that seems like a cop-out to me
<emersion>
> If a pending wl_buffer has been committed to more than one wl_surface the delivery of wl_buffer.release events becomes undefined.
<emersion>
well
fmuellner has joined #wayland
<MrCooper>
yeah I read that, but it's not really hard for the compositor to send it only when it's actually not using the buffer anymore
<emersion>
weston and mutter diverge on this
<MrCooper>
if it can't do that, the new events won't help either
<emersion>
mutter sends one release event, weston sends two
<emersion>
iirc
<emersion>
hm, not sure what you mean?
<zubzub>
protocol says: "If a pending wl_buffer has been committed to more than one wl_surface,
<zubzub>
the delivery of wl_buffer.release events becomes undefined. A well
<zubzub>
behaved client should not rely on wl_buffer.release events in this
<zubzub>
case. Alternatively, a client could create multiple wl_buffer objects
<zubzub>
from the same backing storage or use wp_linux_buffer_release.
<zubzub>
so don't do that I guess?
<clever>
this convo also reminds me of the vchiq api, whenever you import a dma_buf into the VPU firmware, it gives you a new handle for that specific import
<MrCooper>
emersion: if the compositor knows when it can send out the new events, it also knows when it's not using the buffer for anything anymore, at which point it can send the old event; sending the old event before that seems silly
<clever>
you can then use that handle in other api's, and youll get a release with that id later
<clever>
so if you import the same buffer twice, you get 2 unique handles, and each gets released exactly once
ecloud_ has quit [Read error: No route to host]
<emersion>
MrCooper: well, i don't know. wl_buffer.release is not really defined in that case.
<MrCooper>
which I consider a cop-out for lazy compositors :)
<emersion>
i don't know whether it's more sane to wait for all usage to be done, or to send multiple release events
ecloud has joined #wayland
<emersion>
one could argue that only sending one event is "lazy"
<emersion>
which is why we've decided to make it undefined
<MrCooper>
emersion: "Sent when this wl_buffer is no longer used by the compositor", seems pretty clear to me
<emersion>
sorry, it's not for me
<emersion>
but anyways, it doesn't really matter either way
<MrCooper>
how does sending the event while the buffer is still attached to a surface not violate that?
devilhorns has joined #wayland
<emersion>
is it "no longer used [by a particular wl_surface]", or "no longer used [by any wl_surface]"?
<MrCooper>
I quoted the full spec sentence
<emersion>
yes, and the bracketed part is missing
<emersion>
which means it ambiguous
<MrCooper>
how can it be "not used by the compositor" while it's attached to any surface?
<emersion>
well, time to argue about that is long passed
<MrCooper>
the new event is needed to solve the race, not really to clarify this
<emersion>
we have real-world compositor impls doing what you argue is "lazy"
<pq>
MrCooper, problem is not that the compositor wouldn't know when it's done with a buffer. The problem is that the singular release event races agains futher client requests making the same buffer busy *again*.
<emersion>
so we can't break them
<MrCooper>
pq: beat you by 19 seconds :)
<pq>
that's the reason for that wording in the release event spec
fahien has joined #wayland
audgirka has joined #wayland
<pq>
The original wl_buffer.release event is indeed a global one, because the buffer has no idea about any surfaces. So the event is sent when the compositor has no use for it globally.
<pq>
IOW, no longer used by *any* wl_surface.
<emersion>
but weston doesn't do that?
<pq>
I believe it does.
<pq>
the whole buffer reference counting thing is for that
<emersion>
the discussions dating a few years back say it's sending two release events, if you attach twice
<pq>
that would have been the sane definition, but it's not what we had
<emersion>
maybe it sends two release events, but at the right time?
<emersion>
well, i'm too lazy to check the source
<pq>
because of the protocol race, a client cannot tell if it's going to get one or two release events if it attach+commits the same buffer to two wl_surfaces.
<pq>
if the protocol intended and guaranteed that each attach+commit results in exactly one release event, then there would be no problem at all.