unstable/drm-lease: DRM lease protocol support

Submitted by Drew DeVault on June 27, 2019, 7:46 p.m.

Details

Message ID 20190627194627.19918-1-sir@cmpwn.com
State Superseded
Headers show
Series "unstable/drm-lease: DRM lease protocol support" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault June 27, 2019, 7:46 p.m.
From: Marius Vlad <marius-cristian.vlad@nxp.com>

Simple protocol extension to manage DRM lease. Based on the work by Keith
Packard in [1], respectively [2].

[1] https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9&id=62884cd386b876638720ef88374b31a84ca7ee5f

Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
Signed-off-by: Drew DeVault <sir@cmpwn.com>
---
This updates Marius's original patch series implementing DRM leasing for
Wayland. This cleans up the XML style, reworks resource lifetimes, adds
a little link to xdg-output, and a few other changes.

A server-side implementation of this protocol is under development and
available here:

https://github.com/swaywm/wlroots/pull/1730

I've also rigged up Keith Packard's kmscube fork to support leasing from
Wayland instead of X:

https://git.sr.ht/~sircmpwn/kmscube

Run `./kmscube -l` to test it. While doing the research for this
protocol there was also some discussions in wlroots which may be
insightful:

https://github.com/swaywm/wlroots/issues/1723

Background:

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.

Previously there were some musings about the security considerations.
This version of the protocol allows the compositor to consider the lease
request in its own time, perhaps presenting the user with a dialog to
consent to the lease. Additionally, leased connectors can be added and
removed at the compositor's whim, and race conditions have been
considered to avoid disagreement between the client and compositor as to
which connectors are available for lease - the compositor being the
ultimate authority.

In the coming weeks I intend to work on patches for Vulkan and Xwayland
adding support for this protocol, respectively to allow Vulkan clients
to utilize DRM leasing on Wayland and to allow X11 clients utilizing the
xrandr lease request[0] to fulfill their leases through Xwayland.

https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938

 Makefile.am                                  |   1 +
 unstable/drm-lease/README                    |   4 +
 unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++++++++++++++++++
 3 files changed, 208 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..d9fff89 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,6 +4,7 @@  unstable_protocols =								\
 	unstable/pointer-gestures/pointer-gestures-unstable-v1.xml		\
 	unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml		\
 	unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml			\
+	unstable/drm-lease/drm-lease-unstable-v1.xml				\
 	unstable/text-input/text-input-unstable-v1.xml				\
 	unstable/text-input/text-input-unstable-v3.xml				\
 	unstable/input-method/input-method-unstable-v1.xml			\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 0000000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@ 
