I had hoped that backing
http://cgit.freedesktop.org/xorg/xserver/commit/?id=634b0da9a83076d0e9e0fc44dc5dc77b0c368bc1
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:
- The whole TouchBegin/TouchUpdate sequence only gets emitted after I release
my finger.
- 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.
** Also affects: xorg-server (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1015183
Title:
Inconsistent mouse events for Acer T231H multitouch monitor
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1015183/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
