xdotool causes high cpu in Xorg on every key press, possibly refreshing keymap

[octodapple]

For example

xdotool key a

causes the Xorg process to use high cpu for about 1 to 2 seconds, in Ubuntu 18.04.1, xdotool version 3.20160805.1.

I suspect that xdotool key is triggering a keymap change or refresh, every time. If you change the system keymap, for example in Ubuntu settings, region & language, input sources, this will also trigger the exact same high cpu, for the same amount of time, in Xorg.

This makes xdotool key very slow and unsuitable for regular use.

I can't find anything about a keymap change in the system log or xorg logs. But we noticed a problem with autokey detecting a keymap change in its logs, on every xdotool key, written about here.

A similar high cpu usage shows up with xmodmap, which is changing the keymap.

To be clear, this xdotool issues shows up when all other hotkey programs are not running (autokey, xbindkeys etc).

I couldn't find exactly where the keymap is changed in the xdotool code. However in xdo.c in the function _xdo_send_key, looking at this line...

XSync(xdo->xdpy, False);

if you put a usleep(3000000); before this line vs after this line, the high cpu will occur before / after the sleep period. Commenting that line out doesn't solve the problem, since XSync appears elsewhere in the code.

A similar looking command

XFlush(xdo->xdpy);

appears in many places in the xdo.c. Removing them prevents the high cpu problem, but causes the key to be sent to stdout instead of being pressed to the gui. Maybe that provides some clues.

If anyone can determine how to disable this keymap refreshing, it would be very helpful, and make xdotool usable again.

Possibly related issues: .Xmodmap file makes xorg temporarily reach high cpu usage https://bugs.launchpad.net/ubuntu/+source/linux/+bug/998310

[jordansissel]

This sounds like a bug. Xdotool should only be changing the keymap if a requested character or key is not mapped, and it seems weird that “a” wouldn’t be mapped.

Thank you for these details!

Can you include also what keyboard mapping you are using? This info may help in reproducing and eventually fixing this bug.

On Sat, Oct 27, 2018 at 2:49 PM octodapple notifications@github.com wrote:

For example

xdotool key a

causes the Xorg process to use high cpu for about 1 to 2 seconds, in Ubuntu 18.04.1, xdotool version 3.20160805.1.

I suspect that xdotool key is triggering a keymap change or refresh, every time. If you change the system keymap, for example in Ubuntu settings, region & language, input sources, this will also trigger the exact same high cpu, for the same amount of time, in Xorg.

This makes xdotool key very slow and unsuitable for regular use.

I can't find anything about a keymap change in the system log or xorg logs. But we noticed a problem with autokey detecting a keymap change in its logs, on every xdotool key, written about here https://github.com/autokey/autokey/issues/193.

A similar high cpu usage shows up with xmodmap, which is changing the keymap.

To be clear, this xdotool issues shows up when all other hotkey programs are not running (autokey, xbindkeys etc).

I couldn't find exactly where the keymap is changed in the xdotool code. However in xdo.c in the function _xdo_send_key, looking at this line https://github.com/jordansissel/xdotool/blob/08c8e2d6cad60a69ce415499e34865157a1b66fd/xdo.c#L1539 ...

XSync(xdo->xdpy, False);

if you put a usleep(3000000); before this line vs after this line, the high cpu will occur before / after the sleep period. Commenting that line out doesn't solve the problem, since XSync appears elsewhere in the code.

A similar looking command

XFlush(xdo->xdpy);

appears in many places in the xdo.c. Removing them prevents the high cpu problem, but causes the key to be sent to stdout instead of being pressed to the gui. Maybe that provides some clues.

If anyone can determine how to disable this keymap refreshing, it would be very helpful, and make xdotool usable again.

Possibly related issues: .Xmodmap file makes xorg temporarily reach high cpu usage https://bugs.launchpad.net/ubuntu/+source/linux/+bug/998310

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordansissel/xdotool/issues/231, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIC6vtrt9ya0uiDt35sEuIVnZ0gJjKSks5upNTvgaJpZM4X9qaW .

[octodapple]

I'm using standard US english keyboard layout. I've only added other layouts to test the high cpu problem, and then removed them. I looked briefly at Kubuntu (in a virtual machine), and saw high cpu in kwin_x11 and Xorg processes, and the same in Mint Cinnamon with cinnnamon and Xorg processes Looking at it with faster refresh rate on top, I now see its not 1-2 seconds, its much shorter, a fraction of a second, but still detectable, and can still be a problem if you are regularly using xdotool with lots of hotkeys / shortcuts. I've tried commenting out various lines involving XChangeKeyboardMapping, keymapchanged = 1, _xdo_charcodemap_from_keysym and so on, but I can't seem to make a difference. Thanks for your great work on this program.

[sabian2008]

I experience this issue too. And I need do need a custom keymap.

Please let me know if I can provide any useful information.

[sabian2008]

Well, this is strange.

I created a new user, which uses the exact same keyboard layouts my main user has, in the same order. Everything looks exactly the same (same DE, etc.). However, my main user has this CPU spike that renders xdotool unusable, whereas for this newly created user xdotool works like a charm.

I've checked both home directories for differences in .X* files and didn't find anything meaningful.

Now I'm really puzzled.

[justinslatten]

I have created a launcher icon (Ubuntu 19.04 Gnome) to execute xdotool to open application grid (Super key aka the Windows key) and it seems to trigger bizarre issues. Intermittently my Xorg session crashes when I execute the launcher which then triggers the apport process to go haywire. The load average quickly starts ramping up to 15+ load average in the seconds after launching. Xorg becomes mostly unresponsive and I'm forced to go into an alternate terminal session to kill off the Apport process. Once killed the system returns back to normal. Unless resolved I'll probably have to start using some other tool to execute key strokes on my behalf.

[dchen327]

Well, this is strange.

I created a new user, which uses the exact same keyboard layouts my main user has, in the same order. Everything looks exactly the same (same DE, etc.). However, my main user has this CPU spike that renders xdotool unusable, whereas for this newly created user xdotool works like a charm.

I've checked both home directories for differences in .X* files and didn't find anything meaningful.

Now I'm really puzzled.

Were you ever able to get this fixed? I'm having cpu spikes in Pop OS.

EDIT: In Pop OS Region & Language settings, I changed a setting from Use the same source for all windows to Allow different sources for each window. Changing this setting seems to have reduced the CPU spike from around 100 to 50%. I am able to toggle back and forth between these two options and the issue seems to have been fixed.