1 files changed, 102 insertions, 0 deletions
diff --git a/results/classifier/118/debug/1688231 b/results/classifier/118/debug/1688231
new file mode 100644
index 000000000..2d2ce6a30
--- /dev/null
+++ b/results/classifier/118/debug/1688231
@@ -0,0 +1,102 @@
+user-level: 0.973
+debug: 0.949
+boot: 0.941
+architecture: 0.916
+performance: 0.916
+PID: 0.915
+register: 0.911
+graphic: 0.908
+kernel: 0.906
+device: 0.902
+permissions: 0.901
+assembly: 0.896
+semantic: 0.892
+socket: 0.876
+hypervisor: 0.869
+mistranslation: 0.852
+peripherals: 0.848
+risc-v: 0.848
+arm: 0.845
+ppc: 0.843
+virtual: 0.839
+vnc: 0.826
+network: 0.821
+TCG: 0.814
+KVM: 0.814
+x86: 0.798
+VMM: 0.776
+files: 0.763
+i386: 0.704
+
+[Qemu-ppc] sendkey is not working for any of the keystrokes
+
+sendkey option is not working for any of the keystrokes in ppc64le,
+
+Qemu version:
+# qemu-img --version
+qemu-img version 2.9.50 (v2.9.0-303-g81b2d5c-dirty)
+
+Qemu command line:
+# qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 4G,slots=32,maxmem=32G -smp 16,maxcpus=32 -device virtio-blk-pci,drive=rootdisk -drive file=/var/lib/libvirt/images/f25-upstream-ppc64le.qcow2,if=none,cache=none,format=qcow2,id=rootdisk -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -redir tcp:2000::22
+
+Guest booted successfully and logged in
+Fedora 25 (Twenty Five)
+Kernel 4.11.0-rc4 on an ppc64le (hvc0)
+
+atest-guest login: updatedb (5582) used greatest stack depth: 9568 bytes left
+root
+Password: 
+Last login: Mon Mar 27 01:57:51 on hvc0
+[root@atest-guest ~]# 
+
+Qemu monitor:
+# telnet 127.0.0.1 1234
+Trying 127.0.0.1...
+Connected to 127.0.0.1.
+Escape character is '^]'.
+QEMU 2.9.50 monitor - type 'help' for more information
+(qemu) sendkey a
+(qemu) sendkey ret
+
+But from the console, I couldn't observe the keystroke a or return.
+
+I see this happening in ppc64le and x86_64 with QEMU v2.11.0-1684-ga6e0344fa0. The keystrokes are being sent to tty1:
+
+in x86_64:
+
+./v2.11.0-1684-ga6e0344fa0/bin/qemu-system-x86_64 -enable-kvm -m 512 -kernel vmlinuz -initrd initramfs.img -chardev serial,id=s1,path=/dev/pts/10 -mon chardev=s1 -qmp tcp:localhost:4444,server,nowait -vga none -nographic -append "console=ttyS0 i8042.debug"
+
+QEMU 2.11.50 monitor - type 'help' for more information                    
+(qemu) sendkey a
+(qemu) sendkey b
+(qemu) sendkey c
+(qemu) sendkey ret
+
+# cat /dev/tty1
+abc
+
+---
+same thing with input-send-event:
+
+{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "a" } } }]}
+{"events": [{ "type": "key", "data" : { "down": true, "key": {"type": "qcode", "data": "ret" } } }]}
+
+# cat /dev/tty1
+abc
+a
+
+
+I'm not sure what is the expected behavior when using two input sources in this way (serial line + PS/2 keyboard). I'm inclined to say that the keys should indeed not be seen in the serial console.
+
+Yes, you are right: sendkey does not send keys to the serial console. I had a chat with Peter last year about it in the IRC where the explained:
+
+<danielhb> hey! quick question: is the 'sendkey' monitor command supposed to send the key presses to the serial console of the guest when running with -nographics ? The command works fine with VGA/VNC graphics but the serial console doesn't show the character key being sent by the command
+<pm215> no, 'sendkey' sends a key to whatever physical keyboard is currently being emulated, regardless of what is being done with serial devices
+<danielhb> pm215, I 've debugged the code and saw that the scancodes are being sent to the emulated keyboard via sendkey. I just wondered why the serial console doesn't show the keysyms but the VGA does
+<pm215> because keyboards don't plug into serial terminals
+<pm215> this is like having a server with a PC keyboard plugged into it and also a serial port which you're using as the serial terminal
+<pm215> pressing a key on the PC keyboard doesn't do anything to the serial terminal
+<danielhb> pm215, that makes sense, haven't thought of  that. thanks!
+
+Given that the bug report was created around a wrong assumption, this should be closed.
+