dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Troll Berserker <berserker.troll@yandex.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: RFE: DRM_IOCTL_MODE_EXPOSE_LEASE
Date: Sat, 22 Sep 2018 10:45:40 +0200	[thread overview]
Message-ID: <20180922084540.GJ11082@phenom.ffwll.local> (raw)
In-Reply-To: <cc63af16-689d-d70c-54c3-2eed3d8fa5e1@yandex.com>

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-09-22  8:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-22  2:55 RFE: DRM_IOCTL_MODE_EXPOSE_LEASE Troll Berserker
2018-09-22  8:45 ` Daniel Vetter [this message]
2018-09-22 13:34   ` Troll Berserker
2018-09-24 14:59     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180922084540.GJ11082@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=berserker.troll@yandex.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox