[PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Pekka Paalanen]

On Thu, 14 Nov 2019 10:04:53 -0500
"Drew DeVault" <sir at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191115/e57d8b5c/attachment-0001.sig>