On 12 November 2016 at 17:14, Carlos Garnacho carlosg@gnome.org wrote:
Second, in the unlikely case that Wine managed to detect a master pointer other than the VCP (this requires user intervention, creating a second pointer/keyboard pair and assigning HW devices to it) This second pointer would be unaffected by the core X calls performed by Wine (eg. grabs,cursor). This could eg. result in Wine grabbing/confining one pointer, while listening to raw events from another, which is otherwise unaffected by the grab.
I'm not sure that's necessarily wrong, but using XIGrabDevice(), XIWarpPointer(), etc. would probably be enough to fix that.
The Virtual Core Pointer is a given, it always has ID=2, it's created by default, it can't be removed, it's the one getting HW devices attached to by default, and it will be the device implicitly used by the other X core calls. It's the device Wine wants to listen to despite its initial state.
That probably works in practice, but I can't think of anything in the protocol spec that guarantees the VCP has id 2. Did I miss something there? How about XIGetClientPointer(), would that do the right thing?
The main purpose of this patch is fixing master device detection over Xwayland, which is affected by the relative axes check. Xwayland will most usually emit pointer events as coming from a device with absolute axes, only switching to emitting relative motion when a very specific set of conditions are met (thought out for gaming basically). But most usually these conditions don't apply yet when XI2 is enabled, so the VCP is skipped and it ends up with xi2_core_pointer=0, thus ignoring the relative motion that is later sent.
But again, this is not Xwayland specific, it could happen as well with the right conditions on traditional X servers.
Wouldn't the correct way to handle this kind of thing be to respond to XI_DeviceChanged and XI_HierarchyChanged events?