Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modifiers can become stuck after using --clearmodifiers #43

Open
spoage opened this issue Jun 5, 2014 · 14 comments
Open

Modifiers can become stuck after using --clearmodifiers #43

spoage opened this issue Jun 5, 2014 · 14 comments

Comments

@spoage
Copy link

@spoage spoage commented Jun 5, 2014

Taken from a bug report on Google Code:

What steps will reproduce the problem?
Having this in .xbindkeysrc:

"sleep 0.1 && xdotool type --clearmodifiers --args 1 123123 && xdotool key --clearmodifiers Tab && xdotool type --clearmodifiers --args 1 123123"
m:0x40 + c:10
Mod4 + 1

(That's for filling 2 textboxes in a browser)

push win(mod4)+1

sometimes the mod4 key is "stuck"
that means pressing e.g. TAB acts like win+TAB

What version of the product are you using? On what operating system?
20110530.1-6
xubuntu 13.04

My addendum:

"xdotool sleep 0.2 type --clearmodifiers test123"
m:0x14 + c:49
Control+Mod2 + grave

I'm experiencing this issue too. I think the problem is that I hit the macro by first pressing control then a moment later pressing grave, and to release the key combination I let go of everything at once. So, the macro thinks it needs to put the modifier back into the "down" state, even though it has already been released.

To put it more succinctly, I suspect that the problem is that clearmodifiers doesn't keep track of changes to key state since the modifiers were saved.

@daducci

This comment has been minimized.

Copy link

@daducci daducci commented Jan 26, 2017

@jonhrafe and I are having the same issue when triggering xdotool with a **keyboard shortcut&& inside the Atom editor; see [daducci/atom-ipython-exec#2]. Is there any workaround to this behaviour?

@bbugyi200

This comment has been minimized.

Copy link

@bbugyi200 bbugyi200 commented Sep 22, 2018

I'm experiencing the same issue. You can work around this by using xdotool's keyup option after a
short delay. The problem with this, however, is that if you are using a key mapping that is
sometimes used repeatedly you will be forced to lift your fingers off of the modifiers after each
use of the binding. You can mitigate the annoyance by placing the xdotool commands inside of a
script and killing old instances of the script (if any exist) before moving forward. Something like
this works good:

pid_file=/tmp/"$(basename "$0")".pid
old_pid="$(cat "${pid_file}")"
if kill -0 "${old_pid}" &> /dev/null; then
    kill "${old_pid}"
fi

echo "$$" > "${pid_file}"

DO STUFF HERE (--clearmodifiers)

sleep 0.5 && xdotool keyup Meta_L Meta_R Alt_L Alt_R Super_L Super_R
@wavexx

This comment has been minimized.

Copy link

@wavexx wavexx commented Oct 23, 2018

Same here. The action sequence is the following:

  • I invoke xdotool with "Ctrl" held, since xdotool is triggered by some shortcut
  • xdotool --clearmodifiers will reset the ctrl state and perform the action as intended
  • while xdotool is operating, I lift the finger from Ctrl
  • xdotool completes the action, and restores the "Ctrl" state, although "Ctrl" is no longer physically held on the keyboard.

My memory is fuzzy on the details. Is is possible to query the physical state bypassing the X state?
Maybe through xinput directly?

This would fix this issue.

@dimitarvdimitrov

This comment has been minimized.

Copy link

@dimitarvdimitrov dimitarvdimitrov commented Jan 17, 2020

Any updates on this?

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 7, 2020

After a poke on twitter, I did some thinking about this. The problem as I understand it is described well in this issue -- it's basically a race between xdotool resetting modifier/key states and the human releasing the keys physically. When the human releases before xdotool finishes, it will restore any modifiers (as if you are holding shift or contrtol or other modifier keys) even after a human has released.

I'm not confident we can solve this race condition, so I am thinking we can change the behavior of xdotool to not restore modifiers. Whether this behavior change happens through a flag or not, I am not sure and will rely on y'all to help me figure out if this should be the default behavior or not.

I have ideas for what the human interface for this could look like, but first I'd like to test a solution!
I've opened #276 which disables the "restore modifiers" piece of --clearmodifiers and hopefully results in some improved behavior for folks. If you are able to test this branch, please report any findings (successful or otherwise)

@focusaurus

This comment has been minimized.

Copy link

@focusaurus focusaurus commented Feb 7, 2020

FYI I have posted a bounty for this issue on bounty source. Would love to see us figure out a clean solution.

https://www.bountysource.com/issues/2526330-modifiers-can-become-stuck-after-using-clearmodifiers

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 7, 2020

A rough outline of the solution is to avoid having xdotool race the human. To do this, we must have a way to skip the "restore modifiers" step.

I'm thinking that --clearmodifiers should, by default, skip restoration of modifiers.

Restoring modifiers was intended for a kind of "xdotool shouldn't do anything unexpected to the keyboard state" and when a human invokes xdotool via hotkey that uses a modifier (say, control + F1), the human could release those keys before xdotool "restores" the clearing of the control modifier.

Given the use cases here, I suspect it's mostly humans invoking xdotool via such hotkeys and ultimately beating xdotool at this race, leaving xdotool to do something unexpected and undesired.

Proposal:

  1. Have all --clearmodifiers flags no longer attempt to restore modifiers
  2. Later, if someone needs it, we can add a way (flag, or otherwise) to add modifier restoration back in?

Ultimately, if time ordered steps occur as follows, the keyboard should not have an active modifiers by the end:

  1. Human presses control+f1 hotkey to invoke xdotoolkey --clearmodifiers ... (using xbindkeys or something)
  2. xdotool sees 'control' modifier is active and clears it
  3. xdotool types the keys as instructed
  4. human releases control key
  5. xdotool finishes

Today, step 5 is xdotool restoring ("pressing") the control key before exit which leaves it in the stuck-down state as reported in this issue. My proposal in the PR linked #276 is to no longer do this restoration.

@focusaurus

This comment has been minimized.

Copy link

@focusaurus focusaurus commented Feb 7, 2020

I will try to build and test the branch. I think this comment from @wavexx is an accurate and concise description of the issue. I don't know what APIs and techniques are available as I have not done any X11 programming myself, but I think logically the cleanest solution would be for each modifier that was initially detected, then cleared for the scripted keystrokes, before restoring it confirm it's still down. If so restore it, but if it's up, don't restore it.

Although in my particular use case I think maybe Jordan's proposal would work. Here's the details of how this bug impacts me:

  • I'm navigating tabs (tmux, firefox, vs code, etc I have them all scripted this way)
  • So I press and hold my modifier which is super then I type a letter bound to a "next tab script", it runs, invokes an xdotool to send the appropriate app hot key, but I might hit the letter again and again without ever releasing super to move additional tabs. When I'm finally done I'll release super but if I do that too quickly I'll hit this bug and it's stuck down.
@focusaurus

This comment has been minimized.

Copy link

@focusaurus focusaurus commented Feb 7, 2020

I tested the fix in #276 but it screws up my usage pattern because now even though I'm still physically pressing my super modifier, xdotool now clears it so instead of triggering my same hotkey again I'm now just typing letters.

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 7, 2020

but I might hit the letter again and again without ever releasing super to move additional tabs

Ahh yeah I didn't think this was what you were doing; I agree with your point about @wavexx's comment.

It is possible to query the physical keyboard state using XQueryKeymap, and this is what happens internally in xdo's xdo_get_active_modifiers.

It shouldn't be too hard to query the keymap a second time (when it comes time to restore) and only restore modifiers for keys that are still pressed. However, I am still not certain about timing/race conditions. I'm willing to write the code and hope that testing shows it works ;)

On timing, honestly, xdotool key --clearmodifiers ... should practically execute extremely quickly. Fast enough that hotkey activation (and xdotool invocation) and human keyboard key release shouldn't really even compete! And yet, these races still happen somehow where the human key release happens before xdotool finishes? I don't know exactly why or how this happens, but xdotool typing should be much faster than a single keystroke at normal human typing speeds... My hypothesis is that because we are seeing these races in which humans release a key faster than xdotool completes, then even if we rescan the active keyboard keys, it'll still be too slow somehow. One way to test is to write the code to try this rescanning and let y'all test.

In my head, the code to rescan and selectively restore only keys that are still active should be pretty simple (intersect two lists, etc) so I can probably have a patch ready to try later this week.

@focusaurus

This comment has been minimized.

Copy link

@focusaurus focusaurus commented Feb 7, 2020

OK bear in mind there's other stuff at the start of the "race" like scripts running assorted commands, forking processes, etc, so the timing might be like:

  • I keydown a letter that starts a hotkey
  • hotkey launches a script
  • script runs a bunch of unrelated commands that take non-zero time
  • script runs xdotool --clearmodifiers (I'm still holding the modifier)
  • I just happen to release the modifier at this moment but bear in mind this could easily be 100ms from the start so it's not like I'm racing xdotool for something like 1ms
  • The xdotool restores the modifier resulting in the stuck bug

note my actual xdotool command in the most common case is xdotool key --clearmodifiers ctrl+b o so it's 2 separate keystrokes which adds a tiny bit of delay.

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 9, 2020

Small status update.

XQueryKeymap shows what X11 believes about the current key state which includes anything sent with XTEST. In my testing, this shows:

  1. Human presses and holds shift
  2. Xdotool --clearmodifiers releases shift key
  3. XQueryKeymap shows shift is no longer held even though the physical key is held.

This means that we can't use XQueryKeymap to see if a key is still held by the human.
I'll check for any other API which might expose the physical keyboard key states.

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 9, 2020

It's possible XINPUT or xkbcommon could help here. xinput shows physical device state:

# Hold ctrl and shift keys down shortly after starting the command below
% sleep 0.5; xinput query-state 7 | grep -v up;  xdotool keyup Shift_L; xinput query-state 7 | grep -v up
1 class :
KeyClass
	key[37]=down
	key[50]=down
1 class :
KeyClass
	key[37]=down
	key[50]=down

7 above is device id 7 which on my system is my physical keyboard device:

↳ Windows keyboard id=7 [slave keyboard (3)]

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Feb 9, 2020

side note: It might be easier (?) in the long-term to move the input (keyboard/mouse) stuff to a separate library from xdotool. Wayland is coming to most major distros if it isn't there already, and xdotool doesn't really work at all on these systems.

There are non-xdo alternatives for input emulation like Linux's uinput kernel module which lets you simulate keyboard/mouse inputs from userland similarly to xdotool, but the interface for uinput is the linux kernel instead of xdo's x11 interface.

I've been thinking about doing exactly this for several years now. It's a larger effort than this particular xdotool bug, I think, but might be worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.