libweston as a DRM lease lessee

Wed Feb 3 06:26:48 UTC 2021

Hi Marius,

On 2021/02/02 19:51, Pekka Paalanen wrote:
> On Tue, 2 Feb 2021 12:41:17 +0200
> Marius Vlad <marius.vlad at collabora.com> wrote:
>
>> On Tue, Feb 02, 2021 at 11:28:46AM +0200, 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.
>>>
>>> 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.
>>>
>>> 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.
>> Would this mean modifying the launcher API to pass down a
>> file-descriptor directly, or would that happen in the launcher itself
>> (assuming that would be reason for writing a new launcher -- somehow use some
>> helpers to retrieve the lease fd in the container).

I think that you could just pass an identifier for the DRM lease you 
want to the launcher
backend with and get back the lease fd.  No changes
to the launcher API, or existing launcher backends would be necessary.

It would need a method to choose which launcher backend to use, though, 
which is
currently determined at the weston_launcher_connect() stage. Maybe 
adding a flag
in the API or based on the environment, like it is in the other backends?

Thank you,
Damian

>> Wouldn't be easier to just pass down the lease fd to the DRM-backend, as
>> config option, and handle the mapping itself in the compositor rather than in
>> libweston?
> I don't know. Figuring out where the API should be and what it should
> look like is the major unknown.
>
> DRM fd is one thing. Something needs to cater for input devices too.
> Also I don't know what their leasing protocol looks like, does it have
> dynamic revocation and re-creation without shutting down Weston.
>
> Thanks,
> pq
>
>>> 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.
>>>
>>>
>>> Thanks,
>>> pq
>>
>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel