search

jordansissel / xdotool

fake keyboard/mouse input, window management, and more
Other
3.21k stars 318 forks source link

'q' characters instead of '/' with xdotool type '/' #49

Open rafi opened 10 years ago

rafi commented 10 years ago 
% xdotool type --clearmodifiers --delay 0 '////'
qqqq

My xmodmap -pke: https://paste.xinu.at/Nq9Jz/sh

$ xmodmap -pm
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        ISO_Next_Group (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
jordansissel commented 10 years ago

What version of xdotool?

rafi commented 10 years ago

xdotool version 2.20110530.1

jordansissel commented 10 years ago

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.

rafi commented 10 years ago

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

blueyed commented 9 years ago

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).

blueyed commented 9 years ago

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

emmanueld commented 7 years ago

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.

ghost commented 7 years ago

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.

alphapapa commented 6 years ago

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. :)

testman42 commented 5 years ago

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.

hvhaugwitz commented 5 years ago

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 '[ ]'
[ ]
blueyed commented 5 years ago

@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).

hvhaugwitz commented 5 years ago

@blueyed xkbmap is set to gb initially:

$ setxkbmap -query 
rules:      evdev
model:      pc105
layout:     gb
options:    compose:menu
hvhaugwitz commented 5 years ago

Any progress with this issue?

alphapapa commented 5 years ago

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.

testman42 commented 4 years ago

Any progress on this?

hvhaugwitz commented 4 years ago

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 '[ ]'
[ ]
kidmose commented 4 years ago

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

thyarles commented 4 years ago

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.

VictorQueiroz commented 3 years ago

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

blueyed commented 2 years ago

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.

francoisjacques commented 2 years ago

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?