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