On Sat, Sep 22, 2018 at 04:34:03PM +0300, Troll Berserker wrote: > On 22/09/18 11:45, Daniel Vetter wrote: > > Hi, > > > > On Sat, Sep 22, 2018 at 05:55:00AM +0300, Troll Berserker wrote: > > > Goal: simplify multiseat support. > > > > Sounds like a neat idea to use leases for this. > > > A new parameter was added to the Xorg server to make it use a passed > > > file descriptor instead of /dev/dri/card*. This enables one to start > > > the Xorg server with leased FD. > > > Although it is possible to organize multiseat using this approach, it > > > does not integrate well with existing seat infrastructure (udev, > > > logind). > > > > Why does it not integrate well with logind? > > Without a /sys/ subtree for lease you can't create a new seat with > loginctl attach seat-X /sys/devices/... > logind filters non-graphic devices. > > > > It would be great to have a way to expose a DRM Lessee as /dev/dri/card* > > > node and relevant /sys nodes etc., which would enable one to write an > > > udev rule to create a new seat. This new node should represent leased > > > resources and *should support > > > DRM_IOCTL_SET_MASTER/DRM_IOCTL_DROP_MASTER* as if it were a "real" > > > device. > > > > Note that leases do not make _any_ guarantees about resource usage > > isolation. If one lease lights a high res screen and uses too much scanout > > bandwidth, the other lease won't be able to use it's output. This isn't > > really fixiable without rewriting all the drivers. The way it's solved is > > that the lessor can take away the lease anytime to shut up mis-behaving > > clients. So if you want multi-seat, you probably need someone to properly > > manage these leases for this reason. Not just dumb dev nodes.> The other > > issue with leases is that they're tied to the current owner > > (drm_master) of the device. If the owner switches, all leases switch too > > (and can't access the device anymore), e.g. when doing a vt-switch. As > > mentioned above, logind already does this, and compositors take their drm > > FD from logind. For multi-seat you probably don't want a user-switch on > > one seat to switch all seats, so I think this needs to be put into logind. > > I've studied the topic a bit and understand that there should be a daemon > starting before display managers holding master privileges for some > /dev/dri/card* device and managing leases. > For *multi*seat, one will have to create at least two leases because original > device would be busy. Yup, you need this already. Why can't it also handle multi-seat? Yes, logind needs to be changed, but I think you need to do that anyway. Because leases do _not_ give you perfect isolation between leases, so some oversight is needed. > > > Interface: DRM_IOCTL_MODE_EXPOSE_LEASE ioctl request to DRM Lessor with > > > lease FD as the ioctl parameter. > > > > Final issue I'm seeing: Kernel internals will pose some interesting > > lifetime issues, stuff like what happens when the lease is gone. Can you > > still open the device in that case? > > My view is that this should behave as if someone unplugged a USB-VGA dock. > I.e. the device shall disappear. > > Just first reactions, I think you need to supply more details here on what > > exactly the precise problem is you're trying to solve. > > The precise problem — organize multiseat with one GPU with multiple outputs. > Using logind infrastructure. > > I didn't try, but I think currently I would have to create seats artificially, > (because AFAIK display managers spawn a login screen per seat, not per screen) > for example, attaching /sys/devices/.../graphics/fb0 to the seat-1. > Or patch the logind to make it not filter card0/card0-HDMI-A-1 and other > /sys records for connectors. > Then write a xorg config defining layouts for seats. > And use intel driver with the ZaphodHeads option to be able to start > multiple Xorg servers at one GPU. > > With exposed leases this would be much easier to solve the task. I agree that leases sounds like a good tool here. I'm not sure that the ioctl you propose is the right thing to mesh this into logind. Afaik logind already wrestles drm device nodes with special code, so adding more special code for multi-seat shouldn't be a big deal. And would allow you to solve some of the problems I mentioned in a much cleaner fashion. E.g. you could have multi-user _and_ multi-seat and it would work correctly, with per-seat user switching. You can't do that with a kernel-only solution. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
