[systemd-devel] Rethinking getty and fast user switching

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 20/02/12 16:54 did gyre and gimble:
> On Fri, 17.02.12 16:00, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 
>> 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
>> logins.
>>
>> 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.
> 
> What is currently implemented is more like this:
> 
> 1. On systems with graphical login: tty1 is always the DM
> 
> 2. On systems without graphical login: tty1 is always a getty

Yup.

> 3. On boot, on both kinds of systems: All ttys != tty1 are unallocated

OK, not quite what I get here - getty's are not fully hotplugged I
guess, but all the same, but I accept this is the most sensible setup
and I'll look at why I'm not getting this right now!

> 4. If via graphical fast user switching a new X sesison is oppened, the
>    first unallocated tty is taken

Yes, but this has to happen from a logged in (or logged in but locked)
user session in software...

> 5. If the user switches to tty2-tty6 and it is unallocated a getty will
>    be spawned on it. The maximum number of ttys this happens for is
>    configured in systemd-logind.conf.

Yeah it's basically this bit I want to change... rather than always
starting getty, it should start an "appropriate" login agent: i.e. getty
for when the current target is multi-user.target, and gdm when it's
graphical.target.

> 6. tty1 is activated by default.

Yup, no change there either.

> I kinda like this scheme, since we waste no resources by default,
> i.e. don't start getty nor DM on any tty that wasn't in the
> foreground. 

The same would be true with the proposed changes.

> Also, we provide some compatibility with classic systems,
> since tty2-6 are text gettys, 

I don't think "some compatibility" really flies here.. either it's
compatible or it's not. Any change in the scheme is a change and will
annoy some people and please others. I think "some" compatibility is not
really worth it.

> if the user wants that, but if people use
> no text gettys at all and only graphical user switching they are all
> graphical logins instead.

Yeah but this scheme breaks down when "Mum" (in my previous example),
who *always* logs in on tty2 sits down at the (unknown to her, freshly
rebooted) machine and hits, ctrl+alt+f2. Rather than the locked session
screen she was expecting, a text login appears which she really didn't
expect and doesn't even know what to do with. Sure she may swtich back
to Dad's login on tty1, but if he's not logged in yet, then she'll get
tty1 and he'll have to use tty2 and that's just not how they normally do
things in that house... he's tty1 and she's tty2 and they both know that
and you can't open up another login screen from a greeter as that
doesn't really make sense in terms of software options. This way if all
the users of the house have a kind of pre-arranged agreement as to where
"their" session lives, they can do that very easily. No more "search for
the X" game as mentioned by Dax.


That's why, IMO, it would be much better if the login screen she got
when switching to tty2 for the first time was a gdm login prompt, not a
getty one. This would at least be familiar to her in some capacity. "Oh
I'm not logged in, never mind. <typety-type>. There I'm logged in".

IMO, this (quite small really) change would result in a much more
friendly user experience. The concept of "least surprise" is embodied
here too.

>> 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.
> 
> What happens if you want more than 6 parallel graphical sessions or more
> than 3 parallel text logins? 

The same thing that happens if there are more than 9 (or 12 maybe as F12
is available even if it's some what reserved perhaps?) - you're SoL...
but to be honest these "reservations" were really just discussion points
rather than any solid number I've carefully come up with. I only really
suggested some fixed text logins for "emergency" use when the graphics
card is being dumb or the graphical login agent has a messed up greeter
pam config or similar - rebooting to rescue.target would be a bit of a
pain for us developers. I'd be more than happy to just say only 1 login
is reserved for text only logins by default and ttys 1-11 are reserved
for "appropriate" login prompts.


Maybe now I've explained it a bit better, you have a different opinion?


FWIW, the option you mentioned in your reply to Dax (gdm useing only a
specific tty) is basically the option Ray said he was willing to support
in order to automatically start gdm on a specific tty when you first
switch to it (sans any kind of race avoidance I guess, but obtiously
having a slightly more fault tolerant approach to opening the tty when
systemd is quickly poking log output there would be a good thing generally).

Cheers


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

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/