1 files changed, 223 insertions, 0 deletions
diff --git a/results/classifier/108/all/1101210 b/results/classifier/108/all/1101210
new file mode 100644
index 00000000..b948b9ad
--- /dev/null
+++ b/results/classifier/108/all/1101210
@@ -0,0 +1,223 @@
+semantic: 0.974
+performance: 0.972
+graphic: 0.968
+device: 0.967
+PID: 0.967
+other: 0.967
+debug: 0.967
+permissions: 0.963
+vnc: 0.962
+boot: 0.957
+files: 0.957
+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
+
+