[PATCH v2] unstable/drm-lease: DRM lease protocol support

[Philipp Zabel]

On Tue, 2019-07-02 at 13:30 -0400, Drew DeVault wrote:
> From: Marius Vlad <marius-cristian.vlad at nxp.com>
> 
> DRM leasing is a feature which allows the DRM master to "lease" a subset
> of its DRM resources to another DRM master via drmModeCreateLease, which
> returns a file descriptor for the new DRM master. We use this protocol
> to negotiate the terms of the lease and transfer this file descriptor to
> clients.
> 
> In less DRM-specific terms: this protocol allows Wayland compositors to
> give over their GPU resources (like displays) to a Wayland client to
> exclusively control.
> 
> The primary use-case for this is Virtual Reality headsets, which via the
> non-desktop DRM property are generally not used as desktop displays by
> Wayland compositors, and for latency reasons (among others) are most
> useful to games et al if they have direct control over the DRM resources
> associated with it. Basically, these are peripherals which are of no use
> to the compositor and may be of use to a client, but since they are tied
> up in DRM we need to use DRM leasing to get them into client's hands.
> 
> Signed-off-by: Marius Vlad <marius-cristian.vlad at nxp.com>
> Signed-off-by: Drew DeVault <sir at cmpwn.com>
> ---
>  Makefile.am                                  |   1 +
>  unstable/drm-lease/README                    |   5 +
>  unstable/drm-lease/drm-lease-unstable-v1.xml | 237 +++++++++++++++++++
>  3 files changed, 243 insertions(+)
>  create mode 100644 unstable/drm-lease/README
>  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
> 
> > I wonder if we should add the linux_ prefix here, just like
> > linux_dmabuf_unstable_v1. But maybe "drm" is enough (and maybe
> > linux_dmabuf_unstable_v1 should have been named drm_dmabuf_unstable_v1).
> 
> I went -1 on this, because more operating systems than just Linux
> support DRM. Let's reconsider it if/when we promote linux_dmabuf from
> unstable to stable.
> 
> > I think the protocol error enum is missing.
> 
> Addressed in this version.
> 
> > I'm not sure the client is in the best position to decide which
> > connectors to pick here.
> 
> This patch adds an event advertising the EDID of the connector. Given
> that this is already tied to DRM, this seems like a reasonable addition.
> I think this should give clients everything they need to make an
> informed decision on which connectors to pick.

IIRC Pekka had concerns last time about the potential burst of data when
large EDID blocks are sent for all connectors at the same time, but I
suppose in the common case they are rather small.

Between the "name" and the "edid" event, I think clients should have all
they need to make an informed decision which connectors to request a
lease for.

[...]
> > For example, if I have two simultaneously connected VR headsets, each
> > running their own VR client, how would the two clients each lease only
> > the non-desktop connector corresponding to their headset?
> 
> I imagine that the ideal case is that the VR clients would present their
> user with a list of available connectors (using the name or description
> events to provide names for them, or parsing the EDID and showing more
> detailed information), then letting the user sort it out. The worst case
> is that they issue conflicting requests, in which case the compositor
> will likely grant the first, withdraw offers for the leased connectors,
> and fail the second accordingly.

Yes, that should work. I assume the user will make a selection, either
via a GUI in a normal wayland client, or by way of moving or putting on
a headset.

regards
Philipp