Bug 26922 - Xi2: raw events on master devices don't work if a grab is active
Summary: Xi2: raw events on master devices don't work if a grab is active
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/Core (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 26921 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-05 21:42 UTC by Vitaliy Margolen
Modified: 2018-06-12 18:44 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Sample test prorgam (3.62 KB, text/plain)
2010-03-18 06:32 UTC, Vitaliy Margolen
no flags Details

Description Vitaliy Margolen 2010-03-05 21:42:30 UTC
Xi2 stops generating all XI_RawMotion events when any of mouse buttons was pushed over any of window and held down and mouse is moved. Everything works as expected if button was pressed down over empty area without any windows.

I'm using raw X session (no window manager) starting just xterm.
Can be reproduced with Xorg's xinput programs with "test-xi2" command.
Comment 1 Peter Hutterer 2010-03-17 23:26:06 UTC
Thanks for reporting this. this isn't really a bug though I've heard that it might be a broken feature (ahh, the wording, beautiful, isn't it?).

X has a principle of an implicit passive grab where the pointer device is grabbed when a button press event was delivered to a client (until the release event). In xinput's case, test-xi2 only registers on master devices for raw events. Once the grab is on the pointer, these events only go to the grabbing client.

If you change the code to register for raw events on XIAllDevices instead, you'll see the events from the physical devices. Likewise, with a second pointer you'll see the events for the second pointer even when the first pointer has a button down.

So, not a bug though I'm quite willing to admit that delivering raw events only if there's no grab on the device may prove to be a bad choice in the future.
Comment 2 Peter Hutterer 2010-03-17 23:26:58 UTC
*** Bug 26921 has been marked as a duplicate of this bug. ***
Comment 3 Vitaliy Margolen 2010-03-18 06:30:54 UTC
Unfortunately I'm already using XIAllDevices with the same exact results.
Comment 4 Vitaliy Margolen 2010-03-18 06:32:11 UTC
Created attachment 34197 [details]
Sample test prorgam

Sample test program that demonstrates the issue.
Comment 5 Peter Hutterer 2010-03-25 22:07:23 UTC
(In reply to comment #4)
> Created an attachment (id=34197) [details]
> Sample test prorgam
> 
> Sample test program that demonstrates the issue.

ok, I tried it and changed the device id to my mouse. that worked. then changed it to XIAllDevices and that gave me three events - press from the MD pointer and press + release from the slave. That's what I expect since my WM puts a button 1 grab on the MD pointer.

if you comment out line 63 (eventmask.deviceid = 7;), you should get the same events.

Comment 6 Vitaliy Margolen 2010-04-01 07:04:32 UTC
I see. This all seems to be broken. If the master device supposed to be an aggregate of slaves but it's not...

At least should spell this out somewhere in documentation.
Comment 7 Peter Hutterer 2010-04-05 15:53:05 UTC
reopening to keep track of it. This should probably be fixed in the protocol eventually.

Summary: raw events in XI 2.0 are only sent if no grab is active. If a grab activates, raw events are only sent to the grabbing client.
The implicit passive grab activated on a ButtonPress delivery causes asymmetric event delivery. RawEvents are processed first, hence the raw button press is sent, then the grab activates at the core event delivery and the raw button release is discarded - the grab deactivates only after the core event is delivered.

This needs to be fixed either by rearranging the raw event order for button releases or by handling the whole thing in a better manner inside the server.
Comment 8 Adam Jackson 2018-06-12 18:44:00 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.