Accented keys aren't correctly typed

[albakham]

I'm using rofi-pass, and I can see that some of my passwords are not correctly typed by ydotool, with the french caracters 'é', or 'à' or 'è'…

For example if I enter ydotool type "Hello, it's working, after é it is not" it returns: Hello, it's working, after but nothing after the special caracter.

[jampe]

I can confirm this problem.

It would be great to have a parameter allowing you to set the keyboard layout used by the tool or autodetecting the active keyboard layout. I'm using a qwertz keyboard which resulted in z and y beeing swaped. I was able to resolve this issue by by setting the keyboard layout manually per attached keyboard (per identifier) instead of globally in my sway config. Not perfect, but a workaround until the issue is resolved. The problem with the accented keys like ä, ö, ü on german keyboards remains tho.

[barraponto]

I have the opposite issue. I want it to type something like nanana'K and it actually types nananaḰ. I wish I could configure it to escape those diacritics.

[danielcb]

@danieljampen how did you do that? I've set:

input "1130:17:HID_046a:0011" {
    xkb_layout de
}

in my sway config and swaymsg shows "xkb_layout_names": [ "German" ], for that keyboard, but ydotool type y still prints z.

Is there another way to set the layout for ydotool?

[Smattr]

IIUC this actually affects all non-ASCII unicode. Or maybe the following is a separate problem?

# under X
xdotool key U201c # types “

# under Wayland
ydotool key U201c # types u

[ragusa87]

I have the same issue on Sway (1.6-rc2) I tried to use the US keyboard to fix the problem but it didn't worked.

input * {
 xkb_layout "ch"
 xkb_variant "fr"
 xkb_numlock enabled
}

input "9011:26214:ydotoold_virtual_device" {
 xkb_layout "us,us"
 xkb_variant "euro,"
 xkb_options "grp:shifts_toggle, caps:swapescape"
}

[paullaffitte]

I'm not sure if it's related but I'm unable to insert emojis, with the command ydotool type '😋' for instance.

[fdw]

Since support for emojis still isn't there, is it even planned for ydotool?

[bencollerson]

I have a work-around in terms of inserting non-ascii strings from password managers etc.

Instead of trying to type unicode strings directly with ydotool, try piping the unicode string into the clipboard with wl-copy and use ydotool to send a ctrl-v paste keystroke.

Something like the following:

echo -n "secret" | wl-copy
ydotool key 29:1 47:1 47:0 29:0

[Smattr]

This works for some GUI programs. But not for programs where Ctrl-V does something other than paste, e.g. Vi. There are also a number of drawbacks for something like a password manager to transiently have its secrets resident in the system clipboard.

[bencollerson]

All good points. My example code was just to put across the basic idea.

1. Different keys can be sent to paste the clipboard based on the currently active app using a wrapper script.

2. There is currently no way to simulate sending arbitrary unicode "keystrokes" from ydotool. I provided a workaround to help people who want a way to send arbitrary unicode to applications using ydotool (and wl-clipboard). If someone wants to use it for their passwords, that is up to them, as are any risks.

[aerosol]

FWIW wtype seems to work just fine

[Smattr]

ydotool and wtype appear to use differing APIs: uinput for ydotool and wayland-client.h for wtype. wtype seems to handle non-ASCII by appending new entries to its keymap table. To add further confusion, it seems the blessed way to do this now is neither uinput nor wayland-client.h but libei.

I think (untested) it should be possible to retain the current design of ydotool but support non-ASCII by using xkb_utf32_to_keysym. This would require (1) adjusting all the type_char-calling loops in tool_type to anticipate UTF-8 and move character-by-character instead of byte-by-byte and (2) translating each UTF-8 character to a UTF-32 character and then to a key sym.

[vdegenne]

I have the same problem, Japanese characters (Kanjis) won't type

[protist]

For those looking for alternatives in the meantime, I tested the following to see if they support emoji.

• wtype seems to work as above, but doesn't run on KDE nor Gnome.
• dotool doesn't seem to work for emoji, giving the error dotool: WARNING: impossible character for layout: 😰.
• kdotool can't type characters.

[Smattr]

To unfortunately poor more cold water on this, a couple of months ago I tried the change I described above and found that approach doesn’t work. wtype’s technique is the only working approach I’m aware of, modulo the limitations protist notes.

[leg7]

Still a problem