Comment 21 for bug 1307701

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

Excerpt from #xorg-devel:

"""
<dandrader> daniels, I've the following situation: clientX has a XISelectEvents(TouchBegin|Update|End, childWindowA, slaveDevice1); clientY has a XIPassiveGrabDevice(TouchBegin|Update|End|Ownership, rootWindow, AllMasterDevices)
 daniels, when a touch reaches xserver, it sends touch events to both clientX and clientY
<daniels> dandrader: yes, events are delivered separately thorough master and slaves - i'd recommend not using slaves for anything at all
<dandrader> daniels, but I believe it should send only to clientY, and only once clientY rejects the touch sequence should clientX finally start receiving the touch events (replayed), right?
<daniels> dandrader: if both clients were listening on a master device, then you'd be right
<dandrader> daniels, hmm got it. so what I'm seeing is the expected behavior then and I should modify clientX to select events on AllMasterDevices instead of on slaveDevice1
 daniels, is that it?
<daniels> dandrader: exactly
"""

So we have two problems here:
  1- touch ownership mechanics won't work in our situation as Qt is talking directly to the slave devices whereas unity7 is talking to the master devices.
   2- the xserver bug described in my previous comments where it gets confused with such situation and ends up with a borked internal state which ruins mouse pointer emulation

So if we could avoid the situation in item 1 (by changing either Qt or unity7/"Open Input Fw Grail" code) we might (have to try it out to see) circumvent the bug in item 2.