libweston as a DRM lease lessee

[Damian Hobson-Garcia]

On 2021/02/02 18:28, Pekka Paalanen wrote:
> On Tue, 2 Feb 2021 00:39:30 +0900
> Damian Hobson-Garcia <dhobsong at igel.co.jp> wrote:
>
>> 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.
> Are you referring to not having access to udev daemon (the udev
> properties mechanism) in the container?
>
> If yes, there might be another problem below.
>
>>>>    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.
> Hotplug events are udev events, and traditionally they do not name any
> connetor or anything. They only say "something might have changed with
> this DRM device, it would be better for you to re-scan the whole
> device to see what changed". Weston implements this.

Oh, I was looking at the implementation of drm_backend_update_conn_props(),
which I'm guessing can respond to property changes on a connector, so 
maybe not
the traditional hotplug.

> I'm not exactly sure how those events are delivered, do you need a udev
> daemon running? Weston uses the udev_monitor API for it currently which
> I think requires udevd maybe?
>
> An alternative could be to deliver the equivalent of hotplug events
> through your DRM leasing protocol.

Yes, good point. Hotplug functionality isn't really mandatory right now, 
but I'll keep
this in mind for the future.

Actually, I think I misunderstood your original comment. The udev_device 
that I was
originally referring to is the one created during the DRM device discovery.
That one is used to initialize the backlight.

> I can't say anything for certain, but as a first try, I'd probably
> attempt writing a new launcher backend for weston, parallel to the
> existing launcher backends logind, weston-launch and direct. The device
> discovery code is not in
> the launcher backend but in the DRM-backend
> proper though, so I guess you indeed may need to do something about
> that.
> You seem to be on the right track from what I can tell.
>
> As for other use cases or running inside containers, nothing comes to
> my mind, but OTOH the concept of something like "a full desktop in a
> container" might be attractive to some? Or using a multi-head gfx card
> for multi-seat, to avoid needing to have one gfx card per seat.

Yes, the multi-head graphics for multi-seat is along the lines of what 
I'm looking to do.

Thanks again for your comments.
Damian

> Thanks,
> pq