RFE: DRM_IOCTL_MODE_EXPOSE_LEASE

[Daniel Vetter]

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? Afaiui logind is already doing
the drm-specific VT-switching dance (because otherwise you can't run
compositors without root), and passes fd's around. Can't we extend this to
also handle leases?

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

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

Just first reactions, I think you need to supply more details here on what
exactly the precise problem is you're trying to solve.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch