Doesn't work with non-QWERTY layouts (e.g. Dvorak)

[TinfoilSubmarine]

Hi, if I type in ydotool type "This is a test" I get this instead: Ydco co a y.oyv which signifies that ydotool is typing in QWERTY, not Dvorak.

For reference, I'm using sway as my WM and the following lines of config:

input * xkb_layout "us,us"
input * xkb_variant ",dvorak"
input * xkb_options "grp:shifts_toggle, caps:swapescape"

[ClassicOldSong]

https://github.com/ReimuNotMoe/ydotool/issues/22

[TinfoilSubmarine]

I'm looking at the codebase to familiarize myself with it. Since it seems that currently, we assume that the user wants to type in QWERTY, there really needs to be a way to consider if the user is using an alternative layout.

For example, one can modify /etc/vconsole.conf to use a different layout resulting in the same mismatch that I have while using a non-QWERTY layout in Sway.

As I see it, there are several options.

We can create separate tools for each instance, e.g. Sway-Type, Console-Type, etc. This would probably be easiest; we can confine the scope of each tool by assuming the user is in the expected environment.

Or, we can modify the existing Type tool to preferentially use the "highest" layer to determine the layout it should type in. So if we are executing ydotool from within a WM, we should try to use the WM's layout preference. If we are in console, we should use /etc/vconsole.conf. I'm sure there's some edge case I'm missing here, but you can understand the idea. This is probably more correct, but also more complex.

Thoughts?

[ClassicOldSong]

Thanks for digging into this.

I didn't have this issue while I'm using Norman Layout because my keyboard can configure as different layouts it-self, no need for OS or DE to map these keys. So change to a hardware based configuration could be another solution.

[TT-392]

I am pretty sure this is related even though I am on a pretty common qwerty layout. On a us(intl) layout on sway, ydotool type "^" seems to type a "~" instead (kind of a big deal for rofi-pass).

[eddy-geek]

Another imperfect option is how Hawck is handling this. In short, while it's also not autodetecting the layout, it's parsing console layouts and can be configured to use any of them to translate keys for input.

Of course console keymaps are not exactly the same as XKB ones, but this may be simpler/more portable than trying to use XKB ?

[flavi1]

I share here a temporary (and not consistant) fix for visitor that are looking to use ydotool in an azerty envoronnement

# azerty to qwerty
char=$(echo "$char" | sed -e 'y/²&é"(-è_çà)=azertyuiop^$qsdfghjklm*<wxcvbn,;:!³1234567890°+AZERTYUIOP¨£QSDFGHJKLM%µ>WXCVBN?.\/§/`123567890-=qwertyuiop[]asdfghjkl;\\êzxcvbnm,.\/~!@#$%^&*()_+QWERTYUIOP{}ASDFGHJKL:"|ÊZXCVBNM<>?/' -e "y/'ù/4'/")

(from https://linuxtrack.net/viewtopic.php?id=1380) Likely to be helpfull...

[poleprogger]

Is it possible to specify the wanted keyboard layout as parameter to ydotool?

[AndrewKvalheim]

Not currently. I’ve just been patching my layout in.

[jonas73x]

How did you figure out how do patch the layout? I see the ascii to keycode function in tool_type.c but can't seem to figure out how to specify the layout. At first I thought the "// 00 - 0f" etc were scancodes for a typical US layout, but that doesn't seem to be the case?

[AndrewKvalheim]

ascii2keycode_map translates from ASCII text to input events; the position in the list is what character to type, and the value is how to type it.

[jonas73x]

thank you! very helpful