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 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg