WIP: unstable/drm-lease: DRM lease protocol support (help wanted)
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.vlad@collabora.com Signed-off-by: Drew DeVault sir@cmpwn.com
I'm mainly uploading the patch on GitLab for visibility. Marius and Drew have stopped working on this. Let me know if you're interested to step up.
There are unresolved discussions on the mailing list.
- Patchwork: https://patchwork.freedesktop.org/patch/339386/?series=62884&rev=8
- Mailing list archives: https://lists.freedesktop.org/archives/wayland-devel/2019-November/040980.html
WIP implementations:
- wlroots: https://github.com/swaywm/wlroots/pull/1730
- Xwayland: xorg/xserver!248 (closed)
- Vulkan extension: https://github.com/KhronosGroup/Vulkan-Docs/pull/1001
- Mesa: mesa/mesa!1509 (closed)
- xrgears demo: https://git.sr.ht/~sircmpwn/xrgears
- Monado: monado/monado!141 (closed)
Merge request reports
Activity
added New Protocol label
I have written a implementation for KWin (not up for review yet) and I'm generally interested into helping with this.
I'm not overly qualified (never really did anything with wayland protocols) but aside from some small complaints about the exact protocol (that I'll add here later today) I think the overall design is good.
- unstable/drm-lease/drm-lease-unstable-v1.xml 0 → 100644
37 leasing, and by the client to negotiate a lease request. 38 39 Warning! The protocol described in this file is experimental and 40 backward incompatible changes may be made. Backward compatible changes 41 may be added together with the corresponding interface version bump. 42 Backward incompatible changes are done by bumping the version number in 43 the protocol and interface names and resetting the interface version. 44 Once the protocol is to be declared stable, the 'z' prefix and the 45 version number in the protocol and interface names are removed and the 46 interface version number is reset. 47 </description> 48 49 <enum name="error"> 50 <entry name="stopped_device" value="0" 51 summary="request sent to a device which has been stopped"/> 52 </enum> - unstable/drm-lease/drm-lease-unstable-v1.xml 0 → 100644
141 The compositor will send this event to indicate the DRM ID which 142 represents the underlying connector which is being offered. Note that 143 the final lease may include additional object IDs, such as CRTCs and 144 planes. 145 </description> 146 <arg name="connector_id" type="int" summary="DRM Connector ID" /> 147 </event> 148 149 <event name="withdrawn"> 150 <description summary="lease offer withdrawn"> 151 Sent to indicate that the compositor will no longer honor requests for 152 DRM leases which include this connector. The client may still issue a 153 lease request including this connector, but the compositor will send 154 zwp_drm_lease_v1.finished without issuing a lease fd. 155 </description> 156 </event> Implementation: KWaylandServer, KWin
So how do we proceed here?
Someone needs to go through the discussions we had on the mailing list and address these. Then submit a new MR in this repo.
There were some open questions wrt. Xwayland integration as well, IIRC.
Another thing that would be desirable is to resume work on the Vulkan extension. We don't necessarily need the Vulkan extension to merge this protocol, however it would be unfortunate to settle on a protocol that ends up being incompatible with the Vulkan extension.
Edited by Simon SerSee !67 (merged)
mentioned in merge request !67 (merged)
This has been superseded by !67 (merged) which was recently merged, so closing.
