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

[Peter Hutterer]

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.

Cheers,
  Peter