libweston as a DRM lease lessee

[Damian Hobson-Garcia]

On 2021/02/03 18:57, Pekka Paalanen wrote:
> On Wed, 3 Feb 2021 14:37:43 +0900
> Damian Hobson-Garcia <dhobsong at igel.co.jp> wrote:
>
>> 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].
> ...
>
>>>>>>     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.
> Yes, that's the improved hotplug event. It's otherwise the same as the
> traditional hotplug event except it carries two additional strings
> naming the connector and property that changed. It's still udev.

Right, I agree. The udev event issue is the main problem here.

>>> 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.
> Hotplug functionality seems quite essential in general, though.

Yes, that's true.  I was only thinking of my immediate needs, but yes, 
any general
implementation will definitely need to address the udev event issue.

Thanks again,
Damian

> Thanks,
> pq