libweston as a DRM lease lessee

[Damian Hobson-Garcia]

Hi Pekka,

Thank you for your comments.

On 2021/02/01 19:34, Pekka Paalanen wrote:
> On Mon, 1 Feb 2021 18:19:29 +0900
> Damian Hobson-Garcia <dhobsong at igel.co.jp> 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.
> Hi,
>
> that is an interesting goal. How will this "nested" Weston/DRM get
> input?

This is still uncertain.  One option is of course to bind mount input 
devices into the
container, but I know that there are problems with providing the
seat information that libinput needs (unless that has changed recently).
I haven't really looked into how to address that yet.

>>   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?
> Hmm, what would an udev_device be needed for? Hotplug events?

Yes, hotplug events.  My hope is that it would work that same as for the 
regular
DRM device nodes.  I guess that some modifications to the hotplug code 
may be
necessary to deal with events on connectors that are not included in the
DRM lease.

> Thanks,
> pq

Thank you,
Damian

>> 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
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel