'q' characters instead of '/' with xdotool type '/' about xdotool HOT 22 OPEN

It seems that a single call of setxkbmap without arguments helps as well:

$ xdotool type --clearmodifiers --delay 0 '[ ]'
8 9
$ setxkbmap
$ xdotool type --clearmodifiers --delay 0 '[ ]'
[ ]

from xdotool.

Any progress on this?

from xdotool.

I encounter the same, or at least a strongly related, issue with with @ being typed as 2 on a dk layout. (@ is AltGr+2 on a danish keyboard. not sure if that says anything)

I confirm that calling setxkbmap without any parameters also fixes this for me.

Setup: Nixos, i3wm

from xdotool.

What version of xdotool?

from xdotool.

xdotool version 2.20110530.1

from xdotool.

Sweet, thank sfor the details. I'll try to reproduce with your keymap. I think this is a known (old!) issue that should be fixed in master, but I'll try to confirm for you.

from xdotool.

Yeah, I've seen some old bug reports about it. Thanks!

from xdotool.

I have a similar problem, and tried it with master. This is the output with some printf's enabled:

% xdotool type :   
Finding symbol for key ':'
  => MATCH to symbol: 58
Found key for :
code: 47
sym: colon
keyseqlist_do: Sending : down (47, mods 0)
Ökeyseqlist_do: Sending : up (47, mods 0)

% setxkbmap -print
xkb_keymap {
  xkb_keycodes  { include "evdev+aliases(qwertz)"   };
  xkb_types     { include "complete"    };
  xkb_compat    { include "complete"    };
  xkb_symbols   { include "pc+de(nodeadkeys)+us:2+inet(evdev)+level3(ralt_switch_multikey)+capslock(ctrl_modifier)" };
  xkb_geometry  { include "pc(pc105)"   };
};

% setxkbmap de    
% xdotool type :  
Finding symbol for key ':'
  => MATCH to symbol: 58
Found key for :
code: 60
sym: colon
keyseqlist_do: Sending : down (60, mods 0)
:keyseqlist_do: Sending : up (60, mods 0)
% setxkbmap -print                        
xkb_keymap {
  xkb_keycodes  { include "evdev+aliases(qwertz)"   };
  xkb_types     { include "complete"    };
  xkb_compat    { include "complete"    };
  xkb_symbols   { include "pc+de+inet(evdev)+level3(ralt_switch_multikey)+capslock(ctrl_modifier)"  };
  xkb_geometry  { include "pc(pc105)"   };
};

":" is where "Ö" is on the en/us layout.

When I press ":", it gets translated to the keycode that "Ö" uses.

This seems to get triggered by the difference in setxkbmap's xkb_symbols (+us:2).

from xdotool.

For reference: (one of) the issue(s) in the old(?) tracker: https://code.google.com/p/semicomplete/issues/detail?id=55

from xdotool.

For me, it's also failing with related issue (replace / with ` for instance).
I have the us,ca keyboard map set.

But I noticed that if I first:
setxkbmap us

Then xdotool type start behaving properly (but I then cannot switch anymore to my alternate key map). setxkbmap us,ca will bring me back to my default keyboard layout.

from xdotool.

Same here. My keyboard layout is set to fr in /etc/X11/xorg.conf.d/10-keyboard.conf, but xdotool type as a US keyboard. setxkbmap fr does fix it.

from xdotool.

Just encountered this problem. Using Ubuntu Trusty 14.04 with xdotool package version 1:3.20130111.1-3.1, keyboardmap us,gr. setxkbmap us fixed it.

Glad I found this bug report, or it would have been hard to figure out. :)

from xdotool.

I also noticed that xdotool did not type characters correctly.
And after I did setxkbmap us it did start typing correctly, but strangely enough, even after doing setxkbmap back to my previous keyboard layout, xdotool still typed correctly.
Only after reboot it starts typing incorrectly again. but since workaround seems to be two setxkbmap commands per session, it doesn't bother me too much.

from xdotool.

I can also reproduce this issue (using xdotool 1:3.20160805.1-4 from Debian unstable):

$ xdotool type --clearmodifiers --delay 0 '[ ]'
8 9
$ setxkbmap us
$ setxkbmap gb
$ xdotool type --clearmodifiers --delay 0 '[ ]'
[ ]

from xdotool.

@hvhaugwitz
And what is your xkbmap initially?

FWIW your example works for me using setxkbmap -layout de -variant nodeadkeys -option -option 'caps:ctrl_modifier' -option 'lv3:ralt_switch_multikey' (xdotool version 3.20160805.1, Arch Linux).

from xdotool.

@blueyed xkbmap is set to gb initially:

$ setxkbmap -query 
rules:      evdev
model:      pc105
layout:     gb
options:    compose:menu

from xdotool.

Any progress with this issue?

from xdotool.

sigh Just hit this bug again, vaguely recalled encountering this behavior, googled xdotool input colon q, and ended up here, finding my comment from almost 2 years ago.

When I do xdotool type :, the window receives a Q instead. Running setxkbmap us fixes it. But I'm writing a script to demo some software, and I don't know if I should put that in the script, or just document that it should be used before running the script.

from xdotool.

Same strange delay on Ubuntu 20.04... almost 4 seconds to output the key if the layout is br.

thyarles@t7:~$ setxkbmap -query 
rules:      evdev
model:      pc105
layout:     br

thyarles@t7:~$ time xdotool key slash
real	0m4,160s
user	0m0,005s
sys	0m0,004s

thyarles@t7:~$ /

thyarles@t7:~$ setxkbmap us

thyarles@t7:~$ time xdotool key slash
real	0m0,040s
user	0m0,001s
sys	0m0,008s

thyarles@t7:~$ /
thyarles@t7:~$ xdotool -version
xdotool version 3.20160805.1

I think this is a Gnome/X11 issue, because I have the same behavior with the xte of xautomation package.

from xdotool.

Is it fixed already? I have this behavior on GNOME/X11.

from xdotool.

I've found xpaste, which appears to not have the problem (of being influenced/remapped via setxkbmap): https://github.com/ossobv/xpaste/blob/ea8b2ff9f839f9ecc345fd9d04014b99def5b112/xpaste

It is using Xlib.XK.string_to_keysym, and Xlib.XK.string_to_keysym("y") returns the same (121/0x79) with both setxkbmap us and setxkbmap de.
This might give a clue / idea about fixing this.

from xdotool.

I confirm the workaround proposed by @hvhaugwitz works great (whoa - how did you end up finding this?!).

Environment is Gnome as well (3.36.7)
Anyone tried to report it upstream?

from xdotool.