UnifiedLoginUnlock

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

Stop Press

We are investigating console-kit instead.

http://lists.freedesktop.org/archives/hal/2007-January/006996.html http://fedoraproject.org/wiki/Desktop/FastUserSwitching package consolekit, with support in gdm et al MainInclusionReviewConsoleKit

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 start an X server from the command line.
If you reach the login screen from your screensaver, the username field will start with your username. The user will need to hit enter to confirm it and then enter their password (this gives them the ability to specify a different username without doing too much violence to the existing UI code).
The login screen will be augmented with information about already running sessions.

Long-term Design

Each user session will run in a separate "proxy" X server; likewise, gdm will run in a similar proxy. These proxy servers will all connect to one single real X server.

When the real X server provides GL and if Xgl works properly, the proxy server will be Xgl. When it does not, it will be Xnest or perhaps Xephyr.

Each user session proxy will last only for the duration of that session. The X server used by the greeter will remain around forever and be reused by fast user switching.

Arrangements will be made to automatically switch back and forth between proxy servers as appropriate, initially using ordinary X protocol requests to the real X server (map/unmap or change stacking order). Logging in will switch to an existing session and unlock it.

Initial version and fallback options

The software architecture in gdm will be written to support initially the use of real X servers for each session, without the master server, and with session switching done with VC switching. This will avoid complicating the initial login switch architecture with interactions with GL and Xrandr (which we are not currently sure will work properly in the design demonstrated above). This will be the initial version deployed in gutsy.

This will also remain in the long-term as fallback option for situations where Xnest and/or Xgl do not prove sufficiently stable, but fast user switching is still desired.

Until Xnest/Xephyr and/or Xgl are sufficiently stable and featureful for use in a default configuration, we will have the options of using the VC-based switching or disabling fast user switching altogether.

If Xnest/Xephyr work well but Xgl is insufficiently stable (eg because effort has gone into AIGLX) then we will have two options: smooth fast user switching with no compositing; VC-based fast-user switching (or none), but compositing enabled.

Details

After a successful login via gdm, the system will look for an existing session. If there is one, it will raise/map the relevant proxy and stop the screensaver (if any), thus resuming the user's session. Otherwise it will start a new proxy server with the user's session, and on the gdm proxy 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 (on activity or unlock request) switch to the gdm login screen (and then carry on and show, invisibly on its own proxy, 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) unless requested; 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 last-switched-away-from user's screensaver (or the gdm screensaver if no-one is still logged in) 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 server (the switched-away-from user's proxy) but with the actual screensaver disabled (as above), and a 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 use its existing communication sockets. gdm will be responsible for all session switching, by running a special switching client against the real server.

Some details

GL support on the real server can be detected as the following combination of extensions: "Direct Rendering" AND (GL_ADD_NON_POWER_OF_TWO OR GL_ARB_TEXTURE_RECTANGLE).

There will be a configuration option to disable fast user switching for power users who need or want to disable it.

It will be necessary to provide a way for the user to run programs on the real X server (this is needed eg for some games). The arrangements ought to be similar to the way currently done by compiz/glx - a command-line utility which manipulates Xauthority files and DISPLAY.

Resolution switching will initially only supported by users with gksu access so that xrandr can be run against the real X server.

Running the session via Xgl as a proxy will simplify the use of compositing window managers: if Xgl starts then compiz will be known to work, and no complex hardware databases etc. are needed and some hardware compatibility bugs avoided.

Xinerama will not be supported in this configuration. Xinerama users will have to disable fast user switching. [Nvidia-settings will also not work with XGL?]

Release note

The login screen has been unified with the screensaver password request screen, and the "Switch user" feature improved to make the user switching workflow comprehensible.

Test plan

Log in as one user, A, and start some applications
Ask to switch to a different user
Observe that the main login screen returns and indicates that A has a session running
Log in as a different user, B
Ask to switch to a different user
See the main login screen again, with both A and B with sessions running
Ask to log in as A
See that A's applications (started earlier) are running
Configure A's screensaver to some specific screensaver, and sk to lock the screen
Observe A's screensaver
Move the mouse or press a key
Observe the main login screen again, showing A and B with sessions running

Comments

There's been some strong concerns expressed that XGL is not at all ready for being this strongly relied on, both for stability and supportability reasons; it might be best to move this to a Deferred For Now section. -- bryce
The spec says that Xinerama will not be supported, which is fine as I expect this to be deprecated here at some point. What about TwinView or xrandr-based multi-head (these are the encouraged path forward)? Also, what are the concerns preventing Xinerama to be supported? -- bryce
A very important thing that this spec must provide is an easy way to completely disable itself (possibly at the cost of completely disabling any sort of fast user switching). There will be a lot of users who this spec will hurt (xinerama, broken drivers, people who like screensavers, or people who are the sole user of their computer and don't like the needless complication). There are probably many more cases that we couldn't possibly think about. -- desrt

CategorySpec

UnifiedLoginUnlock (last edited 2008-08-06 16:38:07 by localhost)

Ubuntu Wiki