It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

Peter Hutterer peter.hutterer at
Tue May 26 17:14:17 PDT 2009

On Tue, May 26, 2009 at 02:13:15PM +0100, Daniel Stone wrote:
> On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote:
> > On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote:
> > > By "switching to a VT", did you mean pressing CTRL-ALT-<number> to 
> > > switch to a virtual terminal?
> > > 
> > > That doesn't work for me, due to the grab.  Pressing those keystrokes is 
> > > unresponsive, thus for a standalone system in a location where there are 
> > > no other computers, it still appears that the only option in the 
> > > situation of hitting a breakpoint during a grab, is to force a power 
> > > down and reboot.
> > 
> > VT switching only works as long as the grab is asynchronous, otherwise
> > events are queued up on the device for replaying and never pass through the
> > XKB paths that trigger this behaviour.
> We should probably fix this for XKB2 by keeping a 'last internal state'
> separate to the normal state, which takes into account all thawed
> events; does that sound sensible? Then we can define 'internal actions'
> which take the new state field into account, or just specify that all
> actions are thus processed before the device is thawed.

The only reason why the event's arent processed in a frozen device is
because the processInputProc is changed to EnqueueEvent which does nothing
but stack the events into the queue. You could hook up the VT switching and
Terminate_Server actions in there (the events need to be discarded or marked
used though so thawing the device doesn't switch again).

I don't think there's any need for XKB2 as such, it could be fixed in the
current implementation. I'll leave that as an exercise to the reader though.


More information about the xorg mailing list