Ubuntu Wiki

NOTE: This page is part of the Ubuntu Specification process. Please check the status and details in Launchpad before editing. If the spec is Approved then you should contact the Assignee, or another knowledgeable person, before making changes.

• Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/consistent-login-screen

• Packages affected: gdm, fast-user-switch-applet

See also:

• ConsistentLoginScreen - old sprawling version of this spec

• FaceBrowserLogin - proposal to change the login screen look-and-feel

Summary

Currently, "fast user switching" and logging in and out can generate very confusing results: black screens, needing to type passwords more than once, accidentally logging in twice as the same user (which breaks Gnome, etc).

Also, currently Ubuntu has three different login screens for (1) first user login, (2) unlocking the screensaver and (3) login as a new user when another user's screen lock is active. This is inconsistent and confusing.

User Interface

• There will be a single screen used for logging in, user switching, and screen unlocking. This will be the gdm login screen, possibly as modified by FaceBrowserLogin.

• The automatic screensaver will switch to that screen when prompting for unlock. "Switch users" will also switch to that screen.
• Logging in will automatically switch back to (and unlock) an existing session if there is one, or start a new one if not.
• You will never be offered a new session when you already have one unless you manually switch VCs.
• If you reach the login screen from your screensaver, the username field will start with your username.
• In the future, the login screen could be augmented with information about already running sessions.

Design

The login screen will be detached from the user's session and run in a different dedicated X server on a dedicated VC. The X server used by gdm will remain around forever and will be reused by fast user switching.

Arrangements will be made to automatically switch back and forth between VCs as appropriate. Logging in will switch to an existing session and unlock it.

Details

After a successful login via gdm, the system will look for an existing session. If there is one, it will switch to the relevant VC and stop the screensaver (if any), thus resuming the user's session. Otherwise it will start a new X server with the user's session, on a new VC (and switch to it), and on the gdm VC it will return to the gdm login screen. (Modifications to gdm.)

When the screensaver triggers in a user's session it will run normally until cancelled by a mouse or keyboard event. If configured not to lock, the user's session will resume immediately as at present. If configured to lock, it will switch VCs to the gdm login screen (and then carry on and show, invisibly, the password prompt, as at present). At this point the screensaver will also make a note never to run the actual screensaver again (it doesn't matter much what it does instead, so long as it doesn't grant access to the user's session); this is to avoid running a computationally intensive screensaver in an invisible X server. (Modifications to the screensaver.)

If following a switch away from a user's screensaver, the gdm login is cancelled, a VC switch will be made back to the screensaver and the screensaver told to start running properly again.

If the user requests to switch to a different user, the screensaver will be started immediately on that VC (the switched-away-from user's VC) but with the actual screensaver disabled (as above), and a VC switch will be made to the login screen; gdm will be told so that it can un-blank the display if needed.

There is no need to change the standard black screen screensaver in gdm.

Communication between the processes will be done as follows: gdm will maintain the list of VCs and sessions, and create an AF_UNIX listening socket, whose pathname will be inherited by sessions via an environment variable. A trivial protocol will be used to convey the various information, including messages with meanings like "here is the new session for user X and it is on VC Y", "hi this is the screensaver for user X requesting switch to you for resume", "you screensaver should quit and unlock now", etc. gdm will be responsible for all VC switching, perhaps by doing ioctls directly or perhaps by running chvt.

Related bugs

The user confusion caused by (and bugs triggered by) the current situation can be seen here: https://launchpad.net/bugs/45254 https://launchpad.net/bugs/51580 https://launchpad.net/bugs/40011 https://launchpad.net/bugs/39936 (and dupes) https://launchpad.net/bugs/67628 https://launchpad.net/bugs/64023 https://launchpad.net/bugs/65975 https://launchpad.net/bugs/67730 https://launchpad.net/bugs/68361

Approval discussion

(This section contains discussion with approvers and reviewers and will be removed after approval.)

Which of the various existing screen designs is to be picked as the preferred one? (I have a slight preference for gdm's, since the others seem too bleak for an initial login.) I think it might be a good idea to modify it in some subtle way if reached from the screensaver or fast-user-switch, otherwise it will give the impression that you're having to log in again because your desktop crashed. --ColinWatson

• I think I have answered these questions above now. If you say "switch users" I think the normal gdm screen will do just fine (and if you enter your own username then you can get back to your session as expected). -iwj

Currently, the screensaver pre-fills your username, which it can do because the login screen runs within your session and only your session. With a single login screen for all users, this invariant no longer holds. Can this be done iff there is a single user with an active screensaver, or perhaps pre-fill the last user who activated their screensaver? How do the various screensavers communicate this state? --ColinWatson

• You will never see the screensaver login screen. When you cancel the screensaver, it will switch back to gdm. See above for arrangements to get the username into gdm.

Speaking of screensaver communication, if we make multiple-user operation much easier we're going to see an increase in multiple users running screensavers at any one time, and I've found in the past that I have to abuse root privileges to kill another user's screensaver when it was hogging resources. Is there any way we can mitigate this? (Perhaps not a topic for this specification, though.) --ColinWatson

• I had failed to discuss screensavers in enough detail. I think this is clearer now. -iwj

Could this be paraphrased as something like "the X server used by the gdm login screen hangs around forever, and is reused by the screensaver and fast user switching"? --ColinWatson

• Something like that, yes - see above. Thanks for the wording suggestion. -iwj

Could this spec be merged with ConsistentLoginScreen? --AndreRuediger

• See the cross-reference right at the top. This spec replaces the relevant part of ConsistentLoginScreen. ConsistentLoginScreen is obsolete now. -iwj

CategorySpec