Inconsistent mouse events for Acer T231H multitouch monitor
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HWE Next |
Fix Released
|
Undecided
|
Unassigned | ||
Saucy |
Fix Released
|
Undecided
|
Unassigned | ||
X.Org X server |
Fix Released
|
Medium
|
|||
xorg-server (Ubuntu) |
Fix Released
|
High
|
Chase Douglas | ||
Precise |
Won't Fix
|
Undecided
|
Maarten Lankhorst |
Bug Description
I already submitted this at http://
My setup is a quantal alpha 1, just upgraded from precise, with an Acer T231H multitouch monitor connected to it, as well as an ordinary mouse for testing. The mouse events as X sends them to the applications are inconsitent. This can be debugged using xev.
The first touch of the screen is preceeded by a MotionNotify event which already has state 0x100, i.e. left mouse button pressed. After that comes a ButtonPress event, again with state 0x100 although that value should indicate the state of the buttons before the event occurred. The subsequent drag is all right, and the ButtonRelease as well, but the 0x100 bit in the state value will never become zero again.
Even if I've got an ordinary mouse connected as well, it will henceforth report every movement as if I were keeping the left mouse button down. The only cure that I could find was restarting the X server. Together with the ButtonPress and ButtonRelease events, this constant bit for left mouse button amounts to an inconsistent reporting of button state.
Java applications e.g. will report every move as a drag due to this issue, with severe implications for focus management. This makes using differenent parts of the application almost impossible, as mouse movement will only be reported to the component where the mouse entered the application window.
Since reporting at askubuntu, I've run some tests with evtest. The data coming from the event device looks sane enough: BTN_TOUCH events for the first finger, with value 1 for pressed and 0 for released. ABS_MT_TRACKING_ID for all fingers, with a non-negative value for pressed and -1 for released. The grouping into syn groups looks sane as well. So I'd say the kernel driver works as intended, and somewhere from there to the xevent layer, some internal state gets messed up.
I'm willing to try out any patches you might propose, be it in an attempt to fix this, or only to gather more information.
Expected behaviour:
MotionNotify with state 0x000 when dragging the ordinary mouse
MotionNotify with state 0x000 for move prior to touch, or no event at all
ButtonPress with state 0x000 when touching the screen
MotionNotify with state 0x100 while dragging the finger
ButtonRelease with state 0x100 when lifting the finger
MotionNotify with state 0x000 when dragging the ordinary mouse afterwards
Actual behaviour:
MotionNotify with state 0x000 when dragging the ordinary mouse before the first touch
MotionNotify with state 0x100 for prior to ButtonPress event
ButtonPress with state 0x100 when touching the screen
MotionNotify with state 0x100 while dragging the finger
ButtonRelease with state 0x100 when lifting the finger
MotionNotify with state 0x100 when dragging the ordinary mouse afterwards
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: xserver-
ProcVersionSign
Uname: Linux 3.4.0-5-generic x86_64
ApportVersion: 2.2.3-0ubuntu5
Architecture: amd64
CurrentDmesg: [ 7.381404] ADDRCONF(
Date: Tue Jun 19 17:56:46 2012
DistUpgraded: 2012-06-19 17:51:23,756 DEBUG enabling apt cron job
DistroCodename: quantal
DistroVariant: ubuntu
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: xserver-
UpgradeStatus: Upgraded to quantal on 2012-06-19 (0 days ago)
dmi.bios.date: 09/22/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.4
dmi.board.name: AMD HUDSON-M1
dmi.board.vendor: ZOTAC
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAmerican
version.compiz: compiz 1:0.9.7.8-0ubuntu3
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.33-1
version.
version.
version.
version.
version.
version.
version.
version.
Martin von Gagern (gagern) wrote : | #1 |
- BootDmesg.txt Edit (71.3 KiB, text/plain; charset="utf-8")
- BootLog.txt Edit (2.5 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.4 KiB, text/plain; charset="utf-8")
- DpkgLog.txt Edit (1.9 MiB, text/plain; charset="utf-8")
- LightdmLog.txt Edit (2.1 KiB, text/plain; charset="utf-8")
- Lspci.txt Edit (16.4 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (863 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.8 KiB, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (1.7 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (3.5 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (119.8 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (292.4 KiB, text/plain; charset="utf-8")
- XorgLog.txt Edit (50.3 KiB, text/plain; charset="utf-8")
- XorgLogOld.txt Edit (53.3 KiB, text/plain; charset="utf-8")
- peripherals.txt Edit (513 bytes, text/plain; charset="utf-8")
- xinput.txt Edit (838 bytes, text/plain; charset="utf-8")
Martin von Gagern (gagern) wrote : | #2 |
Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
Changed in xserver-xorg-input-evdev (Ubuntu): | |
status: | New → Confirmed |
tags: | added: kubuntu |
tags: | added: touch |
Krastanov (krastanov-stefan) wrote : | #5 |
The same behavior on another hardware is reported in this question:
https:/
concerning the wetab tablet with egalax touchscreen
Martin von Gagern (gagern) wrote : | #6 |
Similar behaviour, but not entirely the same: I do receive press events. The incorrect status is the same, though.
Krastanov (krastanov-stefan) wrote : | #7 |
Does `xdotool mousedown/
They do not help for the egalax touchscreen.
Martin von Gagern (gagern) wrote : | #8 |
OK, I bvelieve I've identified the main problem here:
http://
http://
Due to that commit, the ET_TouchEnd branch of UpdateDeviceState never receives the TOUCH_END flag it expects, so it never lifts the button. In fact, there are currently only two references to the TOUCH_END macro in the whole upstream xorg git tree: one its definition in include/input.h, the other this check in Xi/exevents.c. There is noone left ever setting this flag.
http://
http://
The reodering of events which the commit does will also break the state reported for the release event. As far as I understand things (and as it behaves for my regular mouse), the state should reflect the state of buttons BEFORE the event happened. There is a comment to that effect somewhere in the X sources. Reordering the calls in ProcessTouchEvent will cause the state to be already 0 for the release event, where it should be 0x100 still.
As the original commit originated from Chase Douglas who is a member of the ubuntu-x-swat team, I suppose he will read this message here and might provide additional information as to how his change was intended to work, and whether backing it out of the code will likely break things for other users. If he doesn't usually follow bug mail, someone please make him aware of this issue here.
The only remaining problem is the fact that the ButtonPress event has state 0x100 already, where it should have state 0x000 to match the lack of pressed buttons preceeding that event. I'll see whether I can pinpoint that problem as well. If I can, I will attach a patch including that fix as well. Otherwise a simple reverse application of the commit I pointed out above will be enough.
@Stefan Krastanov, please see if this fix works for you, otherwise please open a new bug report for your issue.
Martin von Gagern (gagern) wrote : | #9 |
OK, I believe I now have a good idea as to why the first ButtonPress in xev has state 0x100. This appears to be due to an TouchOwnership event. If ownership changes, such an event is inserted into the queue, so it will always be processed after the BeginTouch event. I wonder how much later it might get processed, but as there appears to be some history, I simply assume everything is all right there. So the TouchBegin arrives, sets state = 0x100, enqueues an Ownership event, and when that arrives, ProcessTouchOwn
For source code of TouchRejected, see
http://
I haven't come up with a fix yet, as I haven't fully understood this whole ownership and history/replay business here. But I assume that a proper fix would be restoring the state to what it was at the beginning of the history before replaying said history. Input from people more fluent in that code would be greatly appreciated.
Martin von Gagern (gagern) wrote : | #10 |
I have a patch for the second issue of the mouse state during replay. Will attach it here shortly. I'm currently trying to get this to my PPA, for quantal first and for precise afterwards.
Editing the change log, I found that the removal of the TOUCH_END is not part of the orig tarball, but comes from an ubuntu patch, 507_touchscreen
Martin von Gagern (gagern) wrote : | #11 |
Martin von Gagern (gagern) wrote : | #12 |
Martin von Gagern (gagern) wrote : | #13 |
OK, here are the two patches which I currently use to get a working core pointer from my touch screen. I've included them in packages available from https:/
Ubuntu Foundations Team Bug Bot (crichton) wrote : | #14 |
The attachment "Reverse commit which removed TOUCH_END" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.
[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]
tags: | added: patch |
Martin von Gagern (gagern) wrote : | #15 |
As the core pointer button state appears to be exclusively maintained inside the x server core, the evdev driver is blameless.
Changed in xserver-xorg-input-evdev (Ubuntu): | |
status: | Confirmed → Invalid |
Cédric Dufour (cdufour-keyword-ubuntu-086000) wrote : | #16 |
Also affected: Atmel maXtouch (see https:/
Cédric Dufour (cdufour-keyword-ubuntu-086000) wrote : | #17 |
I applied the patches in #11 and #12 to the current precise xserver-xorg-core source (1.11.4-
Worse, drag'n drop does not work anylonger (e.g. to move a window by cliking-
Sorry for the negative report.
Chase Douglas (chasedouglas) wrote : | #18 |
Hi Martin,
Thanks for finding this issue. Good work on making some patches, but I don't think they are quite right. We need to set the internal button state of the device when the touch begin comes in, otherwise we will not get the right result when we call {X,XI}QueryPoin
A simpler solution would be to modify DeliverTouchEmu
ptrev->
We need to modify it so that it also passes in a boolean to event_get_
I will attempt to make a test and a patch for this tomorrow.
Thanks!
Changed in xorg-server (Ubuntu): | |
status: | Confirmed → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Chase Douglas (chasedouglas) |
no longer affects: | xserver-xorg-input-evdev (Ubuntu) |
Chase Douglas (chasedouglas) wrote : | #19 |
Upstream patch has been posted here:
http://
Cédric Dufour (cdufour-keyword-ubuntu-086000) wrote : | #20 |
Hello Chase,
Thank you for looking into this.
When not subscribed to the X.org mailing list, obtaining the patch is kind of a hassle (I couldn't find a download option and I'd rather avoid copy/paste). Can you post it here too, so we can download/test it? Or will it be included in the next xserver-xorg-core package update?
Thanks again,
Cédric
Martin von Gagern (gagern) wrote : | #21 |
Hi Chase,
thank you for looking into this, and working towards a solution.
Is the patch you referenced intended as a replacement for both my patches? Working with the touch screen alone, things work out fairly well. But if I also use a mouse, then the lack of a TOUCH_END event still causes the mouse moves to register as drags, i.e. with state 0x100. So I feel like your patch might be a suitable replacement for the one in comment #12, but the one in comment #11 is still required.
I guess you head a good reason to write the changes I mentioned in comment #8, the ones which #11 backs out. I must confess I still haven't fully understood the rationale behind that commit, mostly because I still don't know about that listener concept. So perhaps you want to improve that change instead of reverting it. A proper proof should probably get rid of every occurrence of the TOUCH_END macro in the code. It should be tested on a setup with both a touch and a classical mouse device.
Martin von Gagern (gagern) wrote : | #22 |
With that patch by Chase, I also wonder what would happen if two touch devices were used simultaneously.
When I both touch my screen and click my conventional mouse button, I get two button events, but the state is the bitwise or of both, so the second click will be "pressed button 1 while button 1 was pressed". Makes sense, in a certain way, although it might well confuse some applications.
But what if I had two touch devices controlling the core pointer? I believe it is likely with the current setup that in this case, the second device would generate a ButtonPress with state 0x000. Or is it impossible for more than one touch device to control the core pointer at a given time? I don't have more than one device, so I can't test this.
I'll agree that given current technology, this seems a rather rare corner case, and probably not worth the effort to deal with properly. But any shortcomings in that respect should perhaps at least be documented somewhere.
Martin von Gagern (gagern) wrote : | #23 |
Martin von Gagern (gagern) wrote : | #24 |
Cédric, I attached the patch, after copy & paste from gmane. But it applies all right, at least to the xorg-server-
I updated https:/
Cédric Dufour (cdufour-keyword-ubuntu-086000) wrote : | #25 |
Hello,
Thanks Martin for your PPA and the precise packages; unfortunately, I run amd64 :-/
I first applied only #19 patch (yes, it did require some adjustments) to the latest precise X.org packages (1.11.4-
Then I saw Martin's comment and applied patches #11 and #19: behavior remains the same (as far as Compiz plugins...) AND windows moving (clicking-
I think we can conclude that #11 triggers the "windows moving (clicking-
Now, I'm wondering whether Compiz might have some problem on its own. Example given: I loose single/double click as soon as I launch the "Expo" plugin and select (double-click on) a viewport. After, no amount of single/
I also gave #19 patch (alone) a try without launching Compiz (use metacity alone instead) or multi-touch (ginn) stuff. Before, even in that (no-compiz/no-ginn) scenario, single/
Launching Compiz alone (without ginn), and all problems are back.
Conclusion using patch #19, without patch #11 (cf. "windows moving (clicking-
About that "sometime, one must (single) click two time on an icon for the expected behavior to happen": I can reproduce the behavior systematically by: 1. clicking on a network-manager icon (menu opens), 2. clicking on the desktop to close the menu (menu closes), 3. clicking on a network-manager icon again (menu does not open; instead, a selection rectangle is drawn), 4. clicking on a network-manager icon again (this time, menu opens again)
Let me know if I can help any further.
Martin von Gagern (gagern) wrote : | #26 |
Hi Cédric,
Although this took a little while longer, the amd packages have been built successfully by now, and are available from my ppa.
I have the impression that your problems manifest in cases when some application is listening to the higher level touch interfaces, presumably using XInput. My problems on the other hand occur in a bare bones X where applications only use the core pointer. Those appear to be two sides of a coin: the commit reverted by comment #11 was intended to deal with a changing set of listeners, which to me sounds like some gesture-
Cédric Dufour (cdufour-keyword-ubuntu-086000) wrote : | #27 |
Hello Martin,
Yes indeed, it seems we're bumping is several different issues. Yours - and its fix - helped improve the global picture. I have absolutely no understanding of how all that X and multi-touch works, so I don't know where to start from (in respect with where/how to report the other issues). All I can do is give as detailed a report as possible, so those who know can extract what hopefully useful information they can (and maybe point some directions for further bug reporting and/or testing).
Thanks for keeping up with me so far ;-)
Cheers
Chase Douglas (chasedouglas) wrote : Re: [Bug 1015183] Re: Inconsistent mouse events for Acer T231H multitouch monitor | #28 |
On 07/04/2012 03:30 AM, Martin von Gagern wrote:
> Is the patch you referenced intended as a replacement for both my
> patches? Working with the touch screen alone, things work out fairly
> well. But if I also use a mouse, then the lack of a TOUCH_END event
> still causes the mouse moves to register as drags, i.e. with state
> 0x100. So I feel like your patch might be a suitable replacement for the
> one in comment #12, but the one in comment #11 is still required.
If you aren't receiving a TouchEnd event, then there is something wrong.
The patch you are reverting is needed to fix a different bug. If you can
reproduce the issue easily, please describe how. Then we can look to
resolve it.
Thanks!
Chase Douglas (chasedouglas) wrote : | #29 |
On 07/04/2012 03:37 AM, Martin von Gagern wrote:
> With that patch by Chase, I also wonder what would happen if two touch
> devices were used simultaneously.
>
> When I both touch my screen and click my conventional mouse button, I
> get two button events, but the state is the bitwise or of both, so the
> second click will be "pressed button 1 while button 1 was pressed".
> Makes sense, in a certain way, although it might well confuse some
> applications.
>
> But what if I had two touch devices controlling the core pointer? I
> believe it is likely with the current setup that in this case, the
> second device would generate a ButtonPress with state 0x000. Or is it
> impossible for more than one touch device to control the core pointer at
> a given time? I don't have more than one device, so I can't test this.
>
> I'll agree that given current technology, this seems a rather rare
> corner case, and probably not worth the effort to deal with properly.
> But any shortcomings in that respect should perhaps at least be
> documented somewhere.
Great point here :). I had to look at the code to determine the correct
answer. I worried that, like you said, it would be buggy if you had two
touchscreens. However, this should not be a problem.
Input devices have a two-layer hierarchy. There are slave devices and
master devices. Slave devices represent a physical device, like a
touchscreen. Master devices represent a group of slave devices. Most
people only have one master device configured, and all the slave devices
are attached to it. If you have two mice, you can create a second master
and attach one slave mouse to each. Then you'll have two independent
pointers on screen :).
A client can listen to events from master and/or slave devices. The
events look and behave almost exactly the same. When you press your
mouse button, a button press event is generated for the slave device and
the attached master device.
If you have two touchscreens with one master, then each slave device can
emulate a button press event. However, there can be only one emulated
touch per device (no matter whether it's a slave or a master), so the
first touch is emulated for the master, and the second touch is not.
Thanks!
Martin von Gagern (gagern) wrote : | #30 |
On 05.07.2012 23:35, Chase Douglas wrote:
> If you aren't receiving a TouchEnd event, then there is something wrong.
I am receiving the TouchEnd, but it doesn't update the core state the
way it should.
> The patch you are reverting is needed to fix a different bug. If you can
> reproduce the issue easily, please describe how. Then we can look to
> resolve it.
Please re-read comment #8.
Steps to reproduce:
1. Start xev
2. Touch screen and release
3. Move regular mouse
Expected behaviour:
2. Release event with state 0x100
3. Mouse move with state 0x000
Actual behaviour:
3. Mouse move with state 0x100
Behaviour if you simply disable the check for the TOUCH_END flag in
UpdateDeviceState:
2. Release event already with state 0x000
Trent Piepho (tpiepho) wrote : | #31 |
I see this same behavior on a Samsung Slate 7, which has an Atmel maxtouch multitouch touchscreen. Running Precise, with xserver-
If I don't touch the touchscreen since the X server has started, xev reports the state of events as expected when using a mouse. 0x000 for the ButtonPress, 0x100 for motion with the button down and the ButtonRelease, then 0x000 after. However, after the touchscreen is touched once, the state becomes 0x100 for the first ButtonPress from the touchscreen and stays at 0x100 thereafter, even after the ButtonRelease. Keyboard keys, mouse clicks, mouse motion, etc. are all state 0x100 until the X server is restarted.
Trent Piepho (tpiepho) wrote : | #32 |
Found out something new. I compiled the git version of evdev, xf86-input-
Once I modified configure.ac to turn MULTITOUCH back on, then the problem was back as well and state is locked to 0x100 after the touchscreen is used.
I've also found that I get far more of the problems Cédric mentions when ginn is running. It seems like what happens is the touchscreen stops generating ButtonPress events, but it still does motion events and state is still locked at 0x100. So the effect is that one is moving the pointer around with the button held down, but never pushing the button. This usually seems like left-click has stopped working. But I imagine the state problem and the resulting "drags with no click" can explain in some strange behavior seen in certain apps.
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #45 |
I'm able to "lock up" the Unity session by opening menus quickly by using a touchscreen. Seems as if there's a grab active. I can see the tooltips from launcher icons, interact with focused apps, but that's it.
Can't reproduce with plain metacity, because the menus open so quickly with it, whereas with Unity on this hw the effects slow it down so that the race is hit.
Tried several of the recent patches on top of 1.13, but they haven't helped. Now I see there are newer patches available. I'll give them a try. Filed this one for tracking this particular issue.
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #46 |
tried patches from 56558 and 55738, also "Sync TouchListener memory.." from Carlos Garnacho, didn't help.
In freedesktop.org Bugzilla #56578, Daniel d'Andrada (dandrader) wrote : | #47 |
I just repeatedly tap on the top-most icon (the one which has the Ubuntu logo) of Ubuntu's launcher in a touchscreen. Those taps alternately open and close the dash (a fullscreen window that shows icons for applications, media and other files). Eventually those taps stop having any effect. I.e., the launcher no longer gets ButtonPress and ButtonRelease events out of them.
I've added a wealth of logging (see xorg.log attachment) to try to understand what's happening on the server. From looking at it could see the following:
From touches 2 to 26, launcher is the first window in the list of listeners. From touch 27 onwards, the root window is the first one. Problem is, from touch 27 onwards, xserver fails to pass the touch ownership down to the launcher window because there's always an older pointer-emulated touch (touch 26) lying around which it apparently can't get rid of (i.e. properly process).
In freedesktop.org Bugzilla #56578, Daniel d'Andrada (dandrader) wrote : | #48 |
Created attachment 70064
log output of the "repeated tapping on ubuntu logo launcher icon" use case
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #49 |
Do cross-check with Bug 56557 as well, this can cause issues if any grabs are activated on the root window and I wonder if that influences the behaviour here
In freedesktop.org Bugzilla #56578, Daniel d'Andrada (dandrader) wrote : | #50 |
(In reply to comment #4)
> Do cross-check with Bug 56557 as well, this can cause issues if any grabs
> are activated on the root window and I wonder if that influences the
> behaviour here
Yes, they are at least closely related (most likely have the same cause) as a pointer-emulated touch gets "stuck" because of failed resource lookups in RetrieveTouchDe
In freedesktop.org Bugzilla #56578, Daniel d'Andrada (dandrader) wrote : | #51 |
Created attachment 70422
log output of use case with patches from bug 56557 applied
With the 4 patches mentioned in bug 56557 applied (comments 3 and 4), the bug (missing ButtonPress and ButtonRelease events) manifests itself already on the second tap on the touchscreen.
Again, due to a failure in RetrieveTouchDe
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #52 |
New set of patches, please try those on top of the current set you already tested.
http://
http://
http://
http://
In freedesktop.org Bugzilla #56578, Daniel d'Andrada (dandrader) wrote : | #53 |
Created attachment 70656
log output of use case with patches from Comment 7 also applied
This is the log output I get with this new set of patches (from Comment 7) applied on top of those mentioned in Comment 6.
Again, the same problem.
The first tap on the icon with the ubuntu logo in the launcher (top left corner of the screen) works fine and displays the dash (a fullscreen window showing application icons, etc). The launcher now has a active pointer grab.
Upon the second tap on the ubuntu icon, xserver fails to deliver events to that listener (laucnher's active pointer grab) because the corresponding RetrieveTouchDe
"""
(II) TouchBeginDDXTouch: ddx id 0, touch 2 - returning with emulate pointer == 1
[ 2859.473] (II) ProcessTouchEvent: TouchBegin, master pointer, touch 2
...
[ 2859.474] (II) RetrieveTouchDe
[ 2859.474] (II) dixLookupClient: failed! - rid & SERVER_BIT
[ 2859.474] (II) - Not delivering to listener 1105199104 because his delivery data couldn't be retrieved.
"""
tags: | added: blocks-hwcert-enablement |
Maarten Lankhorst (mlankhorst) wrote : | #33 |
Could you recheck on raring? It seems there have been some touch related fixes in xorg-server since the quantal xserver release.
In freedesktop.org Bugzilla #56578, Jrand (jrand) wrote : | #54 |
We are also experiencing this bug with other touch screen software, not Unity related. The underlying X problem seems to be identical. Has a solution been found?
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #55 |
Nope, the bug is still there. Rasterman reproduced it with E17 and commented on the downstream bug:
https:/
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #56 |
can you test this branch here please? http://
Last 5 commits (currently), starting with 2cd9c4f709f105b
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #57 |
unfortunately still able to reproduce it :/
I needed these commits on top of 1.13.2 to be able to compile with the new patches:
cc79107a5b60d29
fe59774c55e5d42
91ab237358c6e33
9ad0fdb135a1c33
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #58 |
You'll need all of http://
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #59 |
Sorry, to clarify: you need that 1.13 branch linked above AND the patches from Comment 11
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #60 |
Created attachment 74845
evemu-record from the touchscreen
attached the evemu dump from reproducing the bug by hitting the unity indicators quickly a couple of times.
I'll try the more complete 1.13 build next.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #61 |
Ok, analysis of the bug as follows. To trigger this bug, we need the following client stack:
* touch client with a passive touch grab
* core client with a passive button grab in GrabmodeSync
* optional: core client with button mask on window
The touch client must reject the touch.
As the touch grab activates, all events are sent to the touch client, and stored in the touch event history. When the client rejects, the events are replayed on the next client.
The replayed TouchBegin will trigger the core passive grab, and switch the device's processInputProc to EnqueueEvent().
BUG 1: because touch event history replaying calls DeliverTouchEvents directly, EnqueueEvent is side-stepped and no events end up in the sync'd queue. Later, when the client calls XAllowEvents no events are there for syncing, ComputeFreezes() exits early and the emulated motion/release events are not sent to the client.
Fixing that is possible so that EnqueueEvent is honoured. Tricky though, because it will have a number of side-effects, see below.
BUG 2: because the TouchEnd never ends up in the history (by design) no release event ends up in the queue. So when replaying, the emulated button release is missing. Not sure yet how to fix this.
BUG3: If there's the optional third client, it's implicit passive grab currently does not get released. That's the easiest one to fix.
Side effects of the first bug:
If we use EnqueueEvent() for event history replaying, we will replay touch events into the sync buffer, but not actually process them. If there is at least one touch client below the client with the sync passive core grab, it cannot get touch events until the grabbing client calls XAllowEvents. If that touch client has the ownership mask set, that behaviour is against the protocol spec.
Coincidentally, this bug already exists anyway, it's just gone unnoticed so far because touch clients appear to be generally above the normal clients.
To be compliant with the touch specs, we need to wrap EnqueueEvent to still handle touch events for clients with the ownership mask even if the device is currently synced.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #62 |
Branch available for testing here. I think this fixes the issue but I've been unsuccessful getting this backported to a 1.13 ubuntu server.
http://
If you can test this, that'd be much appreciated.
In freedesktop.org Bugzilla #56578, Jrand (jrand) wrote : | #63 |
Hi Peter, I think your recent patches do fix the issue.
I compiled your server and a fresh xinput evdev 2.7.3. I confirmed TouchBegin TouchEnd were being sent with a brief xinput test-xi2 test.
# xdpyinfo |grep -E '(vendor|version)'
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 11399902
X.Org version: 1.13.99.902
My usual scenario to experience this problem is:
run Chrome
xwininfo [tap root screen, get window id of chrome window]
xev -id 0x.... [use window id of chrome window]
tap screen a few times to see xev notify events
ctrl-C
on screen, touch a UI button
the press activates the UI button
screen switches to new page <-- ButtonRelease is dropped somewhere from here
the new UI button underlying where my finger just pressed is stuck down
^--- to here
With these same testing steps above I cannot get a stuck button on your new xserver branch. It seems that the ButtonRelease event arrives correctly.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #64 |
Thanks John, much appreciated.
First patchset, minor changes for preparation:
http://
http://
http://
http://
http://
http://
http://
Second patchset, the actual meat:
http://
http://
http://
http://
http://
http://
http://
http://
http://
http://
http://
http://
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #65 |
Ok I've tested them as well by building 1.14rc minus the video abi changing stuff (and commits on top of them), and added the touch branch. This allowed me to test on the nexus7 & tegra3 blob.
Looks like it's much better now, although sometimes the touch appears to get somewhat hung but can recover from it later on, and when this happens also generates messages like
[ 5101.196] [Xi] Too many valuators reported for device 'Virtual core pointer'. Ignoring event.
on the logfile. The buffered actions prior to the hang are replayed after waiting for a while. At this stage it's quite easy to crash the server.
Jrand (jrand) wrote : | #34 |
note recent updates for the xorg bug here:
https:/
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #66 |
do you have a good backtrace for the crashes? random, or always the same spot? Is it regular in response to some interaction? can it be caused by the backports?
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #67 |
Created attachment 76003
backtrace
Here's the backtrace, seems to be the same every time.
Way to reproduce here:
1. open an app, so there's a window around
2. attach an external pointer device
3. tailf the X logfile
4. hit the panel indicators frantically with the touchscreen, until the touch input is locked
5. move the window with the other pointer device
6. see how some "[Xi] ..." messages appear on the logfile
7. repeat the steps until..
8. .. when the touch input is locked the logfile will get these Xi messages after every touch.. when this happens keep hitting the screen until it crashes, can take a couple of minutes :)
so, it's only after using the other pointer device for a grab when the touch input grab is released. Also, while in step 8 I noticed that the multitouch gestures of unity seemed to work, while the panel menus failed to react. Also, Onboard seemed to work as well. So, while locked I can drag a window with a three-touch gesture but not by a single touch drag from the titlebar.
Not sure what backports you mean, this is 1.14 with your branch, but ajax's video abi commits reverted so the blob (and thus unity) work.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #68 |
Created attachment 76034
valgrind spam that occurs when following tjaalton's instructions
I can reproduce this on x1.14 with my macbook pro in the manner tjaalton described. It didn't need the video abi revert.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #69 |
did you rebuild the drivers too? just wondering, because I used to get a similar crash on my backports but only when running against the system drivers, not against the upstream ones.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #70 |
I still crashed even if I rebuilt the drivers against the patched xorg-server, so it's not that.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #71 |
It seems that the ubuntu patches for synaptics trigger it, most likely not these:
02-do-not-
- makes synaptics no longer match input.keyboard
101_resolution_
- Add resolutiondetect atom and config option, to add a way to disable autodetect
115_evdev_
- uncomment 50-synaptics.conf
118_quell_
- only affects tools
124_syndaemon_
- only affects syndaemon
But these change some things around:
103_enable_
- sets RTCornerButton default to 2, and RBCornerButton default to 3
104_always_
- always sets up tap buttons in set_default_
106_always_
- guess :-)
128_disable_
129_disable_
- both disable 3 touch actions, to make three-touch gestures work
Presumably one of those default tweaks would cause it. I'll try to nail it down.
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #72 |
well I'm not using synaptics, so it's not the same crasher then?
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #73 |
crashes unpatched too, after all :)
I guess I didn't hammer enough on the touchpad like a 3 year old
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #74 |
The crash is in xorg-server by the way, not in the driver, and seems to involve memory freed in xorg-server. It just seems more likely that it involves multitouch handling in xorg-server in general, and is not a bug in a specific driver.
Either that or there are 2 different bugs in evdev and synaptics that both cause a similar backtrace in xorg-server, this somehow seems less likely to me. :)
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #75 |
can you bisect the server then? I honestly don't know where it triggers and given that it's 19 patches it'll be easier to bisect than figure it out otherwise.
fwiw, I've pushed the rebased branch (only a few squashes and reshuffling), please make sure you pull first.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #76 |
for reference, 1.13 server branch (at time of writing 1.13.3 release) crashes just as hard.
criser (devel-god) wrote : | #35 |
I had similiar problems with ubuntu 13.04 on an Acer Iconia Tab W500.
The patches in https:/
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #77 |
Thanks a lot for the hard work here. We see the same issue in Sugar, the UI is basically unusable with touch as we have a "global" grab.
I tested the patches from comment 19 against xserver-1.14.0, they do solve the problem, and I cannot see any new issues introduced by them.
I also tested to 1.13.3. In order to do that I first had to backport a few commits:
* Update the MD's position when a touch event is received
* Don't use GetTouchEvents when replaying events
* Don't use GetTouchEvents in EmitTouchEnd
Then I added the patches from comment #19, and things are now working equally well there.
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #78 |
Created attachment 77097
backtrace
the backport seems incomplete, since it's trivial to crash the server with unity by switching between opening the dash or indicator menus
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #79 |
The backported patches on 1.13.3 (from comment #32) have now been in OLPC's development builds for over a week and we haven't seen any adverse effects.
I've also done some testing on 1.14.0. I can make this crash (with no backtrace) simply by going a bit crazy on the touchscreen for a few minutes, both before and after this patch series. A problem for another day.
Based on this I would vote for going ahead with the merge of this patch series into master.
I also found a related bug with both 1.13.3 and 1.14.0 (both before and after these patches), and posted a patch here:
http://
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #80 |
first valgrind error is on
int emulate_pointer = ! !(ev->device_
So I guess it's safe to assume that ev is garbage..
Other writes seem to be related to ev too, judging from the valgrind output I guess random stuff gets overwritten.
Looking at SetTapState output:
0 -> 1
1 -> 10
moving state stuff
10 -> 2
2 -> 10
moving state stuff
10 -> 2
and then a few more 2 -> 10 and 10 -> 2 with moves until valgrinds starts complaining and xserver starts crashing:
(II) SetTapState - 10 -> 2 (millis:3928387395)
==25788== Invalid read of size 4
==25788== at 0x24236E: ProcessOtherEvent (exevents.c:1519)
==25788== by 0x264CAE: ProcessPointerEvent (xkbAccessX.c:751)
==25788== by 0x166641: PlayReleasedEvents (events.c:1217)
==25788== by 0x16DED4: ComputeFreezes (events.c:1297)
==25788== by 0x16E2E3: AllowSome (events.c:1725)
==25788== by 0x16E495: ProcAllowEvents (events.c:1785)
==25788== by 0x15DC45: Dispatch (dispatch.c:432)
==25788== by 0x14C5B9: main (main.c:295)
==25788== Address 0x122336b0 is 16 bytes before a block of size 152 free'd
==25788== at 0x4C2BA6C: free (in /usr/lib/
==25788== by 0x806D84A: sna_mode_wakeup (sna_display.
==25788== by 0x161F3B: WakeupHandler (dixutils.c:426)
==25788== by 0x2AF6E3: WaitForSomething (WaitFor.c:224)
==25788== by 0x15D9A0: Dispatch (dispatch.c:361)
==25788== by 0x14C5B9: main (main.c:295)
This is with the patches from comment #19 + daniel drake's patch
Digging more, looking up the InternalEvent struct..
int emulate_pointer = ! !(ev->device_
Now this is a function that is looking verrrrrrrry suspicious for type == ET_TouchOwnership..
I think it would make sense to have ET_TouchOwnership handled directly by ProcessTouchOwn
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #81 |
Created attachment 77621
Call ProcessTouchOwn
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #82 |
Valgrind came up with this complaint on 1.13.3 with the backported patches:
==15921== Invalid read of size 4
==15921== at 0x1D0A00: DeliverTouchEvents (exevents.c:1297)
==15921== by 0x1D2589: ProcessOtherEvent (exevents.c:1611)
==15921== by 0x1567C1: TouchEventHisto
==15921== by 0x1D0EBB: TouchPuntToNext
==15921== by 0x1D11EB: TouchRejected (exevents.c:1196)
==15921== by 0x1D28B5: ProcessOtherEvent (exevents.c:1223)
==15921== by 0x1E7DAB: ProcessPointerEvent (xkbAccessX.c:751)
==15921== by 0x204DC5: mieqProcessDevi
==15921== by 0x1570A7: TouchListenerAc
==15921== by 0x1D6AD3: ProcXIAllowEvents (xiallowev.c:128)
==15921== by 0x1D2BD5: ProcIDispatch (extinit.c:406)
==15921== by 0x13CC0D: Dispatch (dispatch.c:428)
==15921== Address 0xc6a0bac is 4 bytes inside a block of size 68 free'd
==15921== at 0x482E5B0: free (vg_replace_
==15921== by 0x14C129: DeletePassiveGrab (grabs.c:336)
==15921== by 0x1527FD: doFreeResource (resource.c:873)
==15921== by 0x152F7F: FreeResource (resource.c:903)
==15921== by 0x14C49F: DeletePassiveGr
==15921== by 0x144A7D: ProcUngrabButton (events.c:5640)
==15921== by 0x13CC0D: Dispatch (dispatch.c:428)
==15921== by 0x132035: main (main.c:298)
I picked the fixes from 57301 to 1.13 too: Xi: fix touch event selction conflicts (#57301), and the commit before that to make it apply.
This brings 1.13 dix and Xi to the 1.14 equivalent minus pointer barriers, as far as I can tell, but then I was getting the following segfault:
==1748== Invalid read of size 4
==1748== at 0x4831DCC: memcpy (mc_replace_
==1748== by 0x156959: TouchConvertToP
==1748== by 0x1D0FA3: DeliverTouchEmu
==1748== by 0x1D0C5F: DeliverTouchEvents (exevents.c:1920)
==1748== by 0x1D25B1: ProcessOtherEvent (exevents.c:1611)
==1748== by 0x1E7E03: ProcessPointerEvent (xkbAccessX.c:751)
==1748== by 0x1423B1: PlayReleasedEvents (events.c:1214)
==1748== by 0x146D13: ComputeFreezes (events.c:1294)
==1748== by 0x146F6B: AllowSome (events.c:1722)
==1748== by 0x1470BF: ProcAllowEvents (events.c:1785)
==1748== by 0x13CC0D: Dispatch (dispatch.c:428)
==1748== by 0x132035: main (main.c:298)
==1748== Address 0xcaa1284 is 156 bytes inside a block of size 280,000 free'd
==1748== at 0x482E5B0: free (vg_replace_
==1748== by 0x1570E3: TouchListenerAc
==1748== by 0x146D6F: ComputeFreezes (events.c:1282)
==1748== by 0x146F6B: AllowSome (events.c:1722)
==1748== by 0x1470BF: ProcAllowEvents (events.c:1785)
==1748== by 0x13CC0D: Dispatch (dispatch.c:428)
==1748== by 0x132035: main (main.c:298)
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #83 |
Note: macbook pro (synaptics) seems to work just fine with the 1.13.3 backports, so it looks like it's a separate bug due to different behavior on a true touch device. The valgrind backtraces were on arm/tegra, which also enables a software keyboard.
The easiest way to crash on ubuntu's xserver on the tegra is by making sure valgrind is running with --free-fill=fe so the freed memory is always reset to an invalid value.
Till Kamppeter (till-kamppeter) wrote : | #36 |
- touch-fix.patch Edit (2.0 KiB, text/plain)
I have partial (full) success (on the Lenovo Thinkpad Twist, an Intel-based convertible, see also bug 1068994):
I have rebuilt the current Raring package of xorg-server (1.13.3-0ubuntu5) with the following two patches:
(found via https:/
2. http://
and after that clicking via touch screen on the Lenovo Thinkpad Twist works reliably. Only remaining problems are (but the touch click ability does not get lost by them):
a. In Chromium when you create a new tab, the new tab contains icons for web apps (at least the app store and perhaps some examples). These icons cannot be clicked by touch, only with a mouse. All the rest in Chromium is clickable by touch.
b. Touch clicks do not work in XBMC, but after using and leaving XBMC with an external mouse on the normal desktop touch-clicking works again.
These are probably separate bugs which got revealed by the now working touch click.
Complete patch for xorg-server is attached.
Changed in xorg-server (Ubuntu): | |
importance: | Medium → High |
milestone: | none → ubuntu-13.04 |
Till Kamppeter (till-kamppeter) wrote : | #37 |
This bug is perhaps duplicate of bug 1099289 or bug 1068994. I have attached a patch (for xorg-server) to that bugs which solves the problem on the Lenovo Thinkpad Twist.
Till Kamppeter (till-kamppeter) wrote : | #38 |
Sorry, previous comment was meant for another bug.
Till Kamppeter (till-kamppeter) wrote : | #39 |
Possibly bug 1099289 or bug 1068994 are duplicates of this one.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #84 |
Created attachment 78124
touch-fix.patch
I have partial (full?) success (on the Lenovo Thinkpad Twist, an Intel-based convertible, see also https:/
I have rebuilt the current Ubuntu Raring package of xorg-server (1.13.3-0ubuntu5) with the following two patches:
(found via comment #17)
2. http://
and after that clicking via touch screen on the Lenovo Thinkpad Twist works reliably. Only remaining (minor) problems are (but the touch click ability does not get lost by them):
a. In Chromium when you create a new tab, the new tab contains icons for web apps (at least the app store and perhaps some examples). These icons cannot be clicked by touch, only with a mouse. All the rest in Chromium is clickable by touch.
b. Touch clicks do not work in XBMC, but after using and leaving XBMC with an external mouse on the normal desktop touch-clicking works again.
These are probably separate bugs which got revealed by the now working touch click.
Complete patch for xorg-server is attached.
Till Kamppeter (till-kamppeter) wrote : | #40 |
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #85 |
Created attachment 78125
touch-fix.patch
Sorry, patch is not complete. Here is the correct one.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #86 |
ok, thanks to Maarten's debugging we've found the issue. listener->grab is not copied but rather referenced, leaving the grab stale once it was deleted. Reproducible test case is simply:
XGrabButton()
pointer-emulating touch down
XUngrabButton()
trigger touch update/end
This doesn't necessarily crash, but once you run through valgrind to reset memory after freeing it we have a reliable crasher.
Till Kamppeter (till-kamppeter) wrote : | #41 |
I have built xorg-server with my patch also on the Nexus7 now and it works perfectly there with the desktop and all applications, too, and on the Nexu7 XBMC and Chromium's web apps work with touch.
It also seems to fix the Nexus 7 (bug 1068994).
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #87 |
I have built xorg-server with my patch also on the Nexus 7 (armhf) now and it works perfectly there with the desktop and all applications, too, and on the Nexus 7 XBMC and Chromium's web apps work with touch.
It also seems to fix the Nexus 7.
Krastanov (krastanov-stefan) wrote : | #42 |
@till-kamppeter, could you provide these modified builds in order to test them on different hardware.
Till Kamppeter (till-kamppeter) wrote : | #43 |
I have uploaded a test package (xorg-server 1.13.3-
sudo apt-get update
sudo apt-get upgrade
Does this fix your touch screen click problem?
Till Kamppeter (till-kamppeter) wrote : | #44 |
Binary test packages for the Nexus 7/armhf attached to bug 1068994.
Changed in xorg-server: | |
importance: | Unknown → Medium |
status: | Unknown → In Progress |
Krastanov (krastanov-stefan) wrote : | #88 |
The packages can not be tested on 13.04 because of:
xserver-xorg-core:
Depends: libaudit1 (>=1:2.2.1) but it is not installable
Depends: libc6 (>=2.17) but 2.15-0ubuntu20.1 is to be installed
Depends: libudev1 (>=183) but it is not installable
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #92 |
ok, I'll be honest. this is a giant mess where we potentially access dangling pointers and sorting this out is nasty. my attempts to do so today have failed badly. fix will come, but not too soon I'm afraid
Till Kamppeter (till-kamppeter) wrote : | #89 |
Krastanov, is your 13.04 completely up-to-date? I have created and tested the packages on an up-to-date 13.04 and there they work. Are you using the PPA (i386, amd64) or the binary package tarball (Nexus 7/armhf)?
Krastanov (krastanov-stefan) wrote : | #90 |
I use the PPA and I have updated and upgraded the system before adding the PPA (but maybe my mirror was not up-to-date). Given your confirmation that it works, I will search for the error on my side. Thank you!
Till Kamppeter (till-kamppeter) wrote : | #91 |
Created a Blueprint about convertibles and the Ubuntu desktop with touch screen:
https:/
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #93 |
Yes, I can see how time consuming this must be. Thanks for continuing to work on it, at OLPC we can promise you some testing once code is ready.
In the mean time I will add the latest 2 patches to our development builds for further testing:
Xi: Do not handle ET_TouchOwnership in ProcessTouchEvent
dix: copy event in TouchConvertToP
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #94 |
Please have a test of this branch here:
http://
I'm not 100% sure yet if there's a memleak introduced - haven't done the required checks yet. but it fixes the crasher caused by the invalid memory dereference.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #96 |
Peter, I have tested your new branch on the Lenovo Thinkpad Twist now. I do not get any crashes and left clicking by tapping is absolutely reliable for me. Right-clicking via onboard does not work for me though. If I activate the right-click mode and tap, the tap is interpreted as left click (right-click mode ignored). At least I do not get a stuck-left-button effect by the right click. I do not get any crash nore a stuck-button effect at all, independent what I am doing. What is missing now is a fix for the right click.
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #97 |
Thanks for continuing to work on this.
I believe the touch-grab-
Running xev, I can see that clicking and holding the mouse button doesn't actually trigger any events. Only when I release, ButtonPress and ButtonRelease appear in quick succession.
If nobody beats me to it, I'll bisect this later this week. Also, the above test was done on xserver-1.13.3, I should also test on a newer version to make sure there aren't any other factors at play.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #98 |
Daniel, Peter, I am using the the full GIT branch touch-grab-
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #99 |
Thanks for testing. Sugar's paint app is http://
It is probably more meaningful to do the xev test though. Click the mouse button and hold, you would expect a ButtonPress event to show immediately, but it doesn't. And do that under sugar, in case the global touch grabs are affecting things.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #100 |
Daniel, on my 1.14 I do not see any problem, also when testing with xev. Both with the external mouse and my finger on the touch screen I see ButtonPress events when I press and hold the mouse button or when I put my finger onto the screen and I get ButtonRelease events when I release the mouse button or take my finger from the screen. This works all correctly for me.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #101 |
Till, can you run this under valgrind please to make sure I didn't introduce any memory leaks?
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #102 |
Peter, how do I run the xorg server under Valgrind? I have a Ubuntu Raring system.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #103 |
Another touch problem: If I run Chromium browser and try to drag and drop one of the tabs using the touch screen, the left button gets stuck down and it does not get even unstuck if I continue working with the external Bluetooth mouse. I can only kill the session.
It also happens sometimes that X crashes but without any message in /var/log/syslog.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #104 |
Created attachment 78472
/etc/X11/X-valgrind
For valgrinding xserver you want to install the xserver-
I enabled auto valgrinding by creating /etc/X11/X-valgrind with the contents of this adjustment, make the file executable and then point the /etc/X11/X symlink to it. It will append the log to /var/log/
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #105 |
Also with 1.14 XBMC behaves as in comment #39, not reacting to touch clicks. Looking more deeply into XBMC's behavior, the mouse cursor is put into the lower right corner of the screen when touch-clicking an arbitrary place, perhaps all touch clicks are registered with the coordinates of the lower right corner.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #106 |
I have set up running X under Valgrind now. I have installed
xserver-
valgrind
xserver-
xserver-
xserver-
xserver-
libdrm2-dbg
libdrm-intel1-dbg
ThenI have installed Maarten's script, made it executable, and linked it. After that I have restarted X via
sudo restart lightdm
X is mnuch slower now, probably due to Valgrind's work.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #107 |
First observation under Valgrind:
onboard pops up when touch-clicking an input field, but onboard is non-functional. Independent whether I touch-click the keys or use my external mouse, the keys do not react. No changes of the key's color, no character appearing in the input field. Also right-clicking does not work as one cannot operate the right-click button.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #108 |
Created attachment 78475
Xorg-valgrind.
My Valgrind log as of now.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #109 |
Installed libunwind8-dbg to improve Valgrind log, then restarted lightdm, logged in, and now onboard works.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #110 |
Created attachment 78476
Xorg-valgrind.
Update of Valgrind log.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #111 |
I have more experience with the onboard-aided right click (same running under Val;grind or without Valgrind):
Touch-clicking the right-click key on onboard makes it turning grey. After that doing one touch click on the desktop background does nothing. A second touch click on the background makes the right-click menu open and onboard disappear.
Right-clicking in Chromium does not work. The second click only makes onboard disappear but does not pop up the right-click menu of Chromium.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #112 |
Same with the double-click emulation button of onboard: It also executes the double-click only on the second touch click (tested with Nautilus).
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #113 |
Created attachment 78483
Xorg-valgrind.
Finally I succeeded to make X crashing again, I opened several programs (Firefox, Chromium, Thunderbird, Calculator, digikam), did some clicks in them, and closed them again. Then I opened LibreOffice Writer via the Launcher and got a window asking to recover a previous document which was not correctly closed. I rejected and when I answered the question whether I really want to reject with "Yes", X crashed.
Valgrind log attached.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #114 |
Created attachment 78484
Xorg-valgrind.
With LibreOffice Writer I can reproduce the crash reliably. Right after login I touch-click its icon in the Launcher, get the dialog to recover the document of the previous session, I reject, and as soon as I click "Yes" to confirm, X crashes, and X crashes fast enough so that LibreOffice does not clean up the document which I have rejected. In the next session I will get asked again.
If you cannot reproduce the crash as you do not have a broken document, try starting a new document and then "kill -9" LibreOffice. On the next session it should ask you for recovering your document.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #115 |
Note: In the last two comments (and also in my other tests), I did all operations by touch clicking (if not otherwise stated).
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #116 |
Created attachment 78485
Xorg-valgrind.
X crashes as well if I do the described steps with LibreOffice using my external Bluetooth mouse for all clicks and not the touch screen.
Valgrind log attached.
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #117 |
(In reply to comment #47)
> I believe the touch-grab-
> a problem with mouse input. In Sugar's Paint application, I can't paint
> anything by moving the mouse around with the button held down.
>
> Running xev, I can see that clicking and holding the mouse button doesn't
> actually trigger any events. Only when I release, ButtonPress and
> ButtonRelease appear in quick succession.
I have reproduced this by checking out the git branch in question and building it directly, so it was not a side effect of my earlier attempt (above) where I had backported this to 1.13.3.
The problem can be reproduced very easily: xinit /usr/bin/xev (running over ssh from another machine, to be able to see stdout)
Move the mouse cursor to the top left (where the xev window is). Click and hold the mouse button, and keep holding. No output from xev. Now release the mouse button, ButtonPress and ButtonRelease arrive at the same time. No touch input is needed to see this problem.
A few churns of "git bisect" later I have tracked this down to:
3e1515898545b0e
commit 3e1515898545b0e
Author: Peter Hutterer <email address hidden>
Date: Thu Apr 18 10:32:11 2013 +1000
dix: drop DeviceIntRec's activeGrab struct
IDWMaster (webadm) wrote : | #95 |
Can confirm this bug on a Samsung Series 7 slate. No touch input is recognized for Plasma Active or Unity, however XInput is reporting touch events (acts just like a mouse, instead of a multitouch screen).
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #119 |
Created attachment 78643
Xorg-valgrind.
Another crash, this time I was visiting http://
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #120 |
Created attachment 78644
Xorg-valgrind.
Another crash: Still visiting http://
RobertZenz (robert-zenz) wrote : | #118 |
I can reproduce this (not reliable) on a Tega v2 (aka Viewpad 10, aka Nexoc Pad 10). Touchscreen is reported as "1d6b:0002 Hanvon 10.1 Touch screen overlay". xev reports a mousebutton release, but no press/keydown/
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #121 |
the libreoffice hint helped a lot tracking this down. New branch posted (top commit b8a2de82e36dd92
). Please give this a test. looks like my test box here is happy and valgrind doesn't see any leaks (yet)
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #122 |
Created attachment 78801
nexus valgrind log for latest attempt
Still a bit buggy. On the nexus7 I can cause it to drop events in the same way still..
What I do is touch the ubuntu dash icon in upper left, then release finger and make a dragging motion with the dash icon. I'm not 100% sure if the touch was fully released, or it just stopped registering my finger. But this (still) results in the following spam from xserver:
[Xi] Virtual core pointer: Failed to get event 8 for touchpoint 1
[Xi] Virtual core pointer: Failed to get event 8 for touchpoint 1
[Xi] Virtual core pointer: Failed to get event 8 for touchpoint 2
source device 7: history size 100 overflowing for touch 12
(history size overflowing repeated a lot, for touch 12 and 13)
Stopping lightdm doesn't crash any more and shows no leak. Only thing that may or may not be relevant is a still reachable warning:
==3663== 16,384 bytes in 4 blocks are still reachable in loss record 245 of 246
==3663== at 0x482D4B8: calloc (vg_replace_
==3663== by 0x216F23: WriteToClient (io.c:1017)
==3663== by 0x142667: WriteEventsToClient (events.c:5982)
==3663== by 0x142747: TryClientEvents (events.c:1968)
==3663== by 0x144905: DeliverEventToI
==3663== by 0x144A99: DeliverEventsTo
==3663== by 0x144D51: ProcSendEvent (events.c:5411)
==3663== by 0x13B9D5: Dispatch (dispatch.c:432)
==3663== by 0x130D2F: main (main.c:295)
Full log for the session is attached as vg.nexus
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #123 |
Peter, I have tried your new snapshot (comment #70) and so far I did not get crashes. Touch operation without right-clicking works well for me now. The right-click emulation via Onboard is still broken, though.
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #124 |
(In reply to comment #70)
> the libreoffice hint helped a lot tracking this down. New branch posted (top
> commit b8a2de82e36dd92
> ). Please give this a test. looks like my test box here is happy and
> valgrind doesn't see any leaks (yet)
I would like OLPC to help with this testing, but the xev problem in comment #67 is getting in our way. Have you had a chance to investigate this yet?
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #125 |
daniel - xev behaves normally for me in the last branch. is it still misbehaving for you?
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #126 |
Yep, reproduced with HEAD b8a2de82e3, bisection identifies the first bad commit as 3e15158985.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #127 |
tried to bisect this, but I can't see any difference in the xev output before or after that commit. Tested several revisions after (and 3e15158985) and xev works as expected.
fwiw, my test box here is Ubuntu 12.10 with the server branch above, rest as-is. mouse used is a trackpoint, which for all purposes looks like a mouse.
test case was xinit /usr/bin/xev -- /opt/xorg/bin/Xorg -retro, then clicking+dragging into the xev window. events as expected.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #128 |
> ==3663== 16,384 bytes in 4 blocks are still reachable in loss record 245 of
> 246
> ==3663== at 0x482D4B8: calloc (vg_replace_
> ==3663== by 0x216F23: WriteToClient (io.c:1017)
> ==3663== by 0x142667: WriteEventsToClient (events.c:5982)
> ==3663== by 0x142747: TryClientEvents (events.c:1968)
> ==3663== by 0x144905: DeliverEventToI
> ==3663== by 0x144A99: DeliverEventsTo
> ==3663== by 0x144D51: ProcSendEvent (events.c:5411)
> ==3663== by 0x13B9D5: Dispatch (dispatch.c:432)
> ==3663== by 0x130D2F: main (main.c:295)
This appears to be present in 1.14.0, not introduced by this series.
I raise a white flag on the other issue though, like the bug Daniel sees I cannot reproduce it here.
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #129 |
(In reply to comment #76)
> tried to bisect this, but I can't see any difference in the xev output
> before or after that commit. Tested several revisions after (and 3e15158985)
> and xev works as expected.
Thanks for testing - I have now looked closer.
The patch removes a field from struct _GrabInfoRec. That is an ABI change, what does it affect? It does seem to break stuff outside of the xserver according to my initial test.
If I readd the field, even though it is now unused, xev works again.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #130 |
oh, right. sorry, I forgot to mention this - it is indeed a ABI break so you have to recompile the drivers (or add the now-unused field back in). Maarten, this could also be the reason for your bug?
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #131 |
Pushed the branch with a fix to keep the ABI, please test de12ce91d8e44ab
In freedesktop.org Bugzilla #56578, Timo Aaltonen (tjaalton) wrote : | #132 |
I built it, and changing between dash and indicators soon hangs with this on the log:
[ 3110.957] (EE) BUG: triggered 'if (!pGrab)'
[ 3110.957] (EE) BUG: ../../dix/
[ 3110.957] (EE)
[ 3110.957] (EE) Backtrace:
[ 3110.957] (EE)
gdb doesn't give anything, just the usual WaitForSomething etc
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #133 |
(In reply to comment #80)
> Pushed the branch with a fix to keep the ABI, please test
> de12ce91d8e44ab
Built this and can't see any problems after a quick test. I'll ship this in upcoming OLPC development builds for wider testing.
In freedesktop.org Bugzilla #56578, pauls (paulatgm) wrote : | #134 |
I have a lenovo S10-3t with full keyboard, synaptics touchpad and cando 2 touch screen that I'd like to try this on. I have ubuntu 13.04 on it. What are the git commands to access de12ce91d8e44ab
In freedesktop.org Bugzilla #56578, pauls (paulatgm) wrote : | #135 |
Sorry, I found the files on the pages referenced above, so don't need any reply.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #136 |
Is make check failing for anyone else with v3?
(EE) test device: not enough space for touch events (max 5 touchpoints). Dropping this event.
(EE) test device: not enough space for touch events (max 5 touchpoints). Dropping this event.
(EE) test device: not enough space for touch events (max 5 touchpoints). Dropping this event.
/bin/bash: line 5: 26164 Segmentation fault MALLOC_PERTURB_=15 ${dir}$tst
FAIL: touch
Program received signal SIGSEGV, Segmentation fault.
TouchInitTouchPoint (t=t@entry=
243 ti->valuators = valuator_
In freedesktop.org Bugzilla #56578, pauls (paulatgm) wrote : | #137 |
I still need help compiling the test branch of xserver on ubuntu 13.04. If I try to compile it, detailed here http://
TIA
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #138 |
(In reply to comment #85)
> Is make check failing for anyone else with v3?
caused by a patch merged into master (and thus picked up on v3), fix is here:
http://
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #139 |
paul:
add-apt-repository ppa:canonical-
apt-get update
apt-get dist-upgrade
apt-get build-dep xorg-server
will get you 1.14 + necessary build dependencies. Copy the debian directory from xserver 1.14, and comment out each patch that fails to apply in debian/
In freedesktop.org Bugzilla #56578, John Faulkner (johnnyuk) wrote : | #140 |
(In reply to comment #88)
Hello.
I would like to provide testing for this bug if possible but I'm not exactly clued up on compiling xorg-server from scratch. I figure it could be useful to have a none-standard (ie not a laptop or tablet device) low-end hardware test case but if it's unlikely to be useful then please let me know.
One thing I've noticed is that once this bug has triggered (rendering most GTK applications and the unity dash unusable), Nautilus continues to function normally with the touch screen. Can anyone else confirm this on a standard Ubuntu 13.04 installation?
Anyway, I can see the branch you're talking about and can clone the git repository no problem.
> Copy the debian directory from xserver 1.14, and comment out each patch that fails to apply in debian/
I'm not certain which directory / patches you're referring to here, could you point me in the right direction?
I can duplicate this bug every time with a custom application which uses a GtkToolPalette. It appears to trigger every time I tap a category which produces a smooth roll-out animation - the hardware is pretty low end so I suppose this additional load triggers a race condition? I can trigger the bug in other normal uses but this one is guaranteed every time.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #141 |
grab http://
and xorg-server_
In freedesktop.org Bugzilla #56578, John Faulkner (johnnyuk) wrote : | #142 |
(In reply to comment #90)
Thank you, Maarten. I can patch and compile that copy but for some reason I'm getting a compilation error with the de12ce91d8e44ab
> REGION_
> REGION_
> REGION_
> REGION_
> window.c:421:5: error: the comparison will always evaluate as ‘true’ for the
> address of ‘box’ will never be NULL [-Werror=address]
Any ideas?
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #143 |
sorry guys, please take the compilation errors to the list. This bug is confusing enough with >90 comments and I'd like to keep off-topic stuff to a minimum.
pushed a new version of the branch after fixing a cursor refcounting issue that crashed my server when dragging and email in thunderbird. new branch tip is 9a5ad65330693b3
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #144 |
That fixed up the background corruptions and hangs on armhf/nexus 7, but I'm still seeing a stuck mouse button, and [ 77305.765] [Xi] Virtual core pointer: Failed to get event 8 for touchpoint 1.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #145 |
nm, bg is still corrupt when running in valgrind :(
Changed in hwe-next: | |
status: | New → In Progress |
assignee: | nobody → James M. Leddy (jm-leddy) |
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #146 |
fwiw, the latest branch got merged into master. It's still buggy but an improvement over the previous state.
commit c76a1b343d6a56a
Merge: 891123c 9a5ad65
Author: Keith Packard <email address hidden>
Date: Thu May 23 19:58:36 2013 -0600
Merge remote-tracking branch 'whot/touch-
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #147 |
Thanks for all your work on this. At OLPC we've been testing the branch but have been a couple of commits behind the tip. Anyway, I think its still worth contributing the test result: no problems seen.
In freedesktop.org Bugzilla #56578, Jrenyard (jrenyard) wrote : | #148 |
I would like to be any help I can with this bug fix. I am able to test on an 18.5" Winmate M185D as well as a 10" Winmate device (W10ID3S-PCH1). I am currently running Unity 13.04 and can make any necessary changes to the system. Please let me know what I can do to test and how to do it. I feel a bit over my head, but am willing to learn in order to be helpful.
In freedesktop.org Bugzilla #56578, Cody Swanson (codyswanson4) wrote : | #149 |
Wondering if anything has been happening in a while...
In freedesktop.org Bugzilla #56578, Dsd-o (dsd-o) wrote : | #150 |
Peter fixed a load of stuff and it got merged in xserver master. Unfortunately there have not been any development releases of xserver master since that happened, but that will come in time.
If you are still seeing problems, and are definitely using xserver master, then I suggest explaining your problem here (if you are sure that you are seeing the same issue), or opening a new bug report (if it seems like your issue might be unrelated).
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #151 |
The fix for bug #66720 looks relevant, commit 8eeaa74bc241acb
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #152 |
Nope, and I noticed a BUG on !pGrab in FreeGrab, I'll try it a bit more on monday.
In freedesktop.org Bugzilla #56578, Cody Swanson (codyswanson4) wrote : | #153 |
(In reply to comment #99)
> Peter fixed a load of stuff and it got merged in xserver master.
> Unfortunately there have not been any development releases of xserver master
> since that happened, but that will come in time.
>
> If you are still seeing problems, and are definitely using xserver master,
> then I suggest explaining your problem here (if you are sure that you are
> seeing the same issue), or opening a new bug report (if it seems like your
> issue might be unrelated).
Thanks for the sumary! I was just wondering. Thanks!
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #154 |
(In reply to comment #101)
> Nope, and I noticed a BUG on !pGrab in FreeGrab, I'll try it a bit more on
> monday.
merged as 0e3be0b25fcfeff
as for the rest, I really need something that's reproducible.
In freedesktop.org Bugzilla #56578, Maarten Lankhorst (mlankhorst) wrote : | #155 |
I think the changes to onboard to use xinput2 directly may have fixed the remaining issue I was having. When I checked out onboard from trunk and used it on my nexus7 things worked, and nothing got stuck.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #156 |
Maarten, I have checked with the new onboard ("bzr branch lp:onboard") now on an up-to-date Saucy with xserver packages from the x-staging PPA and I do not get a stuck-mouse-button effect any more.
In freedesktop.org Bugzilla #56578, Till Kamppeter (till-kamppeter) wrote : | #157 |
I did further testing over longer time and no stuck button. Its seems that with the current X from the x-staging PPA and the current Onboard from the onboard PPA the problem is solved.
In freedesktop.org Bugzilla #56578, Peter Hutterer (peter-hutterer) wrote : | #158 |
Thanks for testing. I'm going to close this one as fixed since we definitely fixed quite a few bugs in this patch set. If there's something left please file a new bug so we can narrow down the new (old? :) issues.
Changed in xorg-server: | |
status: | In Progress → Fix Released |
Maarten Lankhorst (mlankhorst) wrote : | #159 |
Upstream marked this as fixed. So this should be fixed in saucy now. Backporting this is non-trivial, and it might be easier to test if using a newer version of onboard fixes this problem. Newer versions of onboard workaround it by using xi2 events directly.
Changed in xorg-server (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in xorg-server (Ubuntu Precise): | |
assignee: | nobody → Maarten Lankhorst (mlankhorst) |
Chris Fester (camaronut) wrote : | #160 |
- first attempt at 12.04 LTS xserver fix for touchscreen bugs Edit (124.2 KiB, text/plain)
For folks using Ubuntu 12.04LTS, and can't use the quantal/
It's a first attempt at backporting Peter Hutterer's touch-grab-
In order to use the patch you have to comment out the following from the series file:
505_query_
506_touchscreen
507_touchscreen
Let me re-state, this patch is for xserver-
Please let me know what you think. Thanks!
Chris
francisct (franciscotetremblay) wrote : | #161 |
Can someone sum up what we have to do in 13.04 to get rid of the stuck click problem? I am new to ubuntu, I have installed ubuntu 13.04 on my nexus 7. When I dist-upgrade from ppa:canonical-
Chris Fester (camaronut) wrote : | #162 |
- Rev 2 of 12.04 xserver backport patch Edit (125.3 KiB, text/plain)
Hi all,
The patch I posted previously had a bug in xf86UnrealizeCu
Chris
Shawn Rutledge (shawn-t-rutledge) wrote : | #163 |
This is quite a severe bug. If you have a touchscreen connected, and you have touched it at some point:
1) start gitk or tkinfo or a recent Qt Creator (or probably many other Qt 5 programs)
2) scroll some long text with the mouse wheel
3) move the mouse
It selects text as if the left mouse button was being pressed. So in other words if you have a touchscreen your mouse wheel isn't very useful anymore in certain applications.
I think it should be fixed in 12.04 too, not just in newer releases.
Maarten Lankhorst (mlankhorst) wrote : | #164 |
It should be fixable on precise by installing xserver-
Changed in hwe-next: | |
assignee: | James M. Leddy (jm-leddy) → nobody |
Steve Langasek (vorlon) wrote : | #165 |
The Precise Pangolin has reached end of life, so this bug will not be fixed for that release
Changed in xorg-server (Ubuntu Precise): | |
status: | New → Won't Fix |
I had hoped that backing http:// cgit.freedeskto p.org/xorg/ xserver/ commit/ ?id=634b0da9a83 076d0e9e0fc44dc 5dc77b0c368bc1 out of the xorg server core code base might be enough to solve this, but if I do so, core events never have any buttons set in their state, so that is not a solution. Nevertheless, it might well be that this problem lies somewhere inside the xorg server itself, and not the evdev driver module. Although I haven't yet pinpointed the location in the sources where that state is managed, it seems to me as if the evdev code were pretty stateless, submitting only button press and release events as appropriate. And as those apparently arrive correctly at xev, the state management appears to be wrong for some other reason.
Searching for ways to obtain more information, I just ran "xinput test-xi2 2" where 2 is the id of my virtual core pointer. When I drag my finger inside the test window, here is what I see in the console (after enlarging my scrollback appropriately):
- DeviceChanged due to SlaveSwitch
- RawTouchBegin
- Enter, buttons: (empty)
- Motion (emulated), buttons: 1
- ButtonPress (emulated), buttons: 1
- Motion (emulated), buttons: 1, repeated while dragging
- ButtonRelease (emulated), buttons: 1
- TouchBegin, buttons: (empty)
- TouchUpdate: buttons: (empty), repeated to mimic the original drag
There are a number of things very strange about this: TouchUpdate sequence only gets emitted after I release my finger.
- The whole TouchBegin/
- The TouchBegin does not have a matching TouchEnd. Very likely this causes the error in core event state.
- After I release my finger, the mouse cursor jumps to the location where I began my drag.
This behaviour is only within the xinput test window, outside the cursor will stay at the end of a drag.
Repeating the test for input device 9, which is the touch screen, I see this:
- RawTouchBegin
- Motion (emulated), button: 1
- TouchBegin, buttons: (empty)
- ButtonPress (emulated), buttons: 1
- RawTouchUpdate
- TouchUpdate, buttons: (empty)
- Motion (emulated), buttons: 1
- The preceeding three events repeated in this order for the duration of the drag
- RawTouchEnd
- TouchEnd, buttons: (empty)
- ButtonRelease (emulated), buttons: 1
So here the Touch events are delivered in sync with the Motion events, there is a TouchEnd where one would expect it to be. The jumping of the mouse cursor to the position where the drag began still remains, though.
To me this looks a lot as if the events made it into the dix layer all right, but the emulation of a core pointer based on these events is somehow broken. For this reason, I now believe the problem to lie within the xserver-xorg-core binary package.
"xinput test 2" does not work at all ("unable to find device 2"), whereas "xinput test 9" shows pretty sane behaviour: a single motion followed by a button press 1 at the beginning, a sequence of motion events during the drag, and a button release 1 at the end. When launched with the -proximity flag, it complains of a bad request and terminates immediately. Makes sense, as this device doesn't provide any proximity information.