[BUG] Touchscreen woes

[Peter Hutterer]

On Fri, Nov 22, 2013 at 09:53:11AM -0500, Ben Gamari wrote:
> I recently took shipment of a Dell Latitude E7440 bearing a
> touchscreen. While things work as expected under Unity, using
> the touchscreen under XMonad causes the input system to quickly fall
> apart. I've been trying to track this down in Bug #71878 [1]. I've been
> putting my notes up in this bug which I'll summarize here. In the
> below I'm working on a 1.14.4 `xserver` with 4292a39c (which appears to
> be relevant to touch bugs) cherry-picked on top.
> 
> The first issue I encountered was BUGs being logged after several
> touch events,
> 
>     (EE) BUG: triggered 'if (ti->listeners[0].type != LISTENER_GRAB && ti->listeners[0].type != LISTENER_POINTER_GRAB)'
>     (EE) BUG: ../../Xi/exevents.c:1044 in ActivateEarlyAccept()
>     (EE) 
>     (EE) Backtrace:
>     (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x7f68034634fd]
>     (EE) 1: /usr/bin/X (0x7f68032c1000+0x132072) [0x7f68033f3072]
>     (EE) 2: /usr/bin/X (0x7f68032c1000+0x1336bb) [0x7f68033f46bb]
>     (EE) 3: /usr/bin/X (0x7f68032c1000+0x135e02) [0x7f68033f6e02]
>     (EE) 4: /usr/bin/X (0x7f68032c1000+0x156f46) [0x7f6803417f46]
>     (EE) 5: /usr/bin/X (mieqProcessDeviceEvent+0x1cd) [0x7f680344581d]
>     (EE) 6: /usr/bin/X (mieqProcessInputEvents+0xf7) [0x7f6803445937]
>     (EE) 7: /usr/bin/X (ProcessInputEvents+0x9) [0x7f6803352f79]
>     (EE) 8: /usr/bin/X (0x7f68032c1000+0x54f12) [0x7f6803315f12]
>     (EE) 9: /usr/bin/X (0x7inaf68032c1000+0x4472a) [0x7f680330572a]
>     (EE) 10: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f6800ffcde5]
>     (EE) 11: /usr/bin/X (0x7f68032c1000+0x44a6f) [0x7f6803305a6f]

you might want to build your server with debug symbols and install
libunwind-devel, it'd help greatly with the backtrace.

> after this happens everything appears to function as expected except
> keyboard input, which is completely unresponsive (save VT switching). I
> tracked this through the code and found that `DeliverTouchBeginEvent`
> does the following,
> 
>     if (listener->type == LISTENER_POINTER_REGULAR ||
>         listener->type == LISTENER_POINTER_GRAB) {
>         rc = DeliverTouchEmulatedEvent(dev, ti, ev, listener, client, win,
>                                        grab, xi2mask);
>         if (rc == Success) {
>             listener->state = LISTENER_IS_OWNER;
>             /* async grabs cannot replay, so automatically accept this touch */
>             if (dev->deviceGrab.grab &&
>                 dev->deviceGrab.fromPassiveGrab &&
>                 dev->deviceGrab.grab->pointerMode == GrabModeAsync)
>                 ActivateEarlyAccept(dev, ti);
>         }

>         goto out;
>     }
> 
> 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).
 
> 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.

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

Cheers,
   Peter

> 
> I'm not terribly familiar with X11 internals so it's not clear to me what
> this means. Does `keydb->focus->win == PointerRootWin` mean there is no
> focused window? Ultimately it seems likely that the issue is related to
> XMonad's focus handling. Does the window manager need to do anything
> special to accomodate touch? Any ideas of what might be going on here or
> means of debugging would be greatly appreciated.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=71878
> [2] https://bugs.freedesktop.org/attachment.cgi?id=89614