Byzantine char substitution in 'xdotool type' (_ -> ?) about xdotool HOT 10 OPEN

Apparently, changing the X keyboard layout to US solves the issue (and also makes the typing more fluid and responsive).
Specifically, I changed my script to

#! /bin/bash

setxkbmap us

[... original script here ...]

setxkbmap it # since that's what I use

I'll test this further but I think it's ok now (I'll comment again if the problem will reapear). However I'm still keeping this issue open for bug tracking purposes.

Thanks.

from xdotool.

This may be a known issue. For many years some folks have had this issue where xdotool types the wrong key. I’ve not been able to figure out the cause.

some workarounds folks have found are as you discovered, running setxkbmap usually fixes it, regardless of your key map.

it’s a hard problem to reproduce, from what I recall, so it’s been difficult to track down in the code.

I welcome any additional data/experience you can provide when you encounter this problem — what was typed wrong, what keyboard mapping was active, any workarounds you find, etc, as you’ve done already. I would love to figure out a solution for this :)

from xdotool.

Thanks! I start the process from an Emacs function; the other program I need to pilot is Otii. In the elisp code, I have

		     (async-shell-command (concat "/home/alessandro/xorg-session.sh "
					    current-instruction)
				    nil
				    nil
				    )

where current-instruction is the file name to be typed.
Conversely, xorg-session.sh is a bash script like this:

#! /bin/bash

xdotool mousemove --window $otii_window $otii_start_coord
sleep $buffer_timeout # I noticed that adding little pauses prevents overlapping of commands

xdotool mousemove_relative -- # the "save" button
sleep $buffer_timeout
xdotool click 1
sleep $buffer_timeout

xdotool type --delay 100 "$1"
sleep $buffer_timeout

# then switch back to Emacs

In this scenario, some file names were typed correctly; others aren't. For instance, adds_r0_r0_1.csv became adds?r0_r0_1.csv, and IIRC something similar to ciao_1.csv became ciao_ؿ.csv.

WORKAROUND: guarding the script with

#! /bin/bash
setxkbmap us

# [original script]

setxkbmap it

seem to solve the issue. Moreover, with the US keyboard, the typing is smooth, whereas in the previous setting it felt sometimes clunky (IIRC particularly where the _ gets changed).

Besides the info provided in the first message, I run GNOME with Mutter, and I'm on XWayland.

Thanks!

from xdotool.

I'm on Arch Linux too, using xdotool 3.20211022.1 and Xorg (no Wayland involved). I'm using the dvorak layout, and using xdotool key - caused [ to show up. Not coincidentally, the key labeled - on the standard US qwerty layout will type a [ character when configured as dvorak.

As a workaround (thanks @jordansissel!), running setxkbmap (without arguments!) before xdotool fixed it for me. However, since I ran that I've been unable to get the broken behaviour back.

Here's the relevant part of my Xorg config (generated by systemd-localed):

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us,us"
        Option "XkbModel" "pc104"
        Option "XkbVariant" "dvorak,"
        Option "XkbOptions" "compose:menu,terminate:ctrl_alt_bksp"
EndSection

The equivalent setxkbmap command should be:

setxkbmap -layout us,us -model pc104 -variant dvorak, -option compose:menu,terminate:ctrl_alt_bksp

The Option/-option bits are probably not relevant.

from xdotool.

I tried on Fedora 37 to use a different keyboard mapping entirely, and while I was successful in changing the keymap on login, I was unable to reproduce the problem still.

I tried setting the locale and keymap with localectl and then again in GNOME settings (because of course GNOME has its own thing). I ended up with a GNOME in German language and keymap, but xdotool still worked correctly. I wish I could reproduce this more easily as it would let me more quickly find a permanent solution :(

from xdotool.

Oddly, on macOS using XQuartz and Xephyr, I was able to reproduce this! First time in ... since as long as i can remember. It doesn't reproduce every time though.

from xdotool.

Even more oddly, on XQuartz+Xephyr, it doesn't seem to even be predictable. Sometimes running it once produces the wrong symbol and running xdotool type a second time with no changes... produces the correct symbol.

% DISPLAY=:0.0 DEBUG=1 ~/local/bin/xdotool mousemove 5 5 click 1 type -
command: mousemove
command: click
command: type
Exec arg[0]: -
Key '-' maps to code 35 / sym 45 [minus] in group 0 / mods 0 (ok)

⓿ baguette(~/projects/xdotool) master
% DISPLAY=:0.0 DEBUG=1 ~/local/bin/xdotool mousemove 5 5 click 1 type -
command: mousemove
command: click
command: type
Exec arg[0]: -
Key '-' maps to code 20 / sym 45 [minus] in group 0 / mods 0 (ok)

Notice in the second run, the keycode changes and on the second run does indeed type - (aka "minus")

from xdotool.

I am able to reproduce this in pure X11+xkbcommon, no xdotool.

On macOS, I run Xephyr, then I run a custom program to find the keycode for the - ("minus") symbol. Sometimes, the first run gets the wrong keycode and actually types [ ("bracketleft") instead of -.

% DISPLAY=:0.0 ./keycheck
XGetKeyboardMapping says XK_minus is code 35 entry 0
Sending keystroke (down + up) for code 35 (keysym minus)

# One second later with no other activity having occurred:
% DISPLAY=:0.0 ./keycheck
XGetKeyboardMapping says XK_minus is code 20 entry 0
Sending keystroke (down + up) for code 20 (keysym minus)

The first run above gives code 35 for - when in fact this keycode types [. This is verified through xev which shows the X11 client receiving:

KeyPress event, serial 28, synthetic NO, window 0x200001,
    root 0x388, subw 0x0, time 2246895981, (3,3), root:(5,5),
    state 0x0, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
    XLookupString gives 1 bytes: (5d) "]"
    XmbLookupString gives 1 bytes: (5d) "]"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x200001,
    root 0x388, subw 0x0, time 2246895981, (3,3), root:(5,5),
    state 0x0, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
    XLookupString gives 1 bytes: (5d) "]"
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x200001,
    root 0x388, subw 0x0, time 2246904489, (3,3), root:(5,5),
    state 0x0, keycode 20 (keysym 0x2d, minus), same_screen YES,
    XLookupString gives 1 bytes: (2d) "-"
    XmbLookupString gives 1 bytes: (2d) "-"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x200001,
    root 0x388, subw 0x0, time 2246904489, (3,3), root:(5,5),
    state 0x0, keycode 20 (keysym 0x2d, minus), same_screen YES,
    XLookupString gives 1 bytes: (2d) "-"
    XFilterEvent returns: False

Code to try this is here: jordansissel/experiments@1b969a8

from xdotool.

For the above, I'm unable to reproduce on Xorg on Fedora 37.. I'll keep digging as time permits.

from xdotool.

I observe a similar bug, but in a reproducible way. I use two keyboards with different layouts and the typed keys depend on the last keyboard which was used. I filed a bug against libX11, see https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/213.

from xdotool.