UnifiedLoginUnlock

Differences between revisions 16 and 17
Revision 16 as of 2006-11-29 14:33:39
Size: 7344
Editor: chiark
Comment: clarify status in response to q from AndreRuediger
Revision 17 as of 2007-05-08 15:26:30
Size: 8146
Editor: 195
Comment: new non-VC-switching proposal
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * You will never be offered a new session when you already have one unless you manually switch VCs.  * You will never be offered a new session when you already have one unless you manually start an X server from the command line.
Line 23: Line 23:
 * In the future, the login screen could be augmented with information about already running sessions.  * The login screen will be augmented with information about already running sessions.
Line 28: Line 28:
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. 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.
Line 30: Line 30:
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. When the real X server provides GL, the proxy server will be Xgl. When it does not, it will be Xnest or perhaps Zephyr.

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.
Line 34: Line 42:
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.) 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.)
Line 36: Line 44:
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.) 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.)
Line 40: Line 48:
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. 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.
Line 44: Line 52:
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. 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).

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.

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.

See also:

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

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

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.

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


CategorySpec

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