libweston as a DRM lease lessee

Pekka Paalanen ppaalanen at gmail.com
Wed Feb 3 09:57:23 UTC 2021


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.

> > 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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210203/9ada1413/attachment-0001.sig>


More information about the wayland-devel mailing list