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

[Drew DeVault]

On Fri Nov 15, 2019 at 11:29 AM, Pekka Paalanen wrote:
> 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.

Yeah, but none of them are for DRM until now. That they are not hints
means that we must take care with what kinds of flags we add. There's an
implication here that clients ought to be afforded the privilege of
specifying that their buffers cannot be read, as some kind of tautology,
but I reject this, because the only obvious use-case is a malicious one.

We don't afford the client plenty of other privileges on Wayland, because
they'd be easily abused. There have been plenty of arguments against a
randr-esque protocol, for example, because clients could weaponize it
against users to screw up their desktop session. The same arguments
apply to this - it will be weaponized to prevent users from doing what
they want to with their computers.

> > 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.

Is that acknowledging that there are no use-cases for this other than
DRM?

> 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.

I understand that we can implement DRM protocols in a way which just
says no, but I'd rather just say no to implementing DRM protocols at
all. We implement linux-dmabuf for obvious reasons, but I would prefer
to have DRM features in a separate protocol that we can refuse to
implement, as a message that DRM is not tolerated on our software. We
design our software with the users interests in mind, not our customers.

> > 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.

We won't block this if implemented as a separate protocol in the ext
namespace. We will officially NACK it, but ext protocols can still be
standardized even if NACKed.

I think this is the most reasonable way forward with this change.