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

David Campbell david at
Wed May 27 15:30:24 PDT 2009


Do you think that 
can/should be backed out for the time being until an alternative 
solution to this matter becomes available, because with this change in 
place in the current server, there's no real way to debug popup menu 
callback code during a grab where the application and the debugger are 
on the same display.

-- Dave

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:
>>> 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 at

More information about the xorg mailing list