Open tbenst opened 4 years ago
I was having similar problems on Ubuntu 18.04 with gnome. I discovered that if I installed the xubuntu-desktop
package and login with a Xubuntu session instead, then the problem is resolved and xdotool
is much more responsive.
I had what I believe is the same issue (tested via dragonfly.Key()) appear quite suddenly after having correct behavior yesterday. Back to normal again now after reinstalling Ubuntu
I"m on Ubuntu 20.04
After reinstalling Ubuntu 3 weeks the problem is now back.
I believe xdotool is not the root cause of this. I have cloned this repo and rebuilt from scratch and still see the problem.
I can also work around this problem by using Xubuntu
same issue as https://github.com/jordansissel/xdotool/issues/10 I believe
I can work around this one by switching my keyboard back to English US in the Ubuntu interface.
@kendonB thanks for your work trying to figure out what’s going on. As I reported in the original comment, this problem occurs even when using only ASCII characters so #10 is unrelated I believe as that deals with is that deals with larger character sets. Likewise, the issue appears with both gnome and KDE. It is not a problem with X server as you can mash keys on your keyboard and see them show up without delay. As far as I can tell, it is indeed a xdotool bug.
From your reference the dragonfly sounds like you’re a voicecoder. I previously implemented a much faster way than xdotool for typing arbitrary strings that uses copy-paste (“Text” in Aenea). Please see https://kendonbcaster.readthedocs.io/en/latest/readthedocs/Aenea/ for some info on setting up. I hope this is helpful to you
@tbenst do you find that the bug disappears for ASCII characters after you switch to English US keyboard?
@Danesprite do you think that the clipboard-based solution @tbenst suggests is feasible for dragonfly?
@kendonB see this function here: https://github.com/tbenst/magneto-host/blob/1fbfbc496db5a55b123749b1bcf42e33d0aa5008/server/linux_x11/x11_xdotool.py#L350. I think I discussed upstreaming on gitter or somewhere else a few years back but didn't move forward, as my implementation only works on Linux due to how clipboards are implemented with swapping etc. Windows has to deal with nasty COM, so harder to make this crossplatform.
@tbenst the keyboard in dragonfly is implemented separately for each platform.
@kendonB @tbenst I haven't looked into this enough to judge whether it's a good idea. Middle click doesn't seem like a good solution if the mouse pointer isn't always where you want to type.
In any case, discussion on changes to Dragonfly's keyboard input code for X11 should really take place in a new Dragonfly issue instead of here.
I also experience these desktop freezes on my Ubuntu focal notebooks. SO 48038038 says it's about graphics drivers, but the bug occurrs on computers with nVidia graphics as well as Intel graphics. They are neither default Ubuntu nor default Xubuntu, but installed as minimal (console-only) Ubuntu, then lightdm + xfce4 added.
During the freeze, when I watch xinput test $KEYBOARD_ID
via SSH, it prints my keystrokes immediately, but gedit processes them only after the freeze. Unfortunately, in my case it's not even limited to long strings. Even just xdotool key Ctrl+a
causes several seconds of freezing.
Please help! I used to use xdotool a lot, for some tasks every few seconds even, so those freezes slow me down quite a bit.
I’ve been working on #10 recently with not much success. I have some ideas about some of the reported issues, but not all of them. https://github.com/jordansissel/xdotool/issues/10#issuecomment-935494368
Thank you for working on it! I'll try and also measure my Ctrl + {a,c,v} issues and with variying amounts of open windows.
As tested on two different machines running Ubuntu 18.04 (gnome) and NixOS 20.03 (KDE), respectively, for version
3.20160805.1
, the following command hangs my computer for 9 seconds:Using other delay values does not mitigate, and problem scales linearly with string length.