Created attachment 36593 [details] Sample application that causes the bug. This bug has been talked about a lot in some circles. I'm opening a new bug to keep it clean and technical. The attached code which basically just calls XTestFakeButtonEvent reproduces this problem which has been observed both by Gnome and KDE users (the latter only when they're using KHotkeys). The bug causes the mouse to get grabbed by some semi-random application - as a result the user won't be able to use the mouse anymore unless he restarts X. Activating the uncommented line in the code makes the problem disappear, but this is not a solution for us as we want to allow dragging and dropping with that mouse button. I'm pretty sure this used to work differently as the bug only appeared recently (in the last year or so) but the code in KHotkeys hasn't really changed in a long time.
This client presses button 3 down and never releases. Per X protocol specification, if this event is delivered to a client, this client has an implicit grab until the button is released again. If you don't release the button, the pointer will remain grabbed until the session terminates. I don't think this example really reflects what you want to do, is it?
Thank you for your answer and your time, I know how little there is of it. Do I understand you correctly that it is by design that a release of the real mouse button cannot end the grab that was initiated by a simulated mouse button press? Because this is the issue as far as I understand it. Maybe I should add that in KHotkeys' case, the real mouse button is still pressed when this code executes (we simulate the event we hid from the application due to our grab).
(In reply to comment #2) > Do I understand you correctly that it is by design that a release of the real > mouse button cannot end the grab that was initiated by a simulated mouse button > press? correct, the button on the core pointer device is held down until the last mouse has released the button. Whether the device is simulated or not doesn't matter here to the server - it doesn't know (well... sort-of, you know ;) likewise the other way, if you release the button on the virtual device and the mouse button is still down, the button will be released when you send the phys. mouse button release. Does that make sense?
It does, thank you very much! I'm back to wondering why this code worked in the past - but that's pretty obviously in my domain now. Closing this bug, thank you again for your time.
(In reply to comment #4) > It does, thank you very much! > I'm back to wondering why this code worked in the past - but that's pretty > obviously in my domain now. if you can verify that the same code works with an X server pre 1.7, then we've changed the behaviour and that should probably be fixed then. thinking about it, I wouldn't be surprised if we did.
Does XFree86 4.3.0.1 count? ;) (An ancient Knoppix was the only thing I had lying around just now) Anyway, on that version my test program behaves as I originally would have expected: Releasing the physical mouse button releases the grab. So we do have a behavioural change compared to current versions. Yay, I'm not crazy. I'll reopen the bug.
commit 14327858391ebe929b806efb53ad79e789361883 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Jul 1 12:44:57 2010 +1000 xkb: release XTEST pointer buttons on physical releases. (#28808)
It seems this bug has recently been reintroduced, at least in ArchLinux. For me, it appears again with this Arch package upgrade (which apparently incorporates changes directly from git): https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=fb63d6b030137baf0f1bbfce4bf63a65928687b7 As the actual package version hasn't changed, the culprit should be somewhere in the diff that is shown on that page. The behaviour is exactly the same as it used to be when I originally opened this report: The XTestFakeButtonEvent cannot be released by the physical mouse button.
I have been able to trace the regression to the change of a single line: diff --git a/xkb/xkbAccessX.c b/xkb/xkbAccessX.c index 082c0db..c1af32e 100644 --- a/xkb/xkbAccessX.c +++ b/xkb/xkbAccessX.c @@ -709,7 +709,7 @@ ProcessPointerEvent(InternalEvent *ev, DeviceIntPtr mouse) xkbDeviceInfoPtr xkbPrivPtr = XKBDEVICEINFO(mouse); DeviceEvent *event = &ev->device_event; - dev = IsFloating(mouse) ? mouse : GetMaster(mouse, MASTER_KEYBOARD); + dev = (IsMaster(mouse) || IsFloating(mouse)) ? mouse : GetMaster(mouse, MASTER_KEYBOARD); if (dev && dev->key) { xkbi = dev->key->xkbInfo; Reverting this change brings back the correct behaviour. Please try to fix this problem before the release happens!
Created attachment 70982 [details] [review] 0001-xkb-always-post-XTest-button-up-when-the-physical-bu.patch
(In reply to comment #10) > Created attachment 70982 [details] [review] [review] > 0001-xkb-always-post-XTest-button-up-when-the-physical-bu.patch Thank you, Peter! I can confirm that your patch fixes the problem on my system :)
commit c4fee9d2ecd6fdd4c05b04c9f02b23f10f2938b8 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Tue Dec 4 15:03:37 2012 +1000 xkb: always post XTest button up when the physical button released (#28808)
It seems the fix for this has only reached master, but not server-1.13-branch. A backport would be really appreciated - I know how to help myself, but other affected users will have to restart X or even reboot at seemingly random times due to this bug.
on 1.13 branch as b3b7be7d49ee9a253062661d6c72fa1f8ddff493, will be in 1.13.3.
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.