XorgCtrlAltBackspace

Revision 46 as of 2008-07-16 15:47:43

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

The Ctrl-Alt-Backspace key combination currently "zaps" (hard-restarts) the X server, and thus loses any unsaved data in applications, etc. This key combination is also largely undocumented, so users (probably ex-Windows users) may press this key combination without expecting data loss. This spec proposes to modify how this key combination works such that by default the user must hold the keys for 2 seconds in order for it to take effect.

Release Note

The key combination of Ctrl-Alt-Backspace, which previously immediately exited X (and thus reset the graphics system back to the login screen), has been modified to require it to be held for 2 seconds before taking effect. This should help reduce the frequency of unexpected data loss and activity interruption for users unaware of its function that strike it accidentally.

Rationale

The key combination of Ctrl-Alt-Backspace terminates the user's current graphical shell, which can cause data loss if invoked accidentally. For some keyboards, backspace is in a location that can lead to accidentally hitting Ctrl-Alt-Backspace when using other Ctrl-Alt- key combinations. This can cause unexpected data loss and workflow interruption.

However, disabling the key combination entirely would not be desirable, as it is an important way for exiting/restarting X that is useful particularly when X has locked up. A pop-up confirmation dialog is also not desirable (or even feasible really), firstly because in one of the main use-cases for the key combo (a stuck Xorg), it's highly likely the window manager could not be depended on to display a dialog, secondly because having a dialog would be an irritant both for accidental and intentional users, and thirdly because the key handling is done deep in the *server*, and "just popping up a dialog" is extremely non-trivial (and probably would be very fragile.)

Making the key combination require being held for a couple seconds seems like a reasonable compromise.

Use Cases

  • Brian is a relatively new Ubuntu user working on a large image file in the GIMP, but also has Blender open on a different workspace which he used to render the image. Brian wants to close Blender as he is finished with it and needs to free up some memory for the GIMP. He remembers in Windows he could bring up an application list via Ctrl-Alt-Delete, but that doesn't work so he tries pressing Ctrl-Alt-Backspace. The key combination does nothing so he decides to open the System Monitor from the System > Administration menu instead. Once Blender is closed he continues to work on his image in the GIMP, saving it when he is finished.

  • Katie is writing a guide to help people who are used to Windows to migrate over to Ubuntu. She reads the help manuals for inspiration, then later she is experimenting to find similar functionality between the two systems that she can document. She avoids pressing Ctrl-Alt-Backspace and losing the document, which she has not saved yet, because she read in the help manuals that this would lose her work and send her back to the login screen.
  • Joel's computer interface has frozen due to a graphics driver problem. He still has daemons running which need to remain open, so he cannot reboot. He remembered that Ctrl-Alt-Backspace would restart X, and is surprised at first that it doesn't restart immediately but he holds it down just in case, and after a couple seconds X restarts and he's back in business. He's curious why it didn't restart immediately, but after investigating it he learns that he can control the delay in his xorg.conf, but he doesn't mind the new behavior so leaves it as is.
  • Elisee presses ctrl + alt + left or right to change from one workspace to another, and realizes that he wants to erase what he was writing on his IM program just before switching workspace, and accidentally hits backspace before releasing Ctrl and Alt. Thankfully, this didn't result in X exiting as it used to. He breaths a sigh of relief.

Assumptions

This spec assumes that users do not use the Ctrl-Alt-Backspace functionality regularly, and that those who do will not be terribly inconvenienced by having to hold it for 2 seconds.

The implementation section assumes that imposing a delay for the keystroke is doable with the xorg special key handling infrastructure. If not, an alternate design would be to have the user strike the key combo 3 times in sequence.

Design

A 2 second delay to the Ctrl-Alt-Backspace key combination will be added to xorg-server.

A new 'ZapDelayTime' ServerFlag configuration parameter will be added for users to use in xorg.conf to control the delay before terminating the X session. Setting it to 0 will restore the old behavior, where X exits immediately.

Implementation

  • hw/xfree86/parser/xf86tokens.h: add ZAPDELAYTIME token
  • hw/xfree86/common/xf86Privstr.h: add zapDelayTime field
  • hw/xfree86/common/xf86Globals.c: set default value of zapDelayTime to 2
  • hw/xfree86/common/xf86Config.c: add FLAG_ZAPDELAYTIME with call to xf86GetOptValBool()
  • hw/xfree86/parser/Flags.c add to ServerFlagsTab[] structure and xf86parseFlagsSection(void)'s case statement

  • hw/xfree86/xorgconf.cpp: Add "ZapDelayTime" option

  • hw/xfree86/doc/man/Xorg.man.pre man page
  • hw/xfree86/doc/man/xorg.conf.man.pre man page
  • hw/xfree86/utils/xorgconfig/xorgconfig.c xorg.conf template
  • hw/xfree86/common/xf86Events.c: Modify the KEY_BackSpace case branch in xf86CommonSpecialKey so it calls xf86ProcessActionEvent(ACTION_TERMINATE, NULL) only after zapDelayTime's configured time delay.

    • Need to record when the Press action started
    • On subsequent Press or Release actions, compare time to zapDelayTime
    • If Release happens before zapDelayTime, reset the delay timer
  • xkb/xkbActions.c: Ditto changes done to xf86Events.c

Test/Demo Plan

To test the implementation the keypress should be held for < 2 sec and if nothing happens until time == 2 sec, then it is successful.

The ZapDelayTime parameter should be set to several values (0, 5, 100) and verified that the behavior is delayed by that amount of time.

Discussion

Previous discussion has been taken into account with this version of the spec, and is archived at ["XorgCtrlAltBackspace/Discussion"].

  • A number of people have suggested "just pop up a dialog" out of the assumption that "popup dialogs" == "better user experience" but they do so without giving this much thought. In addition to being unimplementable, imposing a GUI dialog largely breaks the control-alt-backspace use case and leaves remaining users with an irritating UI - instead of one key combo they now would have to also hit additional keys or manipulate the mouse; assuming their keys and mice actually work, they would quickly come to loathe this change. Despite all this, if people still feel the compromise of adding a delay is insufficient and that the spec is not complete without a GUI popup, then my preference would be to leave the current behavior as-is and just have users self-educate about the key combo. -- bryce

  • While I do understand your point, I think that the delay *might* not be enough. Would have to test, but backspace is one of the very few keys you get to press for several seconds, because you actually want it to erase multiple characters. Having a popup showing up like the ones used for special volume / contrast keys, e.g. no user interaction, only display a warning and disappear quickly without requiring any user action sounds like a very good way of not getting in the way while providing the user with useful warning ("you just release that key now or you're loosing all your unsaved work!!!1"). Not sure it's technically possible of course, would certainly require interfacing with the desktop/window manager. Additionnally, providing a simple GUI way to disable / change delay of the zap behaviour (maybe "consensus rather than configuration" is not the solution in that case - but maybe it is), could prove to be good? Though I understand that if it requires editing xorg.conf, it's a no-go. -- elisee

An alternative solution

I'm developing an [https://launchpad.net/remote-help-assistant assistant] that helps set up remote desktop sessions over the Internet, so my concern is about security when you give access to a friend who starts fiddling with things he oughtn't to. VNC servers don't provide any easy way to kick the other user out, and zapping the system fits the problem quite nicely - it's fullproof, available by default, and hard for malicious users to disable. I'm actually quite concerned that it's possible to set DontZap at all, because it leaves users with no option short of hitting reset/power off when a friend turns out to be nasty (or just drunk). Having read all of the above, could I suggest the following (comparatively complex) solution:

The X server listens on a Unix socket named something like /var/run/Xorg-zap-:0.0. It accepts the following messages:

  • lock - Enable ctrl-alt-backspace for as long as the specified client is connected to the socket

  • release - Release a previous lock

  • enable-default - Enable zapping on this server until the next restart

  • disable-default - Disable zapping on this server until the next restart, except when locked by a client

  • enable-messages - This client should receive messages from the server over this socket

When enable-messages is set, the server sends the following messages to the socket:

  • enabled - Zapping has just gone from disabled to enabled, either by a lock or enable-default

  • disabled - Zapping has just gone from enabled to disabled, either by locked socket bing released or closed, or by disable-default

  • wait N - ctrl-alt-backspace is being held down, and the system will be zapped in N seconds

  • cancel - ctrl-alt-backspace has been released

Additionally, the server sends either enabled or disabled in response to enable-messages, to notify the client of the initial state of the server.

This would make the following use cases possible:

A VNC server (or remote help assistant) could lock the server for the duration of the VNC session and hold the socket open with only a few lines of code - in particular, it wouldn't need to bother regularly throwing away input from the socket.

A GNOME applet could listen to messages from the server, and pop a warning message up saying "your computer will restart in N seconds" without making massive architectural changes to X. The idea would be that the window pops up on wait and goes away on cancel, and is just a warning message rather than a confirmation dialogue. That strikes me as a fairly nice way of notifying users what's happening without interrupting their workflow too much.

A KDE configuration program could get the zapping state of the server, update that state in real time, and allow the user to set the state.

See also:


CategorySpec