2

Ubuntu 17.04 XFCE4

When I log in to the computer, Control+R works in all programs. However, after some time (usually after some inactivity, even though the computer never sleeps, the monitors just power off) it stops working in all programs (ex. neither Chrome nor PHPStorm will respond to it but the respective actions it would normally trigger in those programs works when activated froma menu). All other shortcuts work fine, it seems to be only Control+R that's affected.

In the system "Keyboard" settings there are no application shortcuts bound to this combination.

I have run xev and verified that the output is the same when the combo is working and when it isn't.

All I have to do to correct the problem is log out and back in - a system restart is not necessary.

Since the system is recognizing the keystroke but no apps are responding to it, I'm assuming some running process is hijacking this combination, but I don't know how to find out which application that is.

Improve this question
1
  • 1
    See if the issue is solvable using my solution. It shows how to find which program is grabbing the keyboard shortcut. Maybe you are also running an Electron-based app that has the bug that affected me? Examples: Caprine, Spotify, Atom, VS Code askubuntu.com/questions/925732/…
    – oligofren
    Jun 17, 2017 at 10:11

1 Answer 1

Reset to default
2

An answer from Unix.SE by don_crissti. To send the Ctrl+r combination use "ctrl+r", e.g. xdotool key "ctrl+r".

To find out which app/program grabbed your key use the debug keysym XF86LogGrabInfo. Use xdotool to press keys + XF86LogGrabInfo at the same time e.g. in a terminal run

KEY=XF86AudioPlay
xdotool keydown ${KEY}; xdotool key XF86LogGrabInfo; xdotool keyup ${KEY}

Then check for output with tail /var/log/Xorg.0.log
Note that with gnome 3/gdm and systemd this is no longer logged to Xorg.0.log (it's instead logged to the journal). In that case you could run

journalctl -f

and then in another terminal run the xdotool commands. Switch to the first terminal and you'll see something like

/usr/lib/gdm/gdm-x-session[629]: Active grab 0x40c0a58e (xi2) on device 'Virtual core keyboard' (3):
/usr/lib/gdm/gdm-x-session[629]: client pid 708 /usr/bin/gnome-shell
/usr/lib/gdm/gdm-x-session[629]: at 32595124 (from passive grab) (device frozen, state 6)
/usr/lib/gdm/gdm-x-session[629]: xi2 event mask for device 3: 0xc000
/usr/lib/gdm/gdm-x-session[629]: passive grab type 2, detail 0xac, activating key 172

In the above example the program (the client) that grabbed the key is gnome-shell.

Improve this answer
2
  • Hi, this seems quite applicable, but I can't for the life of my understand how to setup Ctrl-Alt-F9 to trigger the XF86LogGrabInfo keysym. Do you have any pointers to progress from here?
    – oligofren
    Jun 15, 2017 at 14:56
  • 1
    @oligofren nvm, I totally misinterpret your comment. You want first to disable "switch to vty" behavior", then globally bind xdotool key XF86LogGrabInfo to Ctrl+Alt+F9 through a way specific to your compositor. Note that the accepted answer disables all Ctrl+Alt+Fδ hotkeys, so if you'd want to switch to vty, you'll probably need to use the Magic SysRq combination "keyboard raw mode".
    – Hi-Angel
    Jun 16, 2017 at 4:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.