performance problems with X server freeze by inserting symbols like ä #10
Comments
|
Confirmed, producing 200 characters (200 bytes for Running Debugging tool that can be used: http://cgit.freedesktop.org/xorg/app/xscope/ Steps to test protocol differences:
Grab https://lekensteyn.nl/files/qemu-sdl-debug/xscope-filter and compare two files with: (needs |
|
...and the following shows the possible source of slowness: |
|
xdotool is only able to type letters that are mapped on your keyboard. If it detects situations where, for example, ä has no key mapping, it finds an empty key map and puts it there ("Mapping sym 228 to 8") and types it, then it reverts the keymap change ("Reverting scratch keycode") to restore the keymapping to the original setting. Your time output is... weird. I cannot reproduce this on Ubuntu 13.10 under Openbox. It's possible we can optimize this by finding a scratch keycode, using it for every unmapped key, and only doing the 'revert' step after we finish? I do wonder if your X server or window manager is buggy and causing this problem. I'm open to working around this inside xdotool if we can, but for now I cannot reproduce this delay or freeze. |
|
lol printf bug 'sym 4374148392801768192' but unreltaed to this problem ;) |
|
I'm testing with KDE 4.12.0, Xorg 1.14.5 on Arch Linux. My keyboard mapping is set to US International - AltGr dead keys. When I run A test with
|
|
Sounds like something is interfering with xdotool's setting of the keyboard mapping. The slowness combined with the null bytes sound like two symptoms of the same problem; very weird. I'd be interested in seeing which parts of the code were being slow; I'd bet it's just the XChangeKeyboardMapping calls. The fact that you're getting nulls is very troubling. xdotool sends XChangeKeyboardMapping and then XSync to make sure everything is aligned and sent to the X server, if the next SendKey attempt results in a null, it means that something bad happened to that XChangeKeyboardMapping call. I do notice that xdotool doesn't check the return value of XChangeKeyboardMapping (which can return BadAlloc and BadValue, according to the manpage); a failure here could explain the null byte typing, but it wouldn't explain the delays. XSync call might be what delays here; I'm not sure what the impact on performance is if there are lots of things waiting on MappingNotify events (perhaps KDE does this?). I'm not familiar with KDE nor do I have easy access to it at this time (I'd have to install it and try to debug, but don't have time today) Any debugging you can do here will help greatly :) |
|
Could this be a hint? (valgrind output is the same when I get The program at http://git.yoctoproject.org/cgit/cgit.cgi/libfakekey/tree/src/libfakekey.c is also affected. That program does, however, not revert the remapping. In a loop of 10 executions of the program, the execution time increases by about 400 ms (5xx ms vs 1xx ms) if the first run needs to remap a key. I do not experience issues with The following command causes my Xorg progress to use over 80% CPU (with (the code from version 2.20110530.1 segfaulted at the |
|
If Xorg is using high cpu, then I believe this to be a bug in Xorg; I do not experience this problem under Xorg 1.14.3 (Ubuntu 13.10 which includes an 18000-line patch on top of Xorg 1.14.3). Can you reproduce this delay-and-high-xorg-cpu under another windowing environment (Say, openbox, gnome, etc?) |
|
This is the #!/bin/sh
str=ääääääääää
#str=aaaaaaaaaa
f() {
time \
DEBUG=1 \
./xdotool type --terminator END \
" echo '$str' | xxd | grep -vw 'c3a4' | grep --color=always ." END \
key Return
# \
#type --terminator END $0 END \
#key Return
}
for i in {1..100}; do
f
ps auxww --sort %cpu | tail -n3
done
Run-time ( I think Conclusion: openbox (or the driver combination I used) is not affected by the performance problem. All keys are correctly processed, no events were lost. Digging further if time allows... |
|
The ( kde top CPU users: openbox top CPU users: |
|
I have the same problem with russian keyboard layout: |
|
I just wanted to say that this issue still happens when multiple keyboard layouts are used. It seems to only affect the layout which is not the default one, as changing the order in "Input sources" (in gnome), the layout on top will run flawlessly but the second one will have that delay. |
|
confirm: fine on first keyboard layout, slow on others |
|
Any news on this issue? |
|
+1 for this issue and btw it is freezing when try do |
|
"xdotool key super" takes about 2 seconds on the Russian keyboard. |
|
+1 |
|
On GNOME, I can solve this by running |
|
I see two tests here:
I could replicate both of the explained behaviors on Ubuntu 20.04. |
|
It is not limited to keys that don't appear on the keyboard. See for example: |
|
This issue is still bad. It's also present with apostrophes which for me will write 'èèèèèèèèèèè' instead of ''''''''''''' . Please someone we need a way to save the key code in a virtual keyboard in a way it doesn't have to be remade every time I think ? I'm not sure how to do this... |
|
For me, just to freeze about 3 seconds.Any one knows how to solve it programatically? |
|
This is still a problem on Debian Bullseye 9 years after the initial post in this thread... |
|
I just tried to reproduce this on both Windows 11 w/ WSLg (XWayland/weston) and on Xephyr with no window manager. I can't seem to reproduce any slowness. I believe there is a problem somewhere, but at this time, I"m not quite sure what is causing it. I'll keep thinking about it. I know this is an old issue without any known solutions yet. :( |
|
Ahh, with KDE running, I do see noticeable performance differences: Tested: US English layout, xdotool typing Russian. Xephyr with just Firefox running: Xephyr with
Trying a longer string, ПППППППППППППППППППППППППППППП:
Seems pretty well related to having a more complex desktop environment, like KDE, running. I can guess as, others in this issue have, that this has mostly to do with xdotool having to map symbols to keycodes vs not having to map anything (for example, on a US keyboard, there is no П key by default). I don't really know why it happens yet and will need to research and explore a bit more. |
|
Had a hypothesis that delays were related to the number of X11 windows, and tested: 1 xterm, 30 xterms, and 100 xterms. Test: Results:
Might be relevant, though the delays measured aren't close to those reported (multiple seconds delay for single keystrokes). I also noticed that |
|
After a bunch of testing tonight, I have a hypothesis that needs testing: When xdotool changes the keyboard mapping, all X11 clients receive a MappingNotify event where they will likely invoke XRefreshKeyboardMapping. It's possible this could incur a thundering herd situation where every client is trying to respond by updating their keyboard maps. This could especially become a problem for two reasons:
If this hypothesis is correct, it could be what causes the whole X11 system to freeze while typing. |
|
For posterity, here's some code I was using to test this outside of xdotool: |
|
I've reread this issue and I see a few different symptoms reported, I'll try to summarize:
🗡️ "normal" meaning keys already in your keymap, like "a" for US keymap or "П" for RU keymap. So far, I've been able to reproduce /some/ slowdown:
I haven't yet reproduced, and am not quite sure what causes:
|
|
I haven't been very helpful in this whole discussion. I am having the issue where the slowdown occurs with "non-mapped" keys. I am also running https://github.com/vividnightmare/g510s, which may or may not factor into it. That repo hasn't been updated in 5 years and perhaps was compiled using old libraries, which might explain why I am experiencing issues that were first reported 9 years ago. I love my Logitech peripherals but they aren't well supported under Linux and I am in the process of switching to Razer peripherals. Anyway @jordansissel, thank you for the effort on this, and if this is because I'm using old software, my apologies. I might be able to help myself by compiling the software myself with newer libraries. |
|
Actually, it has been so long since I managed to get my keyboard working almost perfectly that I've forgotten what I did to get it working. I am using the following repo: http://ppa.launchpad.net/vivnet/g510s/ubuntu focal So it should be compiled against relatively up to date libraries. |
Thank you for pursuing this as I know quite a few people are having this issue. |
|
I did @admirabilis suggestion to run Another thing I realized is that the |
|
I would like to share with you guys, Today I was testing a C++ script that opens Below is the code I am using. The problem arises when the method |
|
@mowses You might have hit on the real issue. Looking at your code I'm wondering if this is an issue located somewhere in the base Linux usb subsystem and drivers. I know I've had similar issues in ratbagd where certain actions take much longer than it seems they reasonably should, and then other issues with peripherals such as usb headsets that might be related. The question is, where to report this issue. I have no idea who is developing and maintaining that code, or even what it is called. That's pretty deep in the Linux OS, and close to the kernel. |
|
The different subsystem mailing lists and maintainers are here: https://www.kernel.org/doc/html/latest/process/maintainers.html I'm not sure which this would fit into. |
|
@Drek282 maybe it is a uinput module issue. Here's the link: the doc says: |
|
@mowses Which library/method does xdotool use? Or ratbagd for that matter? The long hang times I am seeing with ratbagd involve loading profiles to my usb mouse. Is it using uinput as well? |
|
@Drek282 I believe that the issue is like @jordansissel said:
Also I am facing more 2 weird behaviors that may corroborates to the @jordansissel hypothesis, but I would like to make sure it also happens to other people as well.
A curious thing is that I am just concluding that the reported issue is not related with xdotool itself but with some other linux kernel bug. |
|
@Drek282 the man pages of xdotool is written:
the source of file Here are the links for such libs: https://packages.debian.org/sid/libxdo-dev you may also want to check this xdo function references: https://libxdo-d.dpldocs.info/xdo.xdo_send_keysequence_window.html In order to fix this issue I think we need to address where this bug occurs in X11 lib. |
|
As a workaround, one can copy the text to clipboard and paste it instead of typing: # Hangs with long text and text with special characters:
xdotool type "$1"
# Does not hang for me:
echo "$1" | xclip -sel primary # for use with some shared clipboards (e.g. Remmina)
echo "$1" | xclip -sel clipboard # for use with local OS clipboard
xdotool key Shift+Insert |
|
So I'm not really sure why, but on a Ubuntu 22.04 (Xorg) VM, any xdotool typing takes at least one second, freezing the entire display for that duration. I don't see the problem limited to special chars like Same with python-evdev, something different entirely, not even depending on x11 (!): https://python-evdev.readthedocs.io/en/latest/tutorial.html#injecting-input this example also freezes up briefly. AutoKey, on the other hand, is able to type instantaneously! No idea why, it doesn't seem to do anything special either: https://github.com/autokey/autokey/blob/master/lib/autokey/interface.py#L1105 |
Using xdotool to insert charackters like äöü is really slow.
Inserting a
A more extreme example of inserting 10 characters at a time:
It does not take much cpu though as the user and sys time are really low. At least not the xdotool process. It also does freeze X for that time: no screen updates besides mouse movements are rendered.
Using "time xdotool key adiaeresis" can also used to produce the same effects.
The text was updated successfully, but these errors were encountered: