[BUG] Touchscreen woes

[Peter Hutterer]

On 30/11/2013 02:42 , Ben Gamari wrote:
> Peter Hutterer <peter.hutterer at who-t.net> writes:
>
>> On Fri, Nov 22, 2013 at 09:53:11AM -0500, Ben Gamari wrote:
> [snip]
>
>> you might want to build your server with debug symbols and install
>> libunwind-devel, it'd help greatly with the backtrace.
>>
> Done.
>
> [snip]
>
>>> Note how `ActivateEarlyAccept` is called even if the listener is of type
>>> `POINTER_REGULAR`. This results in the bug. The most obvious change to
>>> avoid this was this patch[2].
>>
>> yeah, this does seem the right fix. Need to write some extra tests for this
>> but I've merged your patch for now (might rewrite the commit msg though).
>>
> Alright, good. Thanks!
>
>>> Unfortunately this does not fix a second issue. Both before and after
>>> the fix above, touches would often result in keyboard input pausing: any
>>> key presses after the touch would not be registered until a mouse button
>>> was pressed at which point the keypress events would be delivered
>>> immediately. Sometimes, however, even a mouse events do not restore
>>> keyboard function. Sadly, nothing is logged during these events. It
>>> seems this is likely triggered by touches which change the focused
>>> window.
>>
>> this could be some stuck touch handling where the events aren't actually
>> released. If you can find a reliable test case that'd be great.
>>
> Opening two xterms in a bare xmonad session seems to reproduce
> reliably with my setup.  Attempting to touch the non-focused window
> causes keyboard input to pause until a mouse button is pressed.
>
>>> I've tried following the lost keyboard events through the xserver and
>>> found that `DeliverFocusedEvent` (Xi/exevents.c) finds that
>>> `keydb->focus->win == PointerRootWin`. This causes delivery to occur
>>> through `DeliverDeviceEvents` (dix/events.c) which delivers nothing as
>>> `IsMaster(dev) == 0`.
>>
>> you need to check again here. each event is processed twice, once for the
>> device and once for the master. you need to make sure that kbd->name ==
>> "Virtual core keyboard", you can ignore the actual device for most purposes.
>> the actual device has PointerRootWin, usually, the VCK has the actual focus.
>>
> It seems that when keyboard input is in its paused state only the
> device events are delivered. The core keyboard events are only
> delivered after another mouse event has occurred.

ok, what's happening here is that (most likely) the device is frozen. 
Event delivery works that for each event, dev->public.processInputProc 
is called. That is usually ProcessOtherEvents(), but if the device is 
frozen from a sync grab, that func is EnqueueEvents(). You'll likely 
fine that the core keyboard events are going there. Once unfrozen, the 
events are replayed as you see below.

most likely what's happening here is that the grab is stuck and xmonad 
doesn't send the AllowEvents because it didn't get an event it expected.
the xscope output may help here to figure out what it is registering for.

Cheers,
   Peter



 > The backtrace while
> the old keyboard events are being processed looks like,
>
>      Breakpoint 2, DeliverFocusedEvent (keybd=keybd at entry=0x7ff49474e640, event=event at entry=0x7ff494a07a20, window=0x7ff4949d63c0) at ../../dix/events.c:4101
>      4101    {
>      2: keybd->name = 0x7ff49474ecd0 "Virtual core keyboard"
>      (gdb) bt
>      #0  DeliverFocusedEvent (keybd=keybd at entry=0x7ff49474e640, event=event at entry=0x7ff494a07a20, window=0x7ff4949d63c0) at ../../dix/events.c:4101
>      #1  0x00007ff4928642e6 in ProcessDeviceEvent (device=0x7ff49474e640, ev=0x7ff494a07a20) at ../../Xi/exevents.c:1779
>      #2  ProcessOtherEvent (ev=0x7ff494a07a20, device=0x7ff49474e640) at ../../Xi/exevents.c:1826
>      #3  0x00007ff49288b6e4 in XkbHandleActions (dev=dev at entry=0x7ff49474e640, kbd=kbd at entry=0x7ff49474e640, event=event at entry=0x7ff494a07a20) at ../../xkb/xkbActions.c:1335
>      #4  0x00007ff49288bcc6 in XkbProcessKeyboardEvent (event=event at entry=0x7ff494a07a20, keybd=keybd at entry=0x7ff49474e640) at ../../xkb/xkbPrKeyEv.c:146
>      #5  0x00007ff492884a25 in AccessXFilterPressEvent (event=0x7ff494a07a20, keybd=0x7ff49474e640) at ../../xkb/xkbAccessX.c:576
>      #6  0x00007ff49278b974 in PlayReleasedEvents () at ../../dix/events.c:1258
>      #7  0x00007ff4927919e5 in ComputeFreezes () at ../../dix/events.c:1338
>      #8  0x00007ff4927920f2 in DeactivatePointerGrab (mouse=0x7ff494754b70) at ../../dix/events.c:1609
>      #9  0x00007ff49286447d in ProcessDeviceEvent (device=0x7ff494754b70, ev=0x7fff1653d590) at ../../Xi/exevents.c:1786
>      #10 ProcessOtherEvent (ev=0x7fff1653d590, device=0x7ff494754b70) at ../../Xi/exevents.c:1826
>      #11 0x00007ff492885186 in ProcessPointerEvent (ev=0x7fff1653d590, mouse=0x7ff494754b70) at ../../xkb/xkbAccessX.c:751
>      #12 0x00007ff4928b2a5d in mieqProcessDeviceEvent (dev=dev at entry=0x7ff4948d7060, event=event at entry=0x7ff492b626c0 <event.15512>, screen=screen at entry=0x7ff49468aca0) at ../../mi/mieq.c:565
>      #13 0x00007ff4928b2b77 in mieqProcessInputEvents () at ../../mi/mieq.c:627
>      #14 0x00007ff4927bffc9 in ProcessInputEvents () at ../../../../hw/xfree86/common/xf86Events.c:163
>      #15 0x00007ff492782f12 in Dispatch () at ../../dix/dispatch.c:357
>      #16 0x00007ff49277272a in main (argc=9, argv=0x7fff1653e3f8, envp=<optimized out>) at ../../dix/main.c:298
>
>
> Cheers,
>
> - Ben
>