On 2021/02/03 18:57, Pekka Paalanen wrote:
On Wed, 3 Feb 2021 14:37:43 +0900
Damian Hobson-Garcia <dhobs...@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 <dhobs...@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 <dhobs...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
