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, ProcessTouchOwnershipEvent will first run TouchRejected. This in turn will call EmitTouchEnd, but will not update state. Then TouchPuntToNextOwner will replay the history. The ButtonPress core event corresponding to the initial TouchBegin is now delivered with the CURRENT device state, i.e. 0x100.
For source code of TouchRejected, see http://cgit.freedesktop.org/xorg/xserver/tree/Xi/exevents.c?id=a986f2f30cbe2a00e72ded7315c4951d7703e549#n1210 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. -- 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
