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

[Ray Strode]

Hi,

----- Original Message -----
> 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.
We don't actually run the X server in a session at the moment.

> 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 think it might be better to wait on that until we have wayland and a system compositor.

> Why undesirable? That's the way to go.
1) It will cause flicker
2) It will mean there's always an X server with a login screen running in the background, even on single user systems.

I mean it's something we can consider, we even used to have code to do it (called "factory mode"), but I don't it's a
absolute given that we should do it at this point.

> 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.
gdm runs the greeter inside a logind session as a "gdm" user, too.  It does
this by invoking a minimal pam stack to open the session which runs pam_systemd.

The X server doesn't run inside the session at the moment though.

--Ray