libweston as a DRM lease lessee

[Scott Anderson]

On 1/02/21 10:19 pm, Damian Hobson-Garcia wrote:
> Hi all,
> 
> I am working on adding DRM lease support to a libweston based compositor.
> The compositor will be a client (lessee) that will display output to a 
> DRM lease that
> is created by another (lessor) process, so this is kind of the opposite 
> direction to the DRM lease patches
> that were submitted a while back [1].
> 
> The motivation is to be able to run multiple instances of weston w/ DRM 
> backend, where each instance
> has direct access to a subset of the DRM connectors.  Each instance 
> could, for example, run in a separate container,
> with minimal host interaction.
> 
> In this configuration the DRM lease would be received from a UNIX domain 
> socket connection to the lessor,
> so would not discoverable via udev, in the same way that DRM device 
> nodes normally are.
> 
> I think that I would need to make changes to the compositor-drm, but if 
> possible,
> I'd like to make those changes generic enough to be useful upstream as 
> well, so I was hoping to get some feedback before possibly heading down 
> a wrong path.
> 
>  From what I can tell, I need to:
> 
> 1. Get the DRM lease file descriptor, given an identifier (In my DRM 
> lease case this is a name that maps to a socket path)
> 2. Get a udev_device struct for the device corresponding to the above fd 
> (via the major:minor numbers)
> 
> I think that #1 can be implemented in either via the launcher API (a new 
> launcher type?) or by adding an option for
> the compositor to provide the fd, but #2 seems like it should be in 
> compositor-drm, right?
> 
> Are there other use cases that would benefit from extending the launcher 
> / compostior APIs in this way?
> or the udev device handle creation? Are there any plans/interest for 
> running the DRM backend from inside
> a container?
> 
> Thank you,
> Damian
> 
> [1] 
> https://lists.freedesktop.org/archives/wayland-devel/2018-February/037162.html 

This doesn't answer any of your questions about Weston specifically, but 
an alternative approach would be to add drm-lease support to logind. It 
already has its own concept of groups of devices (seats), so it would 
also solve any issues regarding who gets what input devices, and the 
solution wouldn't be specific to weston. Any logind-capable display 
server (i.e. all of them, including Xorg) would be able to use this, 
without requiring any modification.

Scott