Problem with touchscreen events and grabs

[Thierry Reding]

On Tue, Oct 16, 2012 at 01:09:53PM +1000, Peter Hutterer wrote:
> On Fri, Oct 12, 2012 at 03:38:24PM +0200, Thierry Reding wrote:
> > Hi,
> > 
> > I've been seeing a very strange issue. Originally this was observed when
> > using a browser with an onscreen keyboard. It would sometimes happen
> > that the keys on the keyboard would get stuck and be repeatedly sent.
> > 
> > While trying to debug this, I came across a reliable way to reproduce it
> > using xwininfo. Basically I would run xwininfo and select the onscreen
> > keyboard. This would immediately result in the key being pressed and not
> > receiving a release event. Using other keys on the onscreen keyboard
> > would make them pressed as well, but never released either, resulting in
> > repeated keypresses received by the browser. It seems like X for some
> > reason believes that the press event is actually a release and vice-
> > versa.
> > 
> > In order to find out what exactly was going on, I fired up xev with the
> > window XID as reported by xwininfo. This would indeed show the repeated
> > key events sent to the onscreen keyboard's window. Strangely enough, if
> > xev is started without an existing window XID, generating touch events
> > in that window seems to "fix" the issue. The keyboard can be used
> > reliably again.
> > 
> > Furthermore, when running xwininfo and selecting the onscreen keyboard,
> > a second call to xwininfo would fail, saying it cannot grab the mouse.
> > This issue can be reliably reproduced independent of the onscreen
> > keyboard and works with any X window. So opening an xterm for instance,
> > then running xwininfo and selecting xterm will cause any subsequent
> > calls to xwininfo to fail. Running xev and generating touch events in
> > its window again fixes things.
> > 
> > It seems like the X server doesn't properly release the grab and gets
> > the touch down and up events mixed up. Note that all of this only
> > happens when using a touchscreen device. Performing the same tests using
> > a regular USB mouse to select the X window for xwininfo doesn't show the
> > same behaviour.
> > 
> > I'm using version 1.13 of the X server and xf86-input-evdev 2.7.3. Can
> > anybody else reproduce this?
> > 
> > If you need any more information I'd be happy to provide it.
> 
> Can you reproduce this with xinput -- test-xi2 and check what happens to the
> touch events? In particular the raw events.

Okay, since I can reliably reproduce this with the browser/on-screen-
keyboard setup, I fired up the browser, activated the OSK, run "xinput
test-xi2" in an SSH session and run xwininfo in another SSH session.

Once I press the 'D' key on the keyboard (which selects the OSK window
for xwininfo), the key gets stuck as I described before and the browser
location bar fills up with 'd's. Here is the output of xinput after the
keypress:

    EVENT type 22 (RawTouchBegin)
        device: 2 (8)
        detail: 65
        valuators:
              0: 7664.00 (7664.00)
              1: 26480.00 (26480.00)

    EVENT type 23 (RawTouchUpdate)
        device: 2 (8)
        detail: 65
        valuators:
              0: 7664.00 (0.00)
              1: 26512.00 (26512.00)

    EVENT type 23 (RawTouchUpdate)
        device: 2 (8)
        detail: 65
        valuators:
              0: 7664.00 (0.00)
              1: 26544.00 (26544.00)

    EVENT type 23 (RawTouchUpdate)
        device: 2 (8)
        detail: 65
        valuators:
              0: 7664.00 (0.00)
              1: 26592.00 (26592.00)

    EVENT type 24 (RawTouchEnd)
        device: 2 (8)
        detail: 65
        valuators:
              0: 7664.00 (0.00)
              1: 26592.00 (0.00)

    EVENT type 13 (RawKeyPress)
        device: 3 (5)
        detail: 40
        valuators:

So the RawKeyReleased event never seems to appear, which would explain
why the button press keeps being repeated. I then press the 'S' key,
which results in that key becoming stuck as well and the location bar
filling up with 's's. Again, here's the output from xinput:

    EVENT type 22 (RawTouchBegin)
        device: 2 (8)
        detail: 66
        valuators:
              0: 4768.00 (4768.00)
              1: 26448.00 (26448.00)

    EVENT type 23 (RawTouchUpdate)
        device: 2 (8)
        detail: 66
        valuators:
              0: 4752.00 (4752.00)
              1: 26480.00 (26480.00)

    EVENT type 23 (RawTouchUpdate)
        device: 2 (8)
        detail: 66
        valuators:
              0: 4768.00 (4768.00)
              1: 26512.00 (26512.00)

    EVENT type 24 (RawTouchEnd)
        device: 2 (8)
        detail: 66
        valuators:
              0: 4768.00 (0.00)
              1: 26512.00 (0.00)

    EVENT type 14 (RawKeyRelease)
        device: 3 (5)
        detail: 40
        valuators:

    EVENT type 13 (RawKeyPress)
        device: 3 (5)
        detail: 39
        valuators:

So touch events seem to be properly processed, but RawKeyRelease and
RawKeyPress seem to be inverted.

> Also try to compile your server with the dtrace hooks enabled and look at
> c0b0a9bce9237b0abe150c1a7b54939affecc751 for a example systemtap script.
> That should tell you what events the driver submits to the server.

It looks like dtrace might be hard to get to work. Oddly the X server
has the --with-dtrace option, but the commit you pointed to mentions
systemtap. From the looks of it, systemtap is the Linux implementation
of dtrace, is that correct? Since this is a cross-compilation setup
things might get a little hairy to setup properly. Though I'd first have
to convince the X server to accept systemtap as dtrace replacement. Or
won't that work?

> But on the whole, this issue looks convoluted enough that you may have to
> write a little test application to reliably reproduce this.

I can reliably reproduce this alright. If it helps I can look into
providing a standalone version of the OSK.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121016/c70609a9/attachment.pgp>