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]
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].
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.
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`.
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
pgpkMSt9VtK5q.pgp
Description: PGP signature
_______________________________________________ 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
