DRM leasing
I'm working on implementing DRM leasing (and with it, VR support) and wanted to start the discussion here on how it should shake out. For those unaware, DRM leasing allows us to "lease" some DRM resources (connector, crtc, encoder) to another process, allowing us to share the DRM master. This is used by VR applications to have exclusive and low-latency control over the HMD (head mounted display). I think a comprehensive solution for VR on Wayland (and wlroots) involves the following broad steps, in no particular order:
- Expose the "non-desktop" flag to downstream compositors, so they can decide how to use non-desktop outputs (HMDs generally have this flag set, and are generally unsuitable for inclusion in the desktop layout). A typical compositor will not use this output at all, and will make it available for leasing. A VR compositor might seek out this output specifically to run its VR interface on. etc.
- Clean up and get merged the DRM leasing Wayland protocol extension. I have a cleaned up draft here for your consideration.
- Implement
wlr_drm_lease_manager_v1
. We could do this at a low-level or a high-level. The low-level API would involve expanding the public DRM backend API so that its users can enumerate our DRM resources and offer fine-grained leases of connectors, crtcs, and encoders separately. Until someone comes up with a use-case that demands this, I'd prefer a high-level approach: the downstream compositor just tellswlr_drm_lease_manager_v1
whichwlr_outputs
it would like to offer for leasing. This will still require some changes to the DRM backend to allow the lease manager to ask the backend to stop using certain resources, but it could just use the existing DRM backend headers to dig into DRM internals and since it all lives inside of wlroots (rather than downstream compositors), it simplifies the maintenance burden significantly.- In the high-level model, when a client takes you up on the lease offer, the backend will emit an
output_remove
event for thatwlr_output
, so you stop using it. It'll reappear if you revoke the lease, and you can still access it (though it'll be a programming error to mutate it) by browsing the list of leases.
- In the high-level model, when a client takes you up on the lease offer, the backend will emit an
At that point, we can write our own Wayland clients which take advantage of DRM leasing to provide a VR experience. I'll write some basic demo as part of this workstream. However, to be useful, we'll probably want it to work with OpenVR (which is a misnomer, because it's closed source) - this is what Steam uses. It only supports X11, so my plan is to extend Xwayland with support for the DRM leasing protocol. DRM leasing via X11 was added to xrandr 1.6.
In the long term, I want to expand wlroots to support VR compositors better. This will involve at least:
- Wayland protocols for rendering 3D content (hard)
- Wayland protocols for VR-specific HIDs - plus libinput/eudev support? Today these use libusb and bypass the input subsystem entirely