xdotool not working when invoked as a keyboard shortcut

[todor2810]

Under 'System Settings' > 'Keyboard' > 'Shortcuts' I have bound the command: xdotool key --clearmodifiers End to: Ctrl+E

But when I press the combination e.g. when I'm inside a text editor, nothing happens.

OS: Linux Mint 18 xdotool: v3.20150503.1

[devYonz]

+1 for redhat 7

[lj94093]

+1 for manjaro deepin

[jordansissel]

That is really strange. Do you know much about the program that manages the shortcuts?

Hypothesis: It's possible xdotool runs faster than the shortcut program releases the keyboard? I can try to explain.

From the X11 docs:

The active grab is terminated automatically when the logical state of the keyboard has the specified key released (independent of the logical state of the modifier keys). Doing global shortcuts/hotkeys in X11 is done with a function called XGrabKey.

Examples which are working around this:

• keynav (a hotkey tool), uses a sleepy loop to XGrabKeyboard to work around an issue where a separate hotkey program hasn't released the keyboard (some part of the hotkey combo is still pressed?).

So what may be happening is this:

1) CtrL+E is pressed 2) your shortcut program is given the keyboard grab 3) xdotool key --clearmodifiers End is executed 4) You release Ctrl+E 5) your shortcut program releases the keyboard grab

The timeing on each of the above events is likely only milliseconds apart, but if my hypothesis is correct, it explains why your End sending attempt is never received (because the only program receiving keyboard events at the time of the End is your shortcut program, due to a way X11 is working here)

---

So, my recommendation, try adding a short sleep. xdotool supports both a sleep command as well as a feature called command chaining, so you should be able to change your command to this:

xdotool sleep 0.100 key --clearmodifiers End

This will cause xdotool to sleep for 100ms before sending the keystroke, and with the right timing (releasing Ctrl+E within 100ms of pressing it), this might work for you.

Let me know?

[otizonaizit]

Thanks @jordansissel !!! That fixed it for me. I had the problem while trying to use xdotool in fvwm. Not sure I understand your explanation, though. In my case, I have the following in the fvwm configuration:

Key Left  A M Exec xdotool sleep 0.100 key Prior
Key Right A M Exec xdotool sleep 0.100 key Next

which is meant to remap alt+left/right to alt+prior/next (it is a workaround for a broken keyboard). Following your logic, what is happening is that fvwm grabs the keyboard, and if I don't set the xdotool sleep, it executes xdotool and releases the keyboard grab when xdotool has already done is job and so there is no one to receive the fake keystrokes. It is still a bit slugghish though, and it does not support keeping the key pressed (the key press is not repeated).

But why is such a long sleep needed? What could fvwm possibly be doing during that time? Or is xdotool not meant to be used in this context?

[ainar-g]

@jordansissel I seem to have had a similar problem, only my shortcut was Alt+c and I needed to execute Ctrl+v. What I did was:

xdotool keyup Alt+c
xdotool key Ctrl+v

Seems to work well.

[otizonaizit]

@ainar-g thank you! That fixed me for me too. The previous fix I was using (inserting a short sleep) was working but not reliably. Your fix is working much better, and without the delay I was experiencing with the sleep. Thanks!

[DiagonalArg]

@ainar-g - Are you saying you bound Alt+c to xdotool keyup Alt+c && xdotool key Ctl+v?

If that's it, then does it leave things in a weird state when you finally release the Alt+c? Would you want a xdotool keydown Alt+c in addition?

[ainar-g]

@DiagonalArg Haven't noticed any weirdness, to be honest. Maybe because I unpress Alt+c very quickly.

[thebritons]

@ainar-g - Are you saying you bound Alt+c to xdotool keyup Alt+c && xdotool key Ctl+v?

That solution worked for me as well for my purposes (lack of function keys) xdotool keyup Ctrl+Up && xdotool key F9

[schieni]

@jordansissel

xdotool sleep 0.100 key --clearmodifiers End

...and it works for me too! After hours of fighting (unfocused windows works, but focused does not), I find your solution (sleep). Thank you so much!

[mateja176]

For CentOS 8, neither approach works, be it relying on sleep 0.100 or keyup.

[arminstraub]

Just in case this might be useful to anyone who wants to configure shortcuts: xdotool keyup Alt+c && xdotool key Ctl+v did work for me in a similar situation (KDE global shortcuts on Ubuntu 18.04) but in the end I found that xvkbd -xsendevent -text "\\Cv" worked just as well (without the need for a hard-coded keyup).

[codeswhite]

I managed to find a good solution for my problem: Brightness keys [Fn+F11] -> XF86MonBrightnessDown not getting recieved (tried all solutions including kernel parameters and udev magic but no luck getting them keys to work btw on windows they do work)

So I mapped (in XFCE keyboard shortcuts settings): [Shift+F11] -> xdotool keyup Shift+F11 key --clearmodifiers XF86MonBrightnessDown As advised here and it worked, kinda, Ive noticed that im unable to repeatedly press [Shift+F11]+[F11]+[F11]+... mutiple times without releasing the Shift key, seems that the Shift key was being released by keyup and wasnt getting pressed down until i physically done that. So the solution for that is releasing only the F11 key and keeping the modifier down: [Shift+F11] xdotool keyup F11 key --clearmodifiers XF86MonBrightnessDown Hope it help someone who has encountered a similar issue :)

[ScarletMcLearn]

xdotool sleep 0.100 keydown Alt sleep 0.100 click 4 sleep 0.100 keyup Alt

Not working on Linux Mint XFCE.

[phil294]

can we reopen this? It is not fixed yet (perhaps it isn't even fixable). The proper workaround, as mentioned above, is to do a keyup the-shortcut-key before the actual typing.

Problem also discussed recently here.

[cassava]

For i3wm, using bindsym --release was the key to fixing my particular similar issue.

[jasonstone20]

xdotool sleep 0.100 keydown Alt sleep 0.100 keydown 2 sleep 0.100 keyup Alt sleep 0.100 keyup 2 works for me, using Linux MINT

[phil294]

I have found that this is solvable from an application author's point of view (xdotool source or any other tool using libxdo.so) by doing a Grab and Ungrab first. So in my app, instead of

libxdo.keys_up(the-grabbed-hotkey-that-triggered-this, delay: 0)
libxdo.type("hello")

I now always do

X11.display.grab_keyboard(root_win, owner_events: true, pointer_mode: X11::GrabModeAsync, keyboard_mode: X11::GrabModeAsync, time: X11::CurrentTime)
X11.display.ungrab_keyboard(time: X11::CurrentTime)
libxdo.type("hello")

In other languages accordingly. So no more key UP like written by folks above, but a grab/ungrab (regardless of their return codes). Now I can also emulate proper key remapping logic with X11 tooling.

I'll try this out an extended time now, but it seems like this is reliable and might be worth considering to add to libxdo directly?