Comment 2 for bug 1015183

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.