+Linux DRM lease
+
+Maintainers:
+Marius Vlad <marius-cristian.vlad@nxp.com>
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 0000000..8f52021
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,203 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="drm_lease_unstable_v1">
+  <copyright>
+    Copyright © 2018 NXP
+    Copyright © 2019 Status Research &amp; Development GmbH.
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+
+  <interface name="zwp_drm_lease_manager_v1" version="1">
+    <description summary="lease manager">
+      This protocol is used by Wayland compositors which act as Direct
+      Renderering Manager (DRM) masters to lease DRM resources to Wayland
+      clients. Once leased, the compositor will not use the leased resources
+      until the lease is revoked or the client closes the file descriptor.
+
+      The lease manager is used to advertise connectors which are available for
+      leasing, and by the client to negotiate a lease request.
+
+      Warning! The protocol described in this file is experimental and
+      backward incompatible changes may be made. Backward compatible changes
+      may be added together with the corresponding interface version bump.
+      Backward incompatible changes are done by bumping the version number in
+      the protocol and interface names and resetting the interface version.
+      Once the protocol is to be declared stable, the 'z' prefix and the
+      version number in the protocol and interface names are removed and the
+      interface version number is reset.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroys the manager">
+        Destroys this zwp_drm_lease_manager_v1 object.
+
+        Destroying a bound zwp_drm_lease_manager_v1 while there are lease
+        requests still alive is illegal and will result in a protocol error.
+      </description>
+    </request>
+
+    <request name="create_lease_request">
+      <description summary="create a lease request object">
+        Creates a lease request object.
+
+        See the documentation for zwp_drm_lease_request_v1 for details.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_drm_lease_request_v1" />
+    </request>
+
+    <event name="connector">
+      <description summary="advertise connectors available for leases">
+        The compositor may choose to advertise 0 or more connectors which may be
+        leased to clients, and will use this event to do so. This object may be
+        passed into a lease request to lease that connector. See
+        zwp_drm_lease_request_v1.add_connector for details.
+
+        When this global is bound, the compositor will send all connectors
+        available for lease, but may send additional connectors at any time.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_drm_lease_connector_v1" />
+    </event>
+  </interface>
+
+  <interface name="zwp_drm_lease_connector_v1" version="1">
+    <description summary="a leasable DRM connector">
+      Represents a DRM connector which is available for lease. These objects are
+      created via zwp_drm_lease_manager_v1.connector, and should be passed into
+      lease requests via zwp_drm_lease_request_v1.add_connector.
+    </description>
+
+    <event name="name">
+      <description summary="name">
+        Sent to indicate the name of this connector. This will not change for
+        the duration of the Wayland session, but is not guaranteed to be
+        consistent between sessions.
+
+        If the compositor also supports zxdg_output_manager_v1, this name will
+        match the name of a zxdg_output_v1 object.
+      </description>
+      <arg name="name" type="string" summary="connector name" />
+    </event>
+
+    <event name="withdrawn">
+      <description summary="lease offer withdrawn">
+        Sent to indicate that the compositor will no longer honor requests for
+        DRM leases which include this connector. The client may still issue a
+        lease request including this connector, but the connector may not be
+        included in the issued lease.
+      </description>
+    </event>
+
+    <request name="release">
+      <description summary="release connector">
+        The client may send this request to indicate that it will not issue a
+        lease request for this connector. Clients are encouraged to send this
+        after receiving the "withdrawn" request so that the server can release
+        the resources associated with this connector offer.
+
+        It is a protocol error to call
+        zwp_drm_lease_request_v1.request_connector with this object, or to call
+        zwp_drm_lease_request_v1.submit on a lease which includes this
+        connector, after the connector has been released.
+      </description>
+    </request>
+  </interface>
+
+  <interface name="zwp_drm_lease_request_v1" version="1">
+    <description summary="DRM lease request">
+      A client that wishes to lease DRM resources will attach the list of
+      connectors advertised with zwp_drm_lease_manager_v1.connector that they
+      wish to lease, then use zwp_drm_lease_request_v1.submit to submit the
+      request.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroys the lease request object">
+        Indicates that the client will no longer use this lease request. It is a
+        protocol error to send any further requests for this object after
+        sending destroy.
+      </description>
+    </request>
+
+    <request name="request_connector">
+       <description summary="request a connector for this lease">
+         Indicates that the client would like to lease the given connector.
+         This must be called before zwp_drm_lease_request_v1.create. This is
+         only used as a suggestion, the compositor may choose to include any
+         resources in the lease it issues, or change the set of leased
+         resources at any time.
+       </description>
+       <arg name="connector" type="object"
+         interface="zwp_drm_lease_connector_v1" />
+    </request>
+
+    <request name="submit">
+       <description summary="submit the lease request">
+         Submits the lease request and creates a new zwp_drm_lease_v1 object.
+         After calling submit, issuing any other request than destroy is a
+         protocol error. Submitting a lease request with no connectors is a
+         protocol error.
+       </description>
+       <arg name="id" type="new_id" interface="zwp_drm_lease_v1" />
+    </request>
+  </interface>
+
+  <interface name="zwp_drm_lease_v1" version="1">
+    <description summary="a DRM lease">
+      A DRM lease object is used to transfer the DRM file descriptor to the
+      client and manage the lifetime of the lease.
+    </description>
+
+    <event name="lease_fd">
+      <description summary="shares the DRM file descriptor">
+        This event returns a file descriptor suitable for use with DRM-related
+        ioctls. The client should use drmModeGetLease to enumerate the DRM
+        objects which have been leased to them, which may not be the objects
+        they requested. The lease may have zero DRM objects.
+
+        The compositor may also issue and immediately revoke the lease if no
+        connectors are leasable.
+
+        It is a protocol error for the compositor to send this event more than
+        once for a given lease.
+      </description>
+      <arg name="leased_fd" type="fd" summary="leased DRM file descriptor" />
+    </event>
+
+    <event name="finish">
+      <description summary="sent when the lease has been revoked">
+        When the compositor revokes the lease, it will issue this event to
+        notify clients of the change. If the client requires a new lease, they
+        should destroy this resource and submit a new lease request. The
+        compositor will send no further events for this object after sending
+        the finish event.
+      </description>
+    </event>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroys the lease object">
+        The client should send this to indicate that it no longer wishes to use
+        this lease. The compositor should use drmModeRevokeLease on the
+        appropriate file descriptor, if necessary, then release this object. It
+        is a protocol error for the client to send any further requests for
+        this object after sending a destroy request.
+      </description>
+    </request>
+  </interface>
+</protocol>

Comments

Hi,

Thanks for your work! Here is a first round of comments.

On Thursday, June 27, 2019 10:46 PM, Drew DeVault <sir@cmpwn.com> wrote:
> From: Marius Vlad <marius-cristian.vlad@nxp.com>
>
> Simple protocol extension to manage DRM lease. Based on the work by Keith
> Packard in [1], respectively [2].
>
> [1] https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9&id=62884cd386b876638720ef88374b31a84ca7ee5f
>
> Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> ---
> This updates Marius's original patch series implementing DRM leasing for
> Wayland. This cleans up the XML style, reworks resource lifetimes, adds
> a little link to xdg-output, and a few other changes.
>
> A server-side implementation of this protocol is under development and
> available here:
>
> https://github.com/swaywm/wlroots/pull/1730
>
> I've also rigged up Keith Packard's kmscube fork to support leasing from
> Wayland instead of X:
>
> https://git.sr.ht/~sircmpwn/kmscube
>
> Run `./kmscube -l` to test it. While doing the research for this
> protocol there was also some discussions in wlroots which may be
> insightful:
>
> https://github.com/swaywm/wlroots/issues/1723
>
> Background:
>
> 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.

Maybe some of this can be integrated in the commit message.

> Previously there were some musings about the security considerations.
> This version of the protocol allows the compositor to consider the lease
> request in its own time, perhaps presenting the user with a dialog to
> consent to the lease. Additionally, leased connectors can be added and
> removed at the compositor's whim, and race conditions have been
> considered to avoid disagreement between the client and compositor as to
> which connectors are available for lease - the compositor being the
> ultimate authority.

We still need a way to identify the client. See
https://gitlab.freedesktop.org/wayland/weston/issues/206

>
> In the coming weeks I intend to work on patches for Vulkan and Xwayland
> adding support for this protocol, respectively to allow Vulkan clients
> to utilize DRM leasing on Wayland and to allow X11 clients utilizing the
> xrandr lease request[0] to fulfill their leases through Xwayland.
>
> https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938
>
>  Makefile.am                                  |   1 +
>  unstable/drm-lease/README                    |   4 +
>  unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++++++++++++++++++
>  3 files changed, 208 insertions(+)
>  create mode 100644 unstable/drm-lease/README
>  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 345ae6a..d9fff89 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -4,6 +4,7 @@ unstable_protocols =								\
>  	unstable/pointer-gestures/pointer-gestures-unstable-v1.xml		\
>  	unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml		\
>  	unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml			\
> +	unstable/drm-lease/drm-lease-unstable-v1.xml				\
>  	unstable/text-input/text-input-unstable-v1.xml				\
>  	unstable/text-input/text-input-unstable-v3.xml				\
>  	unstable/input-method/input-method-unstable-v1.xml			\
> diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
> new file mode 100644
> index 0000000..a25600c
> --- /dev/null
> +++ b/unstable/drm-lease/README
> @@ -0,0 +1,4 @@
> +Linux DRM lease
> +
> +Maintainers:
> +Marius Vlad <marius-cristian.vlad@nxp.com>

Drew, maybe you could add yourself as a maintainer too.

Is Marius Vlad still interested in being maintainer?

> diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml b/unstable/drm-lease/drm-lease-unstable-v1.xml
> new file mode 100644
> index 0000000..8f52021
> --- /dev/null
> +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
> @@ -0,0 +1,203 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="drm_lease_unstable_v1">

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

> +  <copyright>
> +    Copyright © 2018 NXP
> +    Copyright © 2019 Status Research &amp; Development GmbH.
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <interface name="zwp_drm_lease_manager_v1" version="1">
> +    <description summary="lease manager">
> +      This protocol is used by Wayland compositors which act as Direct
> +      Renderering Manager (DRM) masters to lease DRM resources to Wayland
> +      clients. Once leased, the compositor will not use the leased resources
> +      until the lease is revoked or the client closes the file descriptor.
> +
> +      The lease manager is used to advertise connectors which are available for
> +      leasing, and by the client to negotiate a lease request.
> +
> +      Warning! The protocol described in this file is experimental and
> +      backward incompatible changes may be made. Backward compatible changes
> +      may be added together with the corresponding interface version bump.
> +      Backward incompatible changes are done by bumping the version number in
> +      the protocol and interface names and resetting the interface version.
> +      Once the protocol is to be declared stable, the 'z' prefix and the
> +      version number in the protocol and interface names are removed and the
> +      interface version number is reset.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the manager">
> +        Destroys this zwp_drm_lease_manager_v1 object.
> +
> +        Destroying a bound zwp_drm_lease_manager_v1 while there are lease
> +        requests still alive is illegal and will result in a protocol error.

I think the protocol error enum is missing.

> +      </description>
> +    </request>
> +
> +    <request name="create_lease_request">
> +      <description summary="create a lease request object">
> +        Creates a lease request object.
> +
> +        See the documentation for zwp_drm_lease_request_v1 for details.
> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_drm_lease_request_v1" />
> +    </request>
> +
> +    <event name="connector">
> +      <description summary="advertise connectors available for leases">
> +        The compositor may choose to advertise 0 or more connectors which may be
> +        leased to clients, and will use this event to do so. This object may be
> +        passed into a lease request to lease that connector. See
> +        zwp_drm_lease_request_v1.add_connector for details.
> +
> +        When this global is bound, the compositor will send all connectors
> +        available for lease, but may send additional connectors at any time.

I'm not sure the client is in the best position to decide which connectors to
pick here.

Maybe it would be better for the client to say _why_ it needs a lease (e.g. it
needs the non-desktop connectors for VR) and let the compositor pick appropriate
connectors.

What would be other use-cases for DRM leases? Probably fullscreen games? If the
compositor advertizes both non-desktop outputs (for VR) and desktop outputs (for
games), how should the VR client pick the right output?

> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_drm_lease_connector_v1" />

There is a race with new connector objects. If the compositor sends a new
connector and the client destroys the manager at the same time, the connector
object is leaked.

A way out would be to define a "stop" request, to which the compositor would
reply with a "finished" event (and destroy the manager). An example of a
protocol using this mechanism is available here:
https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-output-management-unstable-v1.xml#L108

> +    </event>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_connector_v1" version="1">
> +    <description summary="a leasable DRM connector">
> +      Represents a DRM connector which is available for lease. These objects are
> +      created via zwp_drm_lease_manager_v1.connector, and should be passed into
> +      lease requests via zwp_drm_lease_request_v1.add_connector.
> +    </description>

This interface is missing a destructor request.

> +    <event name="name">
> +      <description summary="name">
> +        Sent to indicate the name of this connector. This will not change for
> +        the duration of the Wayland session, but is not guaranteed to be
> +        consistent between sessions.

Is this sent once when the object is created?

> +        If the compositor also supports zxdg_output_manager_v1, this name will
> +        match the name of a zxdg_output_v1 object.

non-desktop connectors won't be advertised via xdg-output. Other connectors may
or may not be advertised.

Any reason why "description" isn't sent too? If the client needs to ask the user
which output to pick, a description would be nice.

> +      </description>
> +      <arg name="name" type="string" summary="connector name" />
> +    </event>
> +
> +    <event name="withdrawn">
> +      <description summary="lease offer withdrawn">
> +        Sent to indicate that the compositor will no longer honor requests for
> +        DRM leases which include this connector. The client may still issue a
> +        lease request including this connector, but the connector may not be
> +        included in the issued lease.

I wonder if the lease request should just fail if this happens.

> +      </description>
> +    </event>
> +
> +    <request name="release">

Generally this is called "destroy". "release" is only used when we need not to
break backwards compatibility.

> +      <description summary="release connector">
> +        The client may send this request to indicate that it will not issue a
> +        lease request for this connector. Clients are encouraged to send this
> +        after receiving the "withdrawn" request so that the server can release
> +        the resources associated with this connector offer.
> +
> +        It is a protocol error to call
> +        zwp_drm_lease_request_v1.request_connector with this object, or to call
> +        zwp_drm_lease_request_v1.submit on a lease which includes this
> +        connector, after the connector has been released.

The protocol error isn't defined. If this request is supposed to destroy the
connector (type="destructor"), this paragraph isn't necessary.

> +      </description>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_request_v1" version="1">
> +    <description summary="DRM lease request">
> +      A client that wishes to lease DRM resources will attach the list of
> +      connectors advertised with zwp_drm_lease_manager_v1.connector that they
> +      wish to lease, then use zwp_drm_lease_request_v1.submit to submit the
> +      request.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the lease request object">
> +        Indicates that the client will no longer use this lease request. It is a
> +        protocol error to send any further requests for this object after
> +        sending destroy.

The last sentence is unnecessary since type="destructor".

> +      </description>
> +    </request>
> +
> +    <request name="request_connector">
> +       <description summary="request a connector for this lease">
> +         Indicates that the client would like to lease the given connector.
> +         This must be called before zwp_drm_lease_request_v1.create. This is

Would be nice to have a protocol error for this.

> +         only used as a suggestion, the compositor may choose to include any
> +         resources in the lease it issues, or change the set of leased
> +         resources at any time.

Does the DRM interface to change the set of leased resources exist?

> +       </description>
> +       <arg name="connector" type="object"
> +         interface="zwp_drm_lease_connector_v1" />
> +    </request>
> +
> +    <request name="submit">
> +       <description summary="submit the lease request">
> +         Submits the lease request and creates a new zwp_drm_lease_v1 object.
> +         After calling submit, issuing any other request than destroy is a
> +         protocol error. Submitting a lease request with no connectors is a
> +         protocol error.

Ditto, would be nice to have protocol error codes for these.

> +       </description>
> +       <arg name="id" type="new_id" interface="zwp_drm_lease_v1" />
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_v1" version="1">
> +    <description summary="a DRM lease">
> +      A DRM lease object is used to transfer the DRM file descriptor to the
> +      client and manage the lifetime of the lease.
> +    </description>
> +
> +    <event name="lease_fd">
> +      <description summary="shares the DRM file descriptor">
> +        This event returns a file descriptor suitable for use with DRM-related
> +        ioctls. The client should use drmModeGetLease to enumerate the DRM
> +        objects which have been leased to them, which may not be the objects
> +        they requested. The lease may have zero DRM objects.
> +
> +        The compositor may also issue and immediately revoke the lease if no
> +        connectors are leasable.

Is this event sent in this case?

> +        It is a protocol error for the compositor to send this event more than
> +        once for a given lease.
> +      </description>
> +      <arg name="leased_fd" type="fd" summary="leased DRM file descriptor" />
> +    </event>
> +
> +    <event name="finish">

