On Thu, 14 Nov 2019 10:04:53 -0500 "Drew DeVault" <s...@cmpwn.com> wrote:
> On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote: > > > A hint is merely a hint. The compositor can abide or not by that. > > > This flag will explicitly close the client connection if the buffer > > > can't be scanned out when this flag is passed. > > > > This flag doesn't sound like a hint to me, but a hard requirement. From > > the discussion I saw on the MR [1], if we don't abide, we risk being > > killed. > > I agree: that's not a hint, it's a demand. All existing flags in zwp_linux_dmabuf are not hints either. If a compositor does not correctly implement each flag every time a client specifies one or more, the result is more or less incorrect. Hence all compositors must always reject all flags they do not recognize or implement. > I think that there would be value in being able to suggest that a > particluar buffer be scanned out for performance reasons. I think not, for the reasons Scott explained in his reply. > But, as a > suggestion, and not a demand, and definitely not for secrecy reasons. > wlroots-based compositors would reserve the right to read your buffers > whenever we want. If I want to read your buffer for a frame to take a > screenshot, it's not going to be the end of the world for performance > and I don't want to end up segfaulting because of it. A totally valid implementation is to always reject any dmabufs that attempt to have direct-display flag set. You can do that on any flag, too. You can also advertise zwp_linux_dmabuf and never accept any dmabuf at all. That is also a valid implementation, though not a very useful one. zwp_linux_dmabuf has the built-in assumption that the compositor can always reject creating a wl_buffer from a dmabuf for any reason or even just for the heck of it, because no-one can know in advance if a particular driver will actually accept a particular dmabuf or not. > Rather, this just seems to be a DRM-enabling change, and the official > policy of wlroots will always be to NACK those for the wp and xdg > namespaces. Very good. We will work with that. Thanks, pq
pgpMT8ARCvlun.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
