Problem with touchscreen events and grabs

[Peter Hutterer]

On Tue, Oct 16, 2012 at 08:42:56AM +0200, Thierry Reding wrote:
> 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:

right, but the sourceid of 5 on the RawKeyPress indicates that this is an
XTest event (i.e. from the OSK). the raw touch end event is sent, so the
driver is fine here. Either the TouchEnd/emulated ButtonRelease is never
sent to the OSK, or the OSK doesn't handle it correctly.

you could try putting xscope in between the OSK and your server to see if
the ButtonRelease is sent at all.

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

if the dtrace probes are built successfully, the script in the commit
message to c0b0a9bce9237b0abe150c1a7b54939affecc751 should work as systemtap
script for those probes.

mind you, this particular script is for testing the driver API and the event
sequence above suggests that that bit is fine. you can debug the events sent
by the server with systemtap as well, but that's a bit more... involved.

try http://people.freedesktop.org/~whot/xserver.stp, but no guarantees that
won't crash your kernel. Haven't used and updated it in a while.

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

do you have the source for the OSK? Can you figure out if it ever receives
the TouchEnd/ButtonRelase?

Cheers,
   Peter