Repeated characters when --delay is large

[jidanni]

On my system today the repeating starts at around 996 ms.
for i in 980 990 998; do xdotool type --delay $i $i.; done
980.990.999988..
Even scarier is when one tries e.g., --delay 4000...
Also key --delay has similar problems.

xdotool version 3.20160805.1

[jordansissel]

I’m on my phone so it’s hard to check the code, but my guess is that xdotool splits the delay between the key press and key release, and maybe it shouldn’t do that for the reasons you’ve found! Assuming I’m remembering the code right, we should be able to make it so the delay between press and release is much shorter

…

On Wed, Apr 5, 2023, at 6:33 PM, 積丹尼 Dan Jacobson wrote: On my system today the repeating starts at around 996 ms. for i in 980 990 998; do xdotool type --delay $i $i.; done 980.990.999988.. Even scarier is when one tries e.g., --delay 4000... Also key --delay has similar problems. xdotool version 3.20160805.1 — Reply to this email directly, view it on GitHub <#423>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABAF2UHCFXIMLDPGG655F3W7YMOVANCNFSM6AAAAAAWUY27LQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jidanni]

Well, apparently there is some number hardwired into the program that the user cannot access.

Therefore, whatever you change, be sure to expose it so the user can also adjust it, in case whatever is assumed causes problems on his system.

[limitedAtonement]

I just did some experimentation which seems to verify

xdotool splits the delay between the key press and key release

(I think "apparently there is some number hardwired into the program that the user cannot access." is unrelated.) It appears that the key down event is issued immediately, and if --delay is specified, the key up event is done half way through the delay. So, a xdotool type --delay 2000 ss; will

• 0ms: s keydown
• 1000 ms: s key up
• 2000 ms: s key down
• 3000 ms: s key up
• 4000 ms: program quits with exit code 0

In other words, s is held for a second, released for a second, then held again for a second and released for a second. If your X server (window manager? I'm not sure what handles this behavior) repeats letters that are held for a long time like mine does, you'll get repeated keys.

[jidanni]

That's a great explanation to add to the man page. However I would use two different characters instead of the two of the same.

Also the man page could add an example of using the same long delay, but with added keyups, to avoid causing repeats.

[jordansissel]

The code indeed does what you describe -- it takes the delay and splits it evenly between the up and down strokes:

xdotool/xdo.c

Lines 989 to 992 in 7b63eb4

	/* Since we're doing down/up, the delay should be based on the number
	* of keys pressed (including shift). Since up/down is two calls,
	* divide by two. */
	delay /= 2;

I agree this behavior is not desirable. I think we can change xdotool to keep it from causing key repeats by changing the code to be a bit wiser -- reducing the delay used in the "down" event and spending most of the time waiting after the "up"

I'll see about making this change soon and let you know if it's available to test :)

[jidanni]

Good to have those changes. But be sure to expose the raw controls too in case some users need finer grained control.

[limitedAtonement]

I agree this behavior is not desirable. I think we can change xdotool to keep it from causing key repeats by changing the code to be a bit wiser -- reducing the delay used in the "down" event and spending most of the time waiting after the "up"

It's nice to know what it's doing. Predictable is better than unknown. Better still is configurable. Changing to a fixed 50ms delay or whatever is actually probably not good. Right now, we can at least adjust the "key down" time, but with a fixed key down time, it will no longer be adjustable. While you're there, maybe a "dwell time ratio" setting would be good? So the current behavior could be preserved by specifying a "dwell time ratio" of 0.5 (which should probably be the default). A ratio of 0.1 would mean "spend 10% of the delay time with key down", etc. Of course, additionally an absolute "dwell time" setting would be nice in milliseconds, too. I'm not sure if this is over-engineered, but it seems good to me.

[limitedAtonement]

Just to add some context: My usecase is to type up daily update messages to my colleagues in Slack. It's a local-running application, but heavily web-based which means it's SLOOWWW. The pattern is: CTRL+<client-number> CTRL+t (search box) type , enter, etc. There must be a delay between switching clients and navigating to the search box. After typing a channel name, if enter is pressed too quickly, the wrong channel will be selected. Later, I format typed text using `. Pressing the second ` should cause formatting to be applied, but it's slow. In general: I need gaps and relatively slow input so that the slack client can keep up, but I also want slow input so I can supervise what's going on and abort if necessary!

In this case, I would probably use an absolute dwell time of maybe 50 ms even if the --delay were set to 2000. (That would be a "dwell time ratio" of .025.)

I'm assuming everyone found this ticket because his own usecase also exposes it in some way.

[jidanni]

Wow, with all controls exposed, any "are you a human" typing test can be beat! Wait... #443 .

[Dunkhan]

So just to be clear, as it currently stands there is no way for me to for example

wait 5 seconds and then send key a down, key a up

could we get another delay modifier like --sleep or --wait that simply passes some time before sending the keystrokes?
It seems like there must be a lot of usecases where sending a normal keypress after a delay of a few seconds could be useful

In case it is relevant my actual use case is:

send alt key down, then press tab key, wait 3 seconds then send alt key up

I want this for a mouse button so I can alt-tab through applications with the mouse. The idea was that if I press the button again within 3 seconds I can alt-tab not to the last application that had focus but the one before it. 3 seconds should be enough to quickly switch among a set of 4-5 applications

[limitedAtonement]

So just to be clear, as it currently stands there is no way for me to for example
wait 5 seconds and then send key a down, key a up

Maybe not in one xdotool command, but something like this should work:

sleep 5;
xdotool keydown a keyup a || exit;

[jordansissel]

wait 5 seconds and then send key a down, key a up

@Dunkhan xdotool has a sleep command which may help if you need it, for example: xdotool sleep 5 key a will wait 5 seconds and then press+release the a key

I'll take a look at #471 which should help resolve this issue

[jordansissel]

#471 is merged which should help with this issue (character repetition when delay is large). It solves this by having xdotool hold the "key down" event for 50ms before releasing each key. The delay now affects only the time between each keystroke (down + up)

[jordansissel]

The pattern is: CTRL+ CTRL+t (search box) type , enter, etc. There must be a delay between switching clients and navigating to the search box.

@limitedAtonement I wonder if #471 affects you. The change in #471 only changes how the type command uses --delay and does not change the key --delay flag behavior. Please let me know if something is broken by this change in a new issue where I'd also like to hear about your use case a bit more :)

[jordansissel]

send alt key down, then press tab key, wait 3 seconds then send alt key up

@Dunkhan Try this:

xdotool keydown Alt keydown Tab sleep 3 keyup Alt

Keep in mind that the "Tab" key will still be pressed when xdotool ends.

If you'd rather "Alt+Tab" be held together for 3 seconds and then released, you can do this:

xdotool keydown Alt_L+Tab sleep 3 keyup Alt+Tab

[limitedAtonement]

I'd also like to hear about your use case a bit more

Thank you for taking note. I worked around my problem by incorporating calls to sleep (outside xdotool). I think having a fixed 50 millisecond dwell time is an excellent improvement. I have nothing to add about my usecase beyond what's written above.

...does not change the key --delay flag behavior.

Hmm, I would think making the key --delay work the same way would be correct, but I defer to others.