2

Looks like a bug

OK, I believe this is a bug in the xorg evdev driver, but as ubuntu-bug for precise so kindly asked me to work this trough the support channels, I first went ant reported this here. In the meantime, I've upgraded to quantal and reported a proper bug, but if someone from the support community should have an answer, that wouldn't go amiss either. (Paragraph has been edited to refer to the reported bug)

Setup

This is Ubuntu 12.04 precise connected to an Acer T231H multitouch monitor. Actually I encountered this on more than one OS setup, one of them done through debootstrap. Packages involved:

  • xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
  • linux-image-*-generic 3.2.0-24.39 on one and 3.2.0-25 on the other system

Symptom

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.

Comparison of expected and actual behaviour

Expected behaviour:

  1. MotionNotify with state 0x000 when dragging the ordinary mouse
  2. MotionNotify with state 0x000 for move prior to touch, or no event at all
  3. ButtonPress with state 0x000 when touching the screen
  4. MotionNotify with state 0x100 while dragging the finger
  5. ButtonRelease with state 0x100 when lifting the finger
  6. MotionNotify with state 0x000 when dragging the ordinary mouse afterwards

Actual behaviour:

  1. MotionNotify with state 0x000 when dragging the ordinary mouse before the first touch
  2. MotionNotify with state 0x100 for prior to ButtonPress event
  3. ButtonPress with state 0x100 when touching the screen
  4. MotionNotify with state 0x100 while dragging the finger
  5. ButtonRelease with state 0x100 when lifting the finger
  6. MotionNotify with state 0x100 when dragging the ordinary mouse afterwards
MvG
  • 1,536

1 Answers1

2

Solved this myself

Analysis of the main bug

I've dug through the sources of both evdev and the core x server. Turns out that this bug is not in evdev after all, but in xserver-xorg-core. A commit there (which is also included in the Xorg upstream) removed the only piece of code which ever set the TOUCH_END flag for an event. Without this flag, UpdateDeviceState will not remove the button from the state, thus leading to the "Button is always pressed" behaviour from my original question. Simply reverting that commit restored main core events functionality, i.e. the button was marked released right after the ButtonRelease event.

Minor bug on mouse press event

One issue remains in the xev output, though: The ButtonPress event already has state 0x100, but the state should reflect the state of the mouse buttons before the event occurred. This appears to be due to the way changes to the ownership of a touch sequence are handled. At one point in that ownership management code, the touch history is replayed using TouchEventHistoryReplay, but the internal state of the device isn't set to what it was prior to that replay. I haven't formulated a patch for this yet. When I do, I'll attach it to the bug report. I consider this question here answered even without a patch for that minor point, as it is a separate issue.

How to debug this

In case someone reads this with a similar problem: I had considered using gdb, but I was far from certain whether I'd be able to properly switch vt if the X server was stopped in the debugger, and I didn't have a working ssh server configured on that machine. So I used one of the oldest debugging aids ever and liberally scattered ErrorF calls all over the code, Xi/exevents.c in particular. I then recompiled the code (which I had initially compiled using debuild) without installing it, and ran the compiled binary (build-main/hw/xfree86/Xorg) as root like this:

$ make -C build-main
$ sudo -s
# apt-get install openbox
# ( sleep 3; DISPLAY=:1 exec openbox; ) & build-main/hw/xfree86/Xorg :1

This recompiles the code (takes ages even for a minor modification, so it seems that dependency management in the makefiles is suboptimal, but I didn't feel like digging into that as well). Then after becoming root, it starts the new X server, and starts openbox on that server a few moments later. Note that you'll be running openbox as root, so this is strictly for testing only.

MvG
  • 1,536