F11: xorg decision to disable Ctrl-Alt-Backspace

[Adam Jackson]

On Sat, 2009-04-04 at 12:41 -0500, Callum Lerwick wrote:

> You are honestly expecting Aunt Tillie to log in to a console and grovel
> through log files?

No, Aunt Tillie is going to hit c-a-d or the power button like she does
in windows.  She doesn't know the difference between that and
c-a-backspace anyway, and the only visible difference for her is that
full reboot takes slightly longer.

> Here, how about a real life test case:
> 
> <snip>

Running this in rawhide doesn't do anything particularly special.  The
app crashes, certainly, but input continues to work afterward.  Haven't
tried with F10 yet, maybe it's worse there.

> Now how about Seg, the guy who debugs Little Billy's game. Take out the
> 'SDL_FULLSCREEN' flag from sdlcrash, recompile and run it under gdb.
> Wait for the crash... kablooey! I run in to this situation all the
> goddamn time trying to debug Second Life. It grabs the mouse when you
> click to move the camera, which is what you're doing most of the time.
> If it crashes then you're screwed.

I assume that you mean "gdb it from within X" here, in which case yes,
this is difficult.  Option one is to set a breakpoint on the signal
handler and do:

(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
> call XUngrabPointer(SDL_Display, 0)
> call XUngrabKeyboard(SDL_Display, 0)
> end

Except of course that SDL_Display isn't really a variable, so, figure
that bit out.  Or just do it from the signal handler in SDL or the app
itself, except then you have to set the breakpoint after those calls
have run.  You're playing with fire a bit here since if you faulted in
the middle of an xlib call, the ungrab requests are probably going to be
sent as garbage.

Other option is to somehow get an XKillClient() to happen, which would
break the server's connection to the now-halted client, and thus reset
grab state.  Again, if you do this from within the crashing client you
run the risk of corrupting xlib's state, so it's only better than the
ungrab hack if you can get it to fire from some other client.

Third option from within the crashing app itself is
close(ConnectionNumber(dpy)), I suppose.  That'll trigger disconnect
handling in the server without generating more protocol.

> Is there some way to recover other than killing off the process, which
> screws any chance of debugging it because it's no longer running? Remote
> debugging isn't always particularly convenient.

Yep, life is hard.

You may be able to use the GL support in Xephyr instead?  That would
limit the scope of the grab to the nested Xephyr server.

- 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/20090406/0c066845/attachment.sig>