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].
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.
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.
Thanks,
pq
Thank you,
Damian
Are there other use cases that would benefit from extending the launcher
/ compostior APIs in this way?
or the udev device handle creation? Are there any plans/interest for
running the DRM backend from inside
a container?
Thank you,
Damian
[1]
https://lists.freedesktop.org/archives/wayland-devel/2018-February/037162.html
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel