23

I have an application that seems to have grabbed the mouse (I can move it but can't click anywhere), is there a way to find which app owns the X.org mouse grab?

The shortcut given here to release the mouse didn't seem to work, so I'm interested in something that could give me more information.

Community
  • 1
Tobu
  • 6,593
  • Are you sure that is what the issue is? It would be somewhat bizarre for an application you are not using to do this (if it did, I would stop using that app), so chances are -- if this is really the cause -- it is whatever you were just using. – goldilocks Dec 21 '12 at 18:48
  • I've found which by trial and error, killing a few things until something (a wine app) released the grab. – Tobu Dec 21 '12 at 21:05
  • 1
    Related: http://unix.stackexchange.com/questions/23164/manipulating-x-key-and-pointer-grabs-on-the-command-line, http://unix.stackexchange.com/questions/40458/command-for-forcing-a-pointer-ungrab-captured-mouse-release – Mechanical snail Jan 23 '13 at 09:39

3 Answers3

23

You can do this by pressing the XF86LogGrabInfo key, introduced in this commit.

By default, this keysym is not bound to any physical key or key combination. But you can still activate it using xdotool:

xdotool key "XF86LogGrabInfo"

After executing that command, a list of active grabs will be logged to the X log. On Ubuntu at least, this is /var/log/Xorg.0.log. It will be somewhere near the end of the log file, but there may be several irrelevant log messages below it. If there are no grabs, it writes:

[1199271.146] (II) Printing all currently active device grabs:
[1199271.146] (II) End list of active device grabs

If there are grabs (here, I opened a menu in Firefox), it logs something like:

[1199428.782] (II) Printing all currently active device grabs:
[1199428.782] Active grab 0x4c00000 (core) on device 'Virtual core pointer' (2):
[1199428.782]       client pid 15620 /usr/lib/firefox/firefox 
[1199428.782]       at 1199423728 (from active grab) (device thawed, state 1)
[1199428.782]         core event mask 0x7c
[1199428.782]       owner-events true, kb 1 ptr 1, confine 0, cursor 0x0
[1199428.782] (II) End list of active device grabs
Mechanical snail
  • 2,791
  • 2
    This log may also alternatively be at ~/.local/share/xorg/Xorg.0.log – matanox Jun 14 '20 at 08:28
  • I think I would warmly suggest not trying something like watch -n 0 xdotool key "XF86LogGrabInfo" for forcing the logging of grabs on a tight loop; it ended up somehow rigging my key mapping to the extent that resetting the keyboard layout from a console login was necessary to regain the ability to enter my password on the login screen :-)) the key mapping was rigged even in console mode requiring a hefty amount of intuition to figure how to get keys to actually produce latin text for the recovery commands :-\ – matanox Jun 14 '20 at 09:22
3

I've just had a similar issue, and narrowed it down to a a bug that somehow makes X11 think the middle button is pressed and not released. Physically disconnecting the mouse doesn't help, until there is a mouseup event.

The issue can be reproduced using xdotool mousedown 2 - it is impossible to switch focus between windows,

xdotool key XF86LogGrabInfo shows current focused process window, but when one kills it, another window receives focus and same scenario continues.

Workaround: issue xdotool mouseup 2.

Update: middle button being pressed and not released is simply the least noticeable one, because most apps don't respond to it, and some mice don't have this button to try and click to see if issue goes away.

ArticIceJuice
  • 31
1

The entries in the Xorg log can be pretty undecipherable. I wrote a program which parses them and presents them in a human-tractable form:

https://gist.github.com/CyberShadow/6412d11aea64144f8905cc0b8196f38e

To use, first run xdotool key XF86LogGrabInfo, as described in Mechanical snail's answer. Then, run the program linked above. If you Xorg log file is not located at /var/log/Xorg.0.log, you can specify its location using the --xorg-log option. See --help for details.

Vladimir Panteleev
  • 1,696