1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
assembly: 0.975
semantic: 0.974
graphic: 0.968
device: 0.967
other: 0.967
instruction: 0.966
vnc: 0.962
boot: 0.957
mistranslation: 0.951
KVM: 0.946
socket: 0.946
network: 0.944
qemu 1.4.2: usb keyboard not fully working
When using the usb keyboard, I can't type the | character. I'm using german keyboard layout (de) on the host and inside the guest. As a guest OS, I use Linux (e.g. a recent KNOPPIX cd). To obtain the | character on a german keyboard, I need to press AltGr + the < or > key, i.e. the key right to the left shift.
The qemu command line is something like this:
./qemu-system-i386 -device pci-ohci -device usb-kbd
I also tried
./qemu-system-i386 -usb -usbdevice keyboard
with the same effect.
Actually, the whole < > | key doesn't work. It's just dead. I can't type any of those characters.
Any comment? The <>| key is still not working in qemu 1.4.2.
Affects as well Win8.1 as Host System and Debian as Client, tested with latest qemu 2.1.50 (fetched from git).
Debian : 3.2.0-4-vexpress #1 SMP Debian 3.2.57-3 armv71
with startup parameters :
h:\qemu\test\qemu-system-armw" -M vexpress-a9 -kernel vmlinuz-3.2.0-4-vexpress -initrd initrd.img-3.2.0-4-vexpress -append "root=/dev/mmcblk0p2" -drive if=sd,cache=unsafe,file=hda.img -redir tcp:6666::8080 -k de
Any key combined with AltGr doesn't work in Linux clients, which is @|}{ etc. on german keyboards.
setxkb and locale is set to german keyboard.
Testing the same Debian virtual machine under Ubuntu Linux 14.10 with same qemu 2.1.50 compiled from latest git as of today, AltGr key combinations just work fine.
On Windows host showkey in Debian client outputs when trying to press AltGr + < to obtain "|" two times :
Keycode 28 released
Keycode 29 pressed
Keycode 56 pressed
Keycode 86 pressed
Keycode 86 released
Keycode 29 released
Keycode 56 released
Keycode 29 pressed
Keycode 56 pressed
Keycode 86 pressed
Keycode 86 released
Keycode 29 released
Keycode 56 released
Entering the same key combo in QEmu monitor just seems to be working fine, resulting in "|" output in the monitor.
Using sendkey in monitor "sendkey ctrl-alt-<" results in :
Keycode 28 released
Keycode 29 pressed
Keycode 56 pressed
Keycode 86 pressed
Keycode 29 released
Keycode 56 released
Keycode 86 released
However, this also results in no "|" Symbol being printed on Debian console.
Thus, issue seems to affect just Windows Hosts using Linux clients such as Debian. Any ideas, maybe wrong keycodes ?
Additional :
Running the same debian virtual machine under Linux host where "AltGr+<" in order to get "|" on german keyboard seems to work properly, I get the following result running sendkey in console :
Keycode 28 released;
Keycode 100 pressed;
Keycode 86 pressed;
Keycode 86 released;
Keycode 100 released;
Keycode 100 pressed;
Keycode 86 pressed;
Keycode 86 released;
Keycode 100 released;
As you can clearly see, as on Windows host Keycode for Altgr being sent is "29 + 56" whereas it clearly should be sending Keycode "100" instead in order to work properly.
xev log using ubuntu host and debian virtual machine for pressing altgr + < key to obtain "|" using german layout :
KeyPress event, serial 43, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 4278157, (165,-105), root:(446,164),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 46, synthetic NO, window 0x1600001,
root 0x43, subw 0x0, time 4278365, (165,-105), root:(446,164),
state 0x80, keycode 94 (keysym 0x7c, bar), same_screen YES,
XLookupString gives 1 bytes: (7c) "|"
XmbLookupString gives 1 bytes: (7c) "|"
XFilterEvent returns: False
After some digging, it seems that windows itself is responsible for that bug. On international keyboards, it tend to send "Ctrl" and "Alt" instead of "AltGr" keycode.
A possible patch would be to add an option to QEMU command line to handle Ctrl and Alt keystrokes being pressed at the same time as AltGr keystroke.
Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
I am testing the qemu windows version from:
https://qemu.weilnetz.de/w64/qemu-w64-setup-20180519.exe
And AltGr does not work at all.
Another issue is that it seems that Spanish keyboard layout has been changed and in my Spanish (from Spain -Europe-) does not work fine. Maybe the layout has been changed into Spanish Latin layout. I think that two diferent layouts are needed.
Looks like people report different issues here... if you report a keyboard mapping problem, please try to either make sure that it matches the bug, or open a new ticket.
So the original problem (with the < > | not working at all) seems to be fixed nowadays, at least it works for me with a Linux guest running on a Linux host.
But I'll leave this ticket opened for the Windows problems that have been reported.
José, could you please add the information about your guest? Are you running Linux or Windows in QEMU?
Hi, Thomas,
Thanks for your answer.
The mapping keyboard problem happens only from latests versions of qemu for windows. December one, was correct.
My host system is windows 10 and my guest system is an Spanish (Spain -Europe-) msdos 5.0.
But if I boot whithout any system (network booting), the altgr problem still remains.
Thanks for your answer.
With a freshly compiled version of qemu 4.0.50
on Widows 10 (host)
I am using 3 different Belgian keyboards and I have the same behaviour
- 2 USB keyboards (Logitech and HP) and
- the keyboard of my laptop (HP)
3 characters on the same key cannot be used (the key seams to be dead):
< (less than),
> (greater than) used with the combination of LShift or RShift
\ (backslash) used with the combination of AltGr
Using grub command mode from an archlinux installation (5.1.4)
The keyboard seams to be a mix of azerty and qwerty keyboard
all letters are correctly mapped but all numbers and special
characters are not
Using sendkey in monitor
"sendkey <" results in : \
"sendkey shift-<" results in : |
"sendkey ctrl-alt-<" results in : nothing
REM: VirtualBox can handle this key and with the showkey command
from the archlinux kbd package, it shows :
keycode 86 press
keycode 86 release
Same issue with the qemu version 4.1.0
Host: Windows 10
Guest: Archlinux 5.0.10
showkey output :
keycode 100 # Alt Gr
keycode 29 # Left Control
keycode 97 # Right Contol
keycode 56 # Left Alt
no output # '> < \' key, should be 86
If I change the keyboard layout on the Host (Windows 10), showkey reports different keycode:
Keyboard layout Belgian (Comma) AZERTY
key 'A' keycode 30 (VirtualBox reports keycode 16)
Keyboard layout US QWERTY
key 'A' keycode 16
With qemu version 2.9.94
Host: Windows 10
Guest: Archlinux 5.0.10
showkey output :
keycode 56 press # Alt Gr
keycode 29 release # Alt Gr
keycode 56 release # Alt Gr
keycode 29 press # Left Control
keycode 29 release # Left Control
keycode 29 press # Right Contol
keycode 29 release # Right Contol
keycode 56 press # Left Alt
keycode 56 release # Left Alt
keycode 86 press # '> < \' key
keycode 86 release # '> < \' key
As you can see the key 'Alt Gr' is not correctly mapped, it should return 100
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/93
|