libweston as a DRM lease lessee

[Marius Vlad]

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 <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].
> > >>
> > >> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210202/54b776bc/attachment-0001.sig>