No non-destructive way for a normal user to escape frozen full-screen apps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xorg-server (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: xorg
Full screen apps freezing is a common problem in both Windows and Ubuntu (irrespective of hardware or version, I do Ubuntu installs for my friends and always run in to this). (The most recent incarnation of this is the development version of Battle for Wesnoth (svn rev 41526): the quit button freezes the app instead of quitting. But I'm mentioning it only as an example, since it's a very common occurence with SDL or OpenGL apps.)
On Windows you'd try Alt-tab, the Windows key that calls the menu, or Ctrl-Alt-Delete to call the task manager, and in my experience 90% of the time the app'll successfully minimize, you'll kill it with a right-click, and will be able to use whatever other apps were running.
Let's take the point of view of an average Joe user that encounters the same thing in Ubuntu. He's been enjoying a comfortable desktop environment and has little technical knowledge. Assuming he even heard about them, he can try:
- Ctrl-Alt-F#: he is dumped to a terminal where he has as much chance of damaging his system as successfully killing the faulty app and going back to his Gnome session. He'll probably end up rebooting out of fear of the terminal.
- Alt-SysRq-K: in addition of being new and very little known, this will kill the X server along with any open application.
- Alt-SysRq-REISUB: is very little known, and will kill all apps, period.
- Ctrl-Alt-Del, Alt-tab, the windows key, or even Ctrl-Alt-Backspace that used to kill the X server won't do anything.
The most likely outcomes for Average Joe User are therefore:
- He loses all data from open apps. (Let's imagine he fired some sdl game to take a break from writing his school paper and forgot to save -- he loses all his data.) This is not even remotely acceptable.
- He doesn't know what to do reboots the computer, and not only loses all data from open apps, but may end up with an unbootable OS (been there, done that). This is not even remotely acceptable.
Now, I've seen some people including Ubuntu devs or moderators argue that it's the games' problem, and that we should take it up with those apps' devs. Wrong, I say. This is an issue of solidity and stability with the Ubuntu OS. Face it, freezes are VERY common in 3D apps, even under Windows with commercial games (in my experience it's more common under GNU/Linux systems).
The ostrich tactic won't work here, we need to recognize that the problem of full-screen apps freezing is not gonna go away soon no matter how much we pester dev teams. Bugs are part of life and that's it. Windows provides a way to gracefully escape from those freezes most of the time, without damage to the user's data or workflow. *Where is Ubuntu's method to deal with the problem?*
--
There, I've done the best I could as a user: reporting the bug. It's definitely not a mere feature request, since at the moment we're speaking it has nasty consequences on Ubuntu users who expect to find a more human-oriented operating system.
Since I'm not an expert interface designer it's not my job to design a solution, but I can still offer a suggestion: find some unused key combination, hook it directly with the X server and make it work like an emergency Alt-tab to hide the frozen full-screen app and go back to your desktop. And then widely publicize it so Ubuntu users know it just as well as Windows users know Alt-tab and Ctrl-Alt-Del. But I'm sure that with your collective brains, you can figure something better.
Please ask for extra hardware info if you need it, but honestly I wouldn't see the point of that: this is a well-known problem that's cross-platform and cross-distribution, basically everywhere a full-screen app can freeze. It's about time someone tackles and solves the problem, and I hope Ubuntu will be the distro that dares to take this step forward.
Please also don't mark this bug as a duplicate after superficial reading. This is not the same thing as for instance bug #63245, in which the reporter is merely asking for a convenient feature, for apps that run correctly and can be exited the normal way.
Lastly, I assigned the bug to the xorg package for good reasons: please discuss any changes here before hastily changing this assignment.
ProblemType: Bug
Architecture: amd64
Date: Thu Mar 11 00:24:24 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
MachineType: System manufacturer P5Q-PRO
NonfreeKernelMo
Package: xserver-xorg 1:7.4+3ubuntu10
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LANG=fr_CA.UTF-8
SHELL=/bin/bash
ProcVersionSign
RelatedPackageV
xserver-xorg 1:7.4+3ubuntu10
libgl1-mesa-glx 7.6.0-1ubuntu4
libdrm2 2.4.14-1ubuntu1
xserver-
xserver-
SourcePackage: xorg
Uname: Linux 2.6.31-20-generic x86_64
XsessionErrors:
(gnome-
(gnome-
(polkit-
(nautilus:2006): Eel-CRITICAL **: eel_preferences
(firefox:3918): GLib-WARNING **: g_set_prgname() called multiple times
dmi.bios.date: 12/03/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1613
dmi.board.
dmi.board.name: P5Q-PRO
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: P5Q-PRO
dmi.product.
dmi.sys.vendor: System manufacturer
system:
distro: Ubuntu
architecture: x86_64kernel: 2.6.31-20-generic
affects: | xorg (Ubuntu) → fglrx-installer (Ubuntu) |
affects: | xorg (Ubuntu) → fglrx-installer (Ubuntu) |
tags: | added: omit |
Changed in fglrx-installer (Ubuntu): | |
importance: | Undecided → Wishlist |
tags: | added: ct-rev |
description: | updated |
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
You didn't provide any explanation as to why you changed the package. Changing back.
Regarding the freeze example I mentioned, I now found out why Battle for Wesnoth svn is freezing, and it doesn't have anything to do with the graphics card. The game doesn't even use 3D acceleration. So what the hell does *fglrx-installer* has to do with this?
Let me remind you that the bug is that there is no way for an ordinary user to escape a frozen full-screen app. Frozen full-screen apps happen for a variety of reasons and you can't hope to fix them all. Therefore you must provide a decent workaround so the user can avoid losing data. And the X server seems to be the best place to put such a workaround.