xdg-toplevel-icon: buffer release semantics are undefined

See the issues listed in !269 (comment 2440392)

cc @mak

Even after looking at this for a while and looking at compositor code, I still do not understand what the issue even is and why it would be specific to xdg-toplevel-icon.

x-t-i mandates that the buffer must be kept alive on the client side for as long as the icon it is associated with is also alive on the client side. So, when the icon is assigned, the compositor receives a valid buffer, which at some point is destroyed by the client and marked as such. However, since the compositor still holds a reference to it, it will not be actually gone until the compositor discards the buffer as well.

This seems fairly well-defined to me and seems to work for compositors. There could be some ambiguity as to who "owns" the buffer, and keeping a client-destroyed buffer around might have some implications that I don't fully realize, but that would then be a fundamental issue with Wayland itself, which doesn't seem to have been a problem so far. If it is a generic problem with buffer management though, fixing it only in x-t-i would likely not cut it and it would make more sense to do so centrally.

wl_buffer is designed to be re-used. Clients may render their icons with a common buffer pool (re-using logic for other buffers). Right now, wl_buffer.release is undefined for xdg-toplevel-icon, and even if we wanted clients to never re-use buffers, it's not clearly specified in the spec at all. See the description of wl_surface.attach for an example of a wl_buffer.release behavior specification.

Thank you for the clarification! I'll work on this soon once I have a bit of time again, maybe in two weeks :-) It actually doesn't look too bad to resolve at first glance, and hopefully that is also actually the case.

@mak ping?

FWIW, ext-image-copy-capture just spec's that wl_buffer.release is unused.

Sorry, I wanted to do this way, way earlier, but personal life got in the way dramatically. I think I might be able to get to this this week(end), a solution like in ext-image-copy-capture is pretty much what I had in mind to propose :-)

The semantics of the image copy protocol are unrelated to this protocol and its usage (or not) of wl_buffer.release should have no impact on this issue.

Not allowing the buffer to ever be re-used (as you are saying) might be sensible or not.

mentioned in merge request !329 (closed)

mentioned in merge request !330 (merged)

mentioned in merge request !331 (merged)

mentioned in commit emersion/wayland-protocols@c4df317e

mentioned in commit emersion/wayland-protocols@6f5772fd

closed with commit 6f5772fd