Switch to ydotool?
Opened this issue · 24 comments
Just found ydotool, which is an xdotool replacement that works under wayland. Everything seems to be working very well, so I thought this would be a great alternative for rofi-pass to use also, to make it compatible with wayland. I don't know what kind of restrictions the fact that rofi runs under xwayland represents though.
EDIT: I actually did a simple :%s/xdotool/ydotool on the rofi-pass bash script and it doesn't work when used over wayland native applications. Good news is, it seems to be a drop in replacement as it works over xwayland windows still. Once (if ever) rofi goes native wayland this would be a simple migration.
This would be nice as an option. It seems that ydotool doesn't have issue jordansissel/xdotool#97 for me. I have a custom layout, and even with setxkbmap, xdotool types the incorrect case for some letters.
Ok, I played a bit with it. A few things that instantly stick out:
- It requires a kernel module, not a big deal, but one has to know that a newly installed kernel will require a reboot before rofi-pass works again.
- ydotool keeps dropping the first letters of my passwords. This might have to do with the --delay option, but setting that to zero only makes things worse. Removing --delay altogether helps though, so I got rid of it for now, which is obviously not ideal.
- For some reason autotype adds some characters between user and password
If you want to try it out and fix issues, have a look here:
https://github.com/carnager/rofi-pass/tree/ydotool
Removing --delay altogether helps though, so I got rid of it for now, which is obviously not ideal.
See ReimuNotMoe/ydotool#5. Hopefully this can be reliably fixed.
For some reason autotype adds some characters between user and password
It looks like ydotool key space just inserts an "s" for me. ydotool key " " and ydotool key enter work for me. I made an issue: ReimuNotMoe/ydotool#10.
Okay I tested the ydotool branch and it seems to work really well! One small change was required though, ydotool has named keys a bit differently, f.ex xdotool key Return translated to ydotool would be ydotool key enter. After changing that it works flawlessly for me.
I changed those key names in the ydotool branch. Anyway, it does not help with my issues.
i have a password file which has "rasi" as username and "some words as password"
the result is:
rasqal-config some words as password
No clue where the "qal-config" part is coming from :)
Also it seems the "i" of the username is missing.
I guess it must be the "Tab" key, tried to change ydotool key Tab to ydotool key tab, but no difference.
I created an AUR package of the ydotool branch
I am an idiot. I tested the autotype stuff in a terminal and the "tab" event simply completed "rasi" to "rasqal-config"
😄
So now I can work on integrating ydotool as a config option.
Ok, I played a bit with it. A few things that instantly stick out:
* It requires a kernel module, not a big deal, but one has to know that a newly installed kernel will require a reboot before rofi-pass works again. * ydotool keeps dropping the first letters of my passwords. This might have to do with the --delay option, but setting that to zero only makes things worse. Removing --delay altogether helps though, so I got rid of it for now, which is obviously not ideal. * For some reason autotype adds some characters between user and passwordIf you want to try it out and fix issues, have a look here:
https://github.com/carnager/rofi-pass/tree/ydotool
Now the delay related issue is solved by running a persistent daemon in background.
For detailed explanation, you can have a look at ydotool issue #5.
uuh, very nice, I will base the ydotool branch on that, most likely on the weekend. But don't expect this to go to master for the time being, since this is not in stable ydotool yet.
Very nice seeing this go forward! I've been using the ydotool branch for a while now and while it's not as polished as the xdotool version, it works fine for my needs.
As a side note: while ydotool works under X too, there might be reasons why some people would like to continue using rofi-pass with xdotool. What are your thoughts on going forward @carnager? A couple of options come to mind:
- Make a separate repository, maybe named rofi-pass-ydotool and keep the current repo as-is
- Tag a final release of the script with xdotool (probably already done) and pull the ydotool branch to master
Very nice seeing this go forward! I've been using the ydotool branch for a while now and while it's not as polished as the xdotool version, it works fine for my needs.
As a side note: while ydotool works under X too, there might be reasons why some people would like to continue using rofi-pass with xdotool. What are your thoughts on going forward @carnager? A couple of options come to mind:
1. Make a separate repository, maybe named rofi-pass-ydotool and keep the current repo as-is 2. Tag a final release of the script with xdotool (probably already done) and pull the ydotool branch to master
Like I said above:
So now I can work on integrating ydotool as a config option.
I might make this automatic, aka use ydotool if available, otherwise use xdotool, but I def. want the user to be able to force one option in config.
Oh yeah, that's even better ✌️
Ok, ydotool finally compiles again, but ydotoold segfaults for me. Let's see when I find the time to debug this.
@carnager I had some permission issues after the refactoring of ydotool. Previously I had a udev rule like this: KERNEL=="uinput", MODE="0660", GROUP="users", OPTIONS+="static_node=uinput" which would allow me to use ydotool without root. However this rule does not seem to work with ydotoold. I know it's not a real solution but try running it with sudo.
Running it with sudo does not help. Also my debug build that I created to dig deeper didnt crash anymore. Gotta love Heisenberg bugs. 😄
Ok, current master of ydotoold seems to work fine. Updated the ydotool branch with config option and ydotoold support.
At least in Arch Linux ydotoold works out of the box without any udev rule, for other distributions this is most likely not the case.
It's working :) However, it won't type special caracters such as "é", "è", or "à" (probably related to ydotool so I opened an issue here ReimuNotMoe/ydotool#22
but there is an other problem, all passwords with the caracter ' in the field won't be typed entirely. As ydotool type "somepasswordwith'workingcorrectly" is typed entirely I suppose it is related to rofi-pass?
yeah, I can confirm, those characters break gopass
Passwords containing single quotes work just fine here, though
What's the status of this? I have been using the ydotool branch for quite some time and I'm pretty happy with it. Unfortunately it broke on the recent update of ydotool, however, it is easily fixable (ydotool replaced the --delay flag with --key-delay). Any chance this might be fixed (at least in the ydotool branch)? That way I wouldn't need to patch it locally. I can also provide a PR if necessary but it really just is "replace --delay with --key-delay and make sure that --key-delay is in front of every occurence of ${xdotool_delay} (sometimes, the --delay flags seems to have been missing previously)".
I can also provide a PR if necessary but it really just is "replace
--delaywith--key-delayand make sure that--key-delayis in front of every occurence of${xdotool_delay}(sometimes, the--delayflags seems to have been missing previously)".
I just provided this change as a PR, hope it helps.
JFI: I came across xpaste when looking at alternatives to xdotool (https://github.com/ossobv/xpaste).
(It is rather unfortunate that xdotool is broken when using a non-us keyboard layout to start with.)
I have not tried ydotool, but IIRC it requires root / advanced setup?
(It is rather unfortunate that xdotool is broken when using a non-us keyboard layout to start with.)
If I remember correctly you can specify the desired layout just like for every other keyboard. There should be a xdotool daemon next to all your other input devices and you can change the layout for individual devices via their identifier.
Interesting!
There's a "Virtual core XTEST keyboard" input device indeed, and it can be addressed using setxkbmap -device $(xinput --ids-only "Virtual core XTEST keyboard") …, but it appears to be a bit inconsistent / not clear how it works exactly.
% localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: de-latin1-nodeadkeys
X11 Layout: n/a
% setxkbmap us -option
% xdotool key z # => z
# Changing the XTEST device changes it as expected:
% setxkbmap -device "$(xinput list --id-only "Virtual core XTEST keyboard")" de
% xdotool key z # => y
# But also when only changing another device (the effective device of the 3
# devices I have for "Microsoft Natural® Ergonomic Keyboard 4000"):
% setxkbmap us -option
% setxkbmap -device 23 de
% xdotool key z # => y
# That's the original issue I was facing currently.
# Changing the XTEST device additionally to be in sync with device 23 then fixes it:
% setxkbmap -device 5 de
% xdotool key z # => z
The odd thing here is that it behaves different when setting another device (10, new keyboard) to "de" (only, instead of device 23): then the XTEST device does not need to be changed to layout "de" also..!?
But it is also hard to tell how device specific settings get applied really,
since they cannot be queryied using setxkbmap -device X -query, which appears
to reflect the global/root state only/always?
I could imagine that there's some magic with the XTEST input device, where it translates based on some things it detects, but is off there then?
I've also just noticed that the output from xdotool is different based on which keyboard is used to send the command, i.e. likely the least recently used device then!? /cc @jordansissel
Ref: jordansissel/xdotool#150
I've found a workaround for the issue of using multiple keyboard layouts with xdotool: jordansissel/xdotool#150 (comment)