Using systemd-logind Session.TakeControl() from Xorg, input needed

[David Herrmann]

Hi

On Wed, Dec 4, 2013 at 2:32 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi All,
>
> I've been looking into using systemd-logind Session.TakeControl()
> and friends from the xserver, so that the xserver can let
> logind open/close the device nodes for it, and then hopefully
> will no longer need root rights.
>
> Sofar I've mainly been finding investigating / finding my way around
> the xserver.
>
> So today I was ready to start adding some initial code for this to
> the Xserver, only to immediately hit a roadblock :|
>
> Hence this mail I'm looking for input on how to solve the problems
> I've found sofar. Below I try to explain the 2 problems I see and
> I ask a few initial questions about them. Your input on this is
> very much appreciated.
>
> Problem 1:
> 1) TakeControl() works on a session, so the xserver will need to find
> the session it is to serve and then TakeControl of that session.
>
> Questions about problem 1:
> * Does gdm create the session before starting X ?

No. gdm uses a single Xserver for the login-screen and for the
session. But once you log in multiple times, I think it starts a new
Xserver for each. But I am not that familiar with gdm..

> * Can gdm pass in the session id, or the pid of the session leader
>   to X when starting X ?

Just use sd_pid_get_session(). It's in systemd/sd-login.h. It returns
the session ID of a given process. Don't pass session-ids around.

> Problem 2:
> 2) When switching from the "gdm" session to the user login session
> a new session gets created. For this to work we either need to
> start a new X, or X needs to deal with the session going away,
> and another one showing up. Dealing with this means releasing
> all devices including the drm node and then re-opening it when
> X gets the new session.

Start one Xserver for each session. Yes, blending and other transition
effects will get very hard to implement then, but still better than
sharing an xserver between sessions..

I have some ideas how to do transition effects between compositors,
but haven't come around to implement it. I'd recommend just not doing
any effects for now.

> Questions about problem 2:
> * I know starting a new X for the user-session is undesirable,
> but is it a blocker ?

Why undesirable? That's the way to go.

> * How feasible is it to make X deal with the drm node going away,
> without fully invoking the entire switch vt logic ?

I don't see why that's needed. We should just stop sharing Xservers.

I am currently working on systemd to provide basic fallbacks for all
this. See here:
  http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console
Especially the commit "gfx: add monitor". I rebase that branch quite
often so commit-ids are useless..

systemd-consoled is an example how graphics applications work with
TakeControl()/TakeDevice(). It expects to be run inside a session, so
the session has to be setup by the parent beforehand.
systemd-welcomed is an example how login-screens can work. It spawns a
separate process for the greeter and one for each session. Note that
the greeter runs as user "nobody" *inside* of a systemd-logind
session. So it's the same as any other session. Not like gdm which
treats the greeter special.
systemd-welcomed is still under development, but systemd-consoled already works.

You might also want to look at weston-git/src/logind-util.c which
implements this for weston. It differs from systemd-consoled as it
doesn't support multiple GPUs (which consoled/welcomed do!).

Thanks
David