On Tue, Feb 02, 2021 at 11:28:46AM +0200, 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]. > > >> > > >> 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. > > Are you referring to not having access to udev daemon (the udev > properties mechanism) in the container? > > If yes, there might be another problem below. > > > >> 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. > > 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. > > I can't say anything for certain, but as a first try, I'd probably > attempt writing a new launcher backend for weston, parallel to the > existing launcher backends logind, weston-launch and direct. The device > discovery code is not in the launcher backend but in the DRM-backend > proper though, so I guess you indeed may need to do something about > that. Would this mean modifying the launcher API to pass down a file-descriptor directly, or would that happen in the launcher itself (assuming that would be reason for writing a new launcher -- somehow use some helpers to retrieve the lease fd in the container).
Wouldn't be easier to just pass down the lease fd to the DRM-backend, as config option, and handle the mapping itself in the compositor rather than in libweston? > > You seem to be on the right track from what I can tell. > > As for other use cases or running inside containers, nothing comes to > my mind, but OTOH the concept of something like "a full desktop in a > container" might be attractive to some? Or using a multi-head gfx card > for multi-seat, to avoid needing to have one gfx card per seat. > > > Thanks, > pq > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
signature.asc
Description: PGP signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel