XorgCtrlAltBackspace

Revision 45 as of 2008-07-01 12:43:48

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

See also:


CategorySpec