© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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.