Problem with touchscreen events and grabs
Thierry Reding
thierry.reding at avionic-design.de
Tue Oct 16 23:04:55 PDT 2012
On Wed, Oct 17, 2012 at 10:02:37AM +1000, Peter Hutterer wrote:
> 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.
I don't think the OSK is at fault here. As I see it, it should never
even get the press event in the first place. If I repeat the same with a
mouse attached, I get the following sequence of events:
EVENT type 15 (RawButtonPress)
device: 2 (11)
detail: 1
valuators:
flags:
EVENT type 16 (RawButtonRelease)
device: 2 (11)
detail: 1
valuators:
flags:
And the OSK doesn't react to a button press. Note that this is the same
setup as before (browser with OSK started, running xwininfo and pressing
the 'D' key). I can repeat the same using the touchscreen and it always
results in the key getting stuck.
> you could try putting xscope in between the OSK and your server to see if
> the ButtonRelease is sent at all.
Alright, I'll see if I can set this up.
> >
> > 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.
Okay, I'll try to find out more using xscope as you suggest above and
keep this in mind as a last resort.
> > > 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?
Yes, I do have the source for the OSK. I'll try to sprinkle it with some
debugging output to gather some more information. But again, I do think
the USB mouse test shows that the OSK is not the problem, though.
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/20121017/d621e166/attachment-0001.pgp>
More information about the xorg-devel
mailing list