F11: xorg decision to disable Ctrl-Alt-Backspace

[Adam Jackson]

On Tue, 2009-03-31 at 10:51 -0400, Colin Walters wrote:
> 2009/3/31 Adam Jackson <ajax at redhat.com>:
> > So let's list the cases that zap would actually recover from:
> >
> > 1: stuck grabs
> > 2: focus reverts to None and your window manager is dead
> > 3: X driver that's decided to stop rendering (or stop rendering
> > correctly)
> 
> Let me add:
> 
> 4: Randr configuration is either broken or out of date, and the system
> didn't detect it correctly
> 
> More than a few times now I've forgotten I had set up an external
> monitor, suspended, and unsuspended later and faced with a black
> screen thought my machine had locked.  Of course this is a system bug,
> but then all of these things are.

Yeah, this is hard.

Part of the problem here is that the X server doesn't really have a good
way of knowing when a suspend happens.  For UMS drivers, we vt-switch
and hope that works, but that means you can't distinguish normal vt
switch from suspend.  Maybe you always want to do an output rescan at vt
enter?  Maybe not.  Maybe just rescan and send config change events to
the desktop, but not actively change the topology.

For KMS drivers, we suspend in place now, which is pretty awesome since
it eliminates flicker on the way down and on the way back up.  So the
kernel driver ought to be smart enough to send configuration changes
back through a uevent.  I don't think we're doing anything with those
events yet though.

> > For case 1, you might be able to recover if you could just figure out
> > which client was being obstreperous.  So clearly the right thing is to
> > dump active grab state to the X log on VT switch.  If there's anything
> > there, then you know who to blame and you can pkill just that and
> > recover.  If there's not, then the session is doomed.
> 
> That's useful.  A lot of the time I have a good idea of what app has a
> stuck grab, but this is a bit easier.  Ideally there would be a way to
> forcibly ungrab but I suppose that may confuse application toolkits.

We had an optional bit of config file magic at one point that would let
you turn on a magic key combo to break the current grab.  Plus a
matching request in the XFree86-Misc extension to turn it back off,
since otherwise you can defeat screen locking.  Gone in 1.6 though, that
extension was pretty much a mistake. [1]

The problem with the notion of breaking grabs is that it's an arms race.
X is just broken here.  The only way to fix it is to break out to a
wayland mini-app that does the moral equivalent of MacOS's Force Quit.
(And in some sense, by the time you're running a whole new display
system to fix your old one, it's time to just move on.)

Since we can't _actually_ fix grabs, the right thing to do is punish
apps that abuse them.  Server zap doesn't do this.  It punishes the
whole session.  Even just breaking the grab doesn't get things fixed,
because the bug stays there in the app forever.  You want the recovery
path to be such that you can inspect the state of the broken app at the
moment it's misbehaving.  Grab state dump on VT switch accomplishes this
better than either zap or grab-break.

[1] - Not so much that the things it embodied were bad ideas - though
they all were to some extent - but that the implementation showed a
willful disregard for the rest of the server.  GrabBreak could easily
have been a new, possibly even privileged, XKB action, but instead it
was a magic trapdoor.  Why do anything in the existing design when you
can add another layer of crap on top.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090331/0153cd38/attachment.sig>