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