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

[David Herrmann]

Hi

On Wed, Dec 4, 2013 at 7:54 PM, Ray Strode <rstrode at redhat.com> wrote:
>> 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.

No-one is working on a system-compositor and it is an orthogonal idea
to Session.TakeControl(). Both don't work together. Ubuntu tries to
introduce a system-compositor with Mir, but no-one tries to do that
with Wayland. The idea was dropped by all parties and is actually the
reason why we introduced Session.TakeControl() as replacement.

I don't want to discuss the pros/cons of system-compositors here.
Imho, there is no sane way to implement it and looking at Ubuntu and
the problems they're facing, I really think we're better off without
it.

>> Why undesirable? That's the way to go.
> 1) It will cause flicker

No it ain't. If you use DRM, you can run a smooth handover without
tearing, flicker or other artifacts. It's not obvious and not
documented at all (sadly), but it's possible. You simply avoid doing a
full/deep modeset on session activation but instead take-over where it
was left. Schedule your framebuffer for the next vblank and you will
see no artifacts. Obviously, if you need to change (pixel-)modes or
clock parameters, a full modeset is required. But that's always the
case, whether you use a system-compositor or not.

I'm actually working on some improved DRM ioctls to speed up getting
mode-information on activation. Currently it can take up to 200ms to
do that, which is awfully slow.

Note that you can even do blending on handover! FB handles are global
resources on DRM so the active Master can access previous buffers and
blend over.

> 2) It will mean there's always an X server with a login screen running in the background, even on single user systems.

You can shut down the greeter-session after login and re-create it
when required again.

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

I'm lost, sorry. So you are saying we should try it or not?

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

I skimmed through the gdm code but didn't find the pam-transaction for
the gdm user, only the one for the new sessions. Thanks for clarifying
that! It's the right thing to do, imho.

Thanks
David