[systemd-devel] Rethinking getty and fast user switching

Colin Guthrie gmane at colin.guthr.ie
Fri Feb 17 08:00:49 PST 2012


I meant to bug Lennart and Kay about this at FOSDEM, but as it panned
out I didn't see much of you guys so never got the opportunity. So here
goes at an email based description of my thoughts.

As we're (Mageia) following the (somewhat old now) lead of Fedora by
starting X on tty1, and as I had to deal with the expected responses
from the stalwarts ("this is dumb, everyone knows graphics are on the
7th tty"... yeah because that's soooo obvious!), it got me thinking a
bit about what users should expect from this kind of thing.

Firstly, I accept that <ctrl>+<alt>+<fN> is fundamentally NOT the most
obvious thing for any newbie, but let's assume for a second that people
do discover this.

If you have your system setup for a server without a graphical display,
you expect all (well 1 through 6 anyway) ttys to be text logins. I think
this is uncontroversial.

Currently, if you have a graphical system, then tty1 will no longer be a
text login, but will instead become a graphical DM login screen (let's
discount autologin for now), but 2 through 6 will still be getty text

If you do a graphical fast user switch this will result in a tty1 and
tty7 being used for X instances. This is not the most intuitive for
people switching back and forth.

So, I propose the following changes:

 1. tty 1-6 is reserved for "appropriate" login agents.
 2. tty 7-9 are reserved for text logins.

By "appropriate" I mean dependant on the current systemd target. If you
are in multi-user.target, then it should be a getty text login, however
if you are in graphical.target, it should give you a shiny DM login screen.

I have spoken to Ray about this and he was generally supportive. He said
there is no way to get GDM to start on a specific tty at present but
said he would be willing to support that.

I think the changes needed at the systemd level are minimal (if any are
really needed). I guess the only real changes would be to have
appropriate template units (e.g. getty at tty1.service and friends) to make
it all work.

Off the top of my head (without really thinking too hard about it), I'd
think that we'd need two getty units - one that only works in
multi-user.target (or rather conflicts with graphical.target) and one
that works all the time. Something like this:

non-graphical-getty at tty[1-6].service (contains Conflicts: graphical.target)
prefdm at tty[1-6].service (contains Requires: graphical.target)
getty at tty[7-9].service (no changes to current impl).

This way systemd should magically enable the appropriate login screen
(on demand of course) depending on the configured target. Servers will
always have text logins, and those with graphical systems will always
get graphical logins. If a family are used to having specific users on
specific tty2 (e.g. Dad always uses tty1, Mum always uses tty2), then
Mum's reflex when she sits down will be to just hit ctrl+alt+f2. If Dad
had to reboot the machine for whatever reason, Mum will obviously find
she is no longer logged in, but can easily just type her username/pass
or swipe her finger, or get her eyeball lasered etc. and off she goes.

I guess I'm writing this mail to get opinions as to whether or not the
systemd side would be as simple as I suspect or if there would be

Is this something that the other distros would adopt and run with too (I
don't think it's something that would be beneficial to vary wildly) and
thus can we ship these template units upstream in systemd?

Are there complications with Wayland here - will user switching in
Wayland work with ctl+alt+Fn or will it be something that will have to
be done purely in software?

Thanks for any opinions, and if I've not explained things clearly,
apologies in advance.



Colin Guthrie

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

More information about the systemd-devel mailing list