UbuntuWiki:UnifiedLoginUnlock

{{#ifexist: :UbuntuWiki:UnifiedLoginUnlock/zh | | {{#ifexist: UbuntuWiki:UnifiedLoginUnlock/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UnifiedLoginUnlock|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UnifiedLoginUnlock|1|-1|}} | zh | | }}

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 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 login screen will be augmented with information about already running sessions.

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

Proof of concept / technology demonstrator

We will try to provide a mock-up demonstrator ASAP. This will probably not involve gdm.

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); 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 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?]

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

---