Also, sometimes after using the touch device instead of killing keyboard input altogether, it will simply pause it until the next mouse click. For instance,

1) Type on keyboard, see text produced
2) Use touch screen
3) Type on keyboard, no text is produced
4) Click touchpad button, characters typed suddenly appear

It seems that this isn't reproducible with Unity at all. Any idea what XMonad might be doing differently?

Regardless, this should probably still be considered a bug: even a misbehaving (or simply touch unaware) window manager shouldn't be able to kill keyboard input.

The problem might be the following: `DeliverTouchBeginEvent` tries to
deliver an event to a listener of type `LISTENER_POINTER_REGULAR`,
taking the following `if` branch,

    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;
    }

`DeliverTouchEmulatedEvent` succeeds.  The `deviceGrab` meets all
three of the conditions of the inner `if`, enters
`ActivateEarlyAccept` which then fails due to,


    BUG_RETURN(ti->listeners[0].type != LISTENER_GRAB &&
               ti->listeners[0].type != LISTENER_POINTER_GRAB);

That is, despite `listener->type == LISTENER_POINTER_REGULAR`. With my
non-existent knowledge of XINPUT, it seems like the solution here
might be to only `ActivateEarlyAccept` when `listener->type ==
LISTENER_POINTER_GRAB`.

Created attachment 89614 [details] [review]
A quick patch implementing the describing fix and/or workaround

Here is a patch which implements the fix or workaround described above. It seems to prevent touch events from taking down keyboard input. That being said, the pause issue described in Comment 1 seems to still occur.

Sadly it seems like occassionally the keyboard queue freeze is irrecoverable, even aftering throwing in more input events from other devices. I've only seen this once so far after a touch drag. Notably, one of the windows on-screen at the time of the drag (perhaps the window with focus at that moment) stopped redrawing after the incident.

I just had a keyboard pause incident produce a BUG:

[ 36800.740] (EE) BUG: triggered 'if (!(event->device_event.flags & (1 << 5)))'
[ 36800.740] (EE) BUG: ../../dix/touch.c:644 in TouchConvertToPointerEvent()
[ 36800.740] (EE) Non-emulating touch event

It seems that dragging across multiple windows is a good way to trigger the keyboard pauses.

I've followed the dropped key events into exevent.c. We make it
through,

  ProcessKeyboardEvent (xkb/xkbPrKeyEv.c)
  ProcessOtherEvent (Xi/exevents.c)
  ProcessDeviceEvent (Xi/exevents.c)
  DeliverFocusedEvent (Xi/exevents.c)

Then `DeliverFocusedEvent` finds that `keydb->focus->win ==
PointerRootWin`. This causes it to try delivering the events with
`DeliverDeviceEvents` to "the Window underneath the sprite" but it
fails,

  DeliverDeviceEvents (dix/events.c)

In the delivery loop,

    mask == EVENT_CORE_MASK
    IsMaster(dev) == 0
    dev->coreEvents == 4

therefore nothing gets delivered. I suspect the problem is the lack of
a focused window. `DeliverFocusedEvent` should be falling through the initial
checks to the "just deliver it to the focus window" behavior. Why is there no focused window?

Some useful discussion of this issue has happened on the list[1].

[1] http://lists.x.org/archives/xorg/2013-November/056209.html

http://patchwork.freedesktop.org/patch/16209/

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/593.