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
pgpb7Hz6Q40nu.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
