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
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