We generally use the past tense for this kind of events: s/finish/finished/

> +      <description summary="sent when the lease has been revoked">
> +        When the compositor revokes the lease, it will issue this event to
> +        notify clients of the change. If the client requires a new lease, they
> +        should destroy this resource and submit a new lease request. The

s/resource/object/

> +        compositor will send no further events for this object after sending
> +        the finish event.
> +      </description>
> +    </event>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the lease object">
> +        The client should send this to indicate that it no longer wishes to use
> +        this lease. The compositor should use drmModeRevokeLease on the
> +        appropriate file descriptor, if necessary, then release this object. It
> +        is a protocol error for the client to send any further requests for
> +        this object after sending a destroy request.

Ditto regarding the unnecessary last sentence.

> +      </description>
> +    </request>
> +  </interface>
> +</protocol>
> --
> 2.22.0
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Cc'ing Marius Vlad again, hopefully with a working e-mail address now.
<marius-cristian.vlad@nxp.com> is defunct.

> From: Marius Vlad <marius-cristian.vlad@nxp.com>
>
> Simple protocol extension to manage DRM lease. Based on the work by Keith
> Packard in [1], respectively [2].
>
> [1] https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9&id=62884cd386b876638720ef88374b31a84ca7ee5f
>
> Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> ---
> This updates Marius's original patch series implementing DRM leasing for
> Wayland. This cleans up the XML style, reworks resource lifetimes, adds
> a little link to xdg-output, and a few other changes.
>
> A server-side implementation of this protocol is under development and
> available here:
>
> https://github.com/swaywm/wlroots/pull/1730
>
> I've also rigged up Keith Packard's kmscube fork to support leasing from
> Wayland instead of X:
>
> https://git.sr.ht/~sircmpwn/kmscube
>
> Run `./kmscube -l` to test it. While doing the research for this
> protocol there was also some discussions in wlroots which may be
> insightful:
>
> https://github.com/swaywm/wlroots/issues/1723
>
> Background:
>
> 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.
>
> Previously there were some musings about the security considerations.
> This version of the protocol allows the compositor to consider the lease
> request in its own time, perhaps presenting the user with a dialog to
> consent to the lease. Additionally, leased connectors can be added and
> removed at the compositor's whim, and race conditions have been
> considered to avoid disagreement between the client and compositor as to
> which connectors are available for lease - the compositor being the
> ultimate authority.
>
> In the coming weeks I intend to work on patches for Vulkan and Xwayland
> adding support for this protocol, respectively to allow Vulkan clients
> to utilize DRM leasing on Wayland and to allow X11 clients utilizing the
> xrandr lease request[0] to fulfill their leases through Xwayland.
>
> https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938
>
>  Makefile.am                                  |   1 +
>  unstable/drm-lease/README                    |   4 +
>  unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++++++++++++++++++
>  3 files changed, 208 insertions(+)
>  create mode 100644 unstable/drm-lease/README
>  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 345ae6a..d9fff89 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -4,6 +4,7 @@ unstable_protocols =								\
>  	unstable/pointer-gestures/pointer-gestures-unstable-v1.xml		\
>  	unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml		\
>  	unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml			\
> +	unstable/drm-lease/drm-lease-unstable-v1.xml				\
>  	unstable/text-input/text-input-unstable-v1.xml				\
>  	unstable/text-input/text-input-unstable-v3.xml				\
>  	unstable/input-method/input-method-unstable-v1.xml			\
> diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
> new file mode 100644
> index 0000000..a25600c
> --- /dev/null
> +++ b/unstable/drm-lease/README
> @@ -0,0 +1,4 @@
> +Linux DRM lease
> +
> +Maintainers:
> +Marius Vlad <marius-cristian.vlad@nxp.com>
> diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml b/unstable/drm-lease/drm-lease-unstable-v1.xml
> new file mode 100644
> index 0000000..8f52021
> --- /dev/null
> +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
> @@ -0,0 +1,203 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="drm_lease_unstable_v1">
> +  <copyright>
> +    Copyright © 2018 NXP
> +    Copyright © 2019 Status Research &amp; Development GmbH.
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <interface name="zwp_drm_lease_manager_v1" version="1">
> +    <description summary="lease manager">
> +      This protocol is used by Wayland compositors which act as Direct
> +      Renderering Manager (DRM) masters to lease DRM resources to Wayland
> +      clients. Once leased, the compositor will not use the leased resources
> +      until the lease is revoked or the client closes the file descriptor.
> +
> +      The lease manager is used to advertise connectors which are available for
> +      leasing, and by the client to negotiate a lease request.
> +
> +      Warning! The protocol described in this file is experimental and
> +      backward incompatible changes may be made. Backward compatible changes
> +      may be added together with the corresponding interface version bump.
> +      Backward incompatible changes are done by bumping the version number in
> +      the protocol and interface names and resetting the interface version.
> +      Once the protocol is to be declared stable, the 'z' prefix and the
> +      version number in the protocol and interface names are removed and the
> +      interface version number is reset.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the manager">
> +        Destroys this zwp_drm_lease_manager_v1 object.
> +
> +        Destroying a bound zwp_drm_lease_manager_v1 while there are lease
> +        requests still alive is illegal and will result in a protocol error.
> +      </description>
> +    </request>
> +
> +    <request name="create_lease_request">
> +      <description summary="create a lease request object">
> +        Creates a lease request object.
> +
> +        See the documentation for zwp_drm_lease_request_v1 for details.
> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_drm_lease_request_v1" />
> +    </request>
> +
> +    <event name="connector">
> +      <description summary="advertise connectors available for leases">
> +        The compositor may choose to advertise 0 or more connectors which may be
> +        leased to clients, and will use this event to do so. This object may be
> +        passed into a lease request to lease that connector. See
> +        zwp_drm_lease_request_v1.add_connector for details.
> +
> +        When this global is bound, the compositor will send all connectors
> +        available for lease, but may send additional connectors at any time.
> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_drm_lease_connector_v1" />
> +    </event>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_connector_v1" version="1">
> +    <description summary="a leasable DRM connector">
> +      Represents a DRM connector which is available for lease. These objects are
> +      created via zwp_drm_lease_manager_v1.connector, and should be passed into
> +      lease requests via zwp_drm_lease_request_v1.add_connector.
> +    </description>
> +
> +    <event name="name">
> +      <description summary="name">
> +        Sent to indicate the name of this connector. This will not change for
> +        the duration of the Wayland session, but is not guaranteed to be
> +        consistent between sessions.
> +
> +        If the compositor also supports zxdg_output_manager_v1, this name will
> +        match the name of a zxdg_output_v1 object.
> +      </description>
> +      <arg name="name" type="string" summary="connector name" />
> +    </event>
> +
> +    <event name="withdrawn">
> +      <description summary="lease offer withdrawn">
> +        Sent to indicate that the compositor will no longer honor requests for
> +        DRM leases which include this connector. The client may still issue a
> +        lease request including this connector, but the connector may not be
> +        included in the issued lease.
> +      </description>
> +    </event>
> +
> +    <request name="release">
> +      <description summary="release connector">
> +        The client may send this request to indicate that it will not issue a
> +        lease request for this connector. Clients are encouraged to send this
> +        after receiving the "withdrawn" request so that the server can release
> +        the resources associated with this connector offer.
> +
> +        It is a protocol error to call
> +        zwp_drm_lease_request_v1.request_connector with this object, or to call
> +        zwp_drm_lease_request_v1.submit on a lease which includes this
> +        connector, after the connector has been released.
> +      </description>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_request_v1" version="1">
> +    <description summary="DRM lease request">
> +      A client that wishes to lease DRM resources will attach the list of
> +      connectors advertised with zwp_drm_lease_manager_v1.connector that they
> +      wish to lease, then use zwp_drm_lease_request_v1.submit to submit the
> +      request.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the lease request object">
> +        Indicates that the client will no longer use this lease request. It is a
> +        protocol error to send any further requests for this object after
> +        sending destroy.
> +      </description>
> +    </request>
> +
> +    <request name="request_connector">
> +       <description summary="request a connector for this lease">
> +         Indicates that the client would like to lease the given connector.
> +         This must be called before zwp_drm_lease_request_v1.create. This is
> +         only used as a suggestion, the compositor may choose to include any
> +         resources in the lease it issues, or change the set of leased
> +         resources at any time.
> +       </description>
> +       <arg name="connector" type="object"
> +         interface="zwp_drm_lease_connector_v1" />
> +    </request>
> +
> +    <request name="submit">
> +       <description summary="submit the lease request">
> +         Submits the lease request and creates a new zwp_drm_lease_v1 object.
> +         After calling submit, issuing any other request than destroy is a
> +         protocol error. Submitting a lease request with no connectors is a
> +         protocol error.
> +       </description>
> +       <arg name="id" type="new_id" interface="zwp_drm_lease_v1" />
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_drm_lease_v1" version="1">
> +    <description summary="a DRM lease">
> +      A DRM lease object is used to transfer the DRM file descriptor to the
> +      client and manage the lifetime of the lease.
> +    </description>
> +
> +    <event name="lease_fd">
> +      <description summary="shares the DRM file descriptor">
> +        This event returns a file descriptor suitable for use with DRM-related
> +        ioctls. The client should use drmModeGetLease to enumerate the DRM
> +        objects which have been leased to them, which may not be the objects
> +        they requested. The lease may have zero DRM objects.
> +
> +        The compositor may also issue and immediately revoke the lease if no
> +        connectors are leasable.
> +
> +        It is a protocol error for the compositor to send this event more than
> +        once for a given lease.
> +      </description>
> +      <arg name="leased_fd" type="fd" summary="leased DRM file descriptor" />
> +    </event>
> +
> +    <event name="finish">
> +      <description summary="sent when the lease has been revoked">
> +        When the compositor revokes the lease, it will issue this event to
> +        notify clients of the change. If the client requires a new lease, they
> +        should destroy this resource and submit a new lease request. The
> +        compositor will send no further events for this object after sending
> +        the finish event.
> +      </description>
> +    </event>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroys the lease object">
> +        The client should send this to indicate that it no longer wishes to use
> +        this lease. The compositor should use drmModeRevokeLease on the
> +        appropriate file descriptor, if necessary, then release this object. It
> +        is a protocol error for the client to send any further requests for
> +        this object after sending a destroy request.
> +      </description>
> +    </request>
> +  </interface>
> +</protocol>
> --
> 2.22.0
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


On Thu, 2019-06-27 at 20:36 +0000, Simon Ser wrote:
[...]
> > +    <event name="connector">
> > +      <description summary="advertise connectors available for leases">
> > +        The compositor may choose to advertise 0 or more connectors which may be
> > +        leased to clients, and will use this event to do so. This object may be
> > +        passed into a lease request to lease that connector. See
> > +        zwp_drm_lease_request_v1.add_connector for details.
> > +
> > +        When this global is bound, the compositor will send all connectors
> > +        available for lease, but may send additional connectors at any time.
> 
> I'm not sure the client is in the best position to decide which connectors to
> pick here.

The client may be the only one with enough knowledge to pick, see below.

> Maybe it would be better for the client to say _why_ it needs a lease (e.g. it
> needs the non-desktop connectors for VR) and let the compositor pick appropriate
> connectors.

How then would the desktop compositor decide which of the non-desktop
connectors the client requires?

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?

> What would be other use-cases for DRM leases? Probably fullscreen games?

One use case I'd like would be presentation software, where tagging the
projector as non-desktop beforehand would avoid spilling the desktop
onto the presentation display upon connection, before the presentation
is started.

> If the compositor advertizes both non-desktop outputs (for VR) and
> desktop outputs (for games), how should the VR client pick the right
> output?

Depending on the hardware and setup, the VR client may match the serial
number contained in the EDID with one retrieved via USB to identify the
correct connector to render to a given VR headset, or it may just
compare the vendor and product id. In a CAVE setup the client may have
manual configuration telling it which projectors to render to, so I
think the client needs access to at least the uniquely identifying parts
of the EDID.

regards
Philipp

On Friday, June 28, 2019 10:51 AM, Marius Vlad <marius.vlad@collabora.com> wrote:
> >> +    <event name="connector">
> >> +      <description summary="advertise connectors available for leases">
> >> +        The compositor may choose to advertise 0 or more connectors which may be
> >> +        leased to clients, and will use this event to do so. This object may be
> >> +        passed into a lease request to lease that connector. See
> >> +        zwp_drm_lease_request_v1.add_connector for details.
> >> +
> >> +        When this global is bound, the compositor will send all connectors
> >> +        available for lease, but may send additional connectors at any time.
> >
> > I'm not sure the client is in the best position to decide which connectors to
> > pick here.
>
> If you assume connectors are (always) dynamic, they can appear and
> disappear at will (which is the real world). My initial take on this was
> to limit which connectors to advertise using the configuration file,
> idea being that the connectors advertised are already vouched by the
> compositor, but doesn't play that nicely with the idea of connectors
> appearing and disappearing.
>
> > Maybe it would be better for the client to say _why_ it needs a lease (e.g. it
> > needs the non-desktop connectors for VR) and let the compositor pick appropriate
> > connectors.
> >
> > What would be other use-cases for DRM leases? Probably fullscreen games? If the
> > compositor advertizes both non-desktop outputs (for VR) and desktop outputs (for
> > games), how should the VR client pick the right output?
>
> Testing. The ability to run 2 applications simultaneously was the
> initial use case for us, even though we didn't had any kind input for
> it. For instance I imagine intel-ci BAT running a bit faster (at least
> for some of the tests). dEQP was our candidate for speeding it things a
> bit and an internal testing framework. Showcasing.

I don't think we can run BAT faster, because we rely on dmesg, which is global
state.

> Maybe include the/a kind of connector type (based on that property -
> !non_desktop && non_desktop) besides the name of the connector. This
> combined with the connector name might provide enough information for
> the client to choose the correct HMD?

See Philipp Zabel's reply.
On Friday, June 28, 2019 12:23 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > I'm not sure the client is in the best position to decide which connectors to
> > pick here.
>
> The client may be the only one with enough knowledge to pick, see below.
>
> > Maybe it would be better for the client to say why it needs a lease (e.g. it
> > needs the non-desktop connectors for VR) and let the compositor pick appropriate
> > connectors.
>
> How then would the desktop compositor decide which of the non-desktop
> connectors the client requires?
>
> 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?

[…]

> > If the compositor advertizes both non-desktop outputs (for VR) and
> > desktop outputs (for games), how should the VR client pick the right
> > output?
>
> Depending on the hardware and setup, the VR client may match the serial
> number contained in the EDID with one retrieved via USB to identify the
> correct connector to render to a given VR headset, or it may just
> compare the vendor and product id. In a CAVE setup the client may have
> manual configuration telling it which projectors to render to, so I
> think the client needs access to at least the uniquely identifying parts
> of the EDID.

Indeed, that makes sense. So another idea that was floating around
would be to allow the client to get a lease FD with zero leased
resources, let it inspect the connectors via DRM properties, then
let the client request a particular connector ID and get a second
lease.

We could also expose make/model/serial instead. In any case, the
connector name probably won't help a lot.
On Friday, June 28, 2019 12:58 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Fri, 28 Jun 2019 11:23:53 +0200
> Philipp Zabel p.zabel@pengutronix.de wrote:
>
> > On Thu, 2019-06-27 at 20:36 +0000, Simon Ser wrote:
> >
> > > What would be other use-cases for DRM leases? Probably fullscreen games?
> >
> > One use case I'd like would be presentation software, where tagging the
> > projector as non-desktop beforehand would avoid spilling the desktop
> > onto the presentation display upon connection, before the presentation
> > is started.
>
> Hi,
>
> I don't think that is a good idea. Presentation software (Libreoffice,
> web browsers, Evince, ...) probably does not want to grow a whole DRM
> KMS backend just to be able to drive a projector.

I totally agree.

> It would be much better for compositors to handle presentation outputs
> specially on their own to not extend the normal desktop contents there,
> and have a simple dedicated extension for presentation software to put
> a wl_surface on a presentation output (if necessary, maybe xdg_output
> and fullscreening to a specific wl_output is already enough).
>
> There are much more categories of outputs than just "desktop" and
> "non-desktop". I would avoid extending and confusing the meaning of
> "non-desktop" from what it currently is in the Linux kernel.
>
> Personally I am sceptical that even non-VR games would really benefit
> from DRM leases, because games might want to switch between windowed and
> fullscreen, users might want to see desktop notifications sometimes,
> etc. and again the DRM KMS backend is not easy to write.
>
> VR apps at least can rely on a VR runtime that knows how to drive DRM
> KMS properly, and there the use of DRM leases is well justified.

Yes. +1 to all of this.
On Thursday, June 27, 2019 11:36 PM, Simon Ser <contact@emersion.fr> wrote:
> > Previously there were some musings about the security considerations.
> > This version of the protocol allows the compositor to consider the lease
> > request in its own time, perhaps presenting the user with a dialog to
> > consent to the lease. Additionally, leased connectors can be added and
> > removed at the compositor's whim, and race conditions have been
> > considered to avoid disagreement between the client and compositor as to
> > which connectors are available for lease - the compositor being the
> > ultimate authority.
>
> We still need a way to identify the client. See
> https://gitlab.freedesktop.org/wayland/weston/issues/206

I'm now wondering if DRM leasing is that much different from xdg-shell
set_fullscreen requests.

Is DRM leasing that much of a big deal regarding security? (Especially
if the compositor has a policy to lease only non-desktop outputs)

One thing I'm concerned about is buffers read access. Someone posted a
Weston patch [1] to remove framebuffers when switching VTs, because the
new master could potentially read them.

Would this type of thing be possible with DRM leases? Could a lessee
read buffers from the compositor's connectors?

[1]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/175
Hi Pekka,

On Fri, 2019-06-28 at 12:58 +0300, Pekka Paalanen wrote:
> On Fri, 28 Jun 2019 11:23:53 +0200
> Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > On Thu, 2019-06-27 at 20:36 +0000, Simon Ser wrote:
> > > What would be other use-cases for DRM leases? Probably fullscreen games?  
> > 
> > One use case I'd like would be presentation software, where tagging the
> > projector as non-desktop beforehand would avoid spilling the desktop
> > onto the presentation display upon connection, before the presentation
> > is started.
> 
> Hi,
> 
> I don't think that is a good idea. Presentation software (Libreoffice,
> web browsers, Evince, ...) probably does not want to grow a whole DRM
> KMS backend just to be able to drive a projector.
> 
> It would be much better for compositors to handle presentation outputs
> specially on their own to not extend the normal desktop contents there,
> and have a simple dedicated extension for presentation software to put
> a wl_surface on a presentation output (if necessary, maybe xdg_output
> and fullscreening to a specific wl_output is already enough).
>
> There are much more categories of outputs than just "desktop" and
> "non-desktop". I would avoid extending and confusing the meaning of
> "non-desktop" from what it currently is in the Linux kernel.
> 
> Personally I am sceptical that even non-VR games would really benefit
> from DRM leases, because games might want to switch between windowed and
> fullscreen, users might want to see desktop notifications sometimes,
> etc. and again the DRM KMS backend is not easy to write.
> 
> VR apps at least can rely on a VR runtime that knows how to drive DRM
> KMS properly, and there the use of DRM leases is well justified.

I can't argue with this, all of it makes sense.

Another possible use case could be applications for special purpose
displays like the Looking Glass lenticular displays, or anything that we
know for sure the Wayland compositor or normal Desktop applications
won't be able to produce meaningful content for.

regards
Philipp