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

[Daniel Stone]

On Wed, May 27, 2009 at 10:14:17AM +1000, Peter Hutterer wrote:
> 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:
> > > 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).

Right.  You still need to run them through the full XKB processing gamut
however, so you can catch the state from modifiers, etc, and that
requires you to run all the actions too.  *shrug*

> 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.

I didn't think you could do this within the spec, but upon re-reading,
it looks like it should be possible.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20090529/eb0851fd/attachment.pgp>