Bug#758881: [bisected] VNC server can't get all sent chars correctly
On Di, 2014-08-26 at 09:55 +0400, Michael Tokarev wrote: 26.08.2014 09:40, Gerd Hoffmann wrote: There should be a delay after every character. It can be pretty small. 10ms should be enough (you should set TCP_NODELAY though to make sure the key events are not buffered in the network stack). Is this delay qemu-specific (or, rather, virtualization-specific, so to say, when the target - the VNC server - is working with a hardware being emulated), or applies to all VNC servers equally? Dunno, didn't try. Maybe you can hit it with xvnc too. But I'd expect that software (xvnc) has larger buffers than (emulated) hardware, so it doesn't trigger that easily. cheers, Gerd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: [bisected] VNC server can't get all sent chars correctly
On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote: There's a bug filed against debian qemu package, there: http://bugs.debian.org/758881 which says about problems sending keypress events over VNC to a qemu guest, -- some keypresses gets lost, at least. So it looks like something else is not right here. Before this patch, it wasn't possible to use keyboard with VNC client with redhat 5 guest. Now, it isn't possible to use keyboard with VNC in another scenario which worked before (so it is a regression compared with 2.0 version). qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being 16 bytes instead of 256, matching real hardware). That may trip up software depending on old, broken behavior. IMO vncdotool should be fixed to add small delays between keyboard events, as if a real person is typing, instead of sending the key events at the maximum possible speed. I'm sure you can hit the issue with qemu 2.0 too, you just need longer user input strings to trigger it, so it is less likely to happen. cheers, Gerd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: [bisected] VNC server can't get all sent chars correctly
[ CC'ing Marc Sibson, vncdotool developer ] Hi Marc, thread starts at http://thread.gmane.org/gmane.comp.emulators.qemu/292614 On Mon, Aug 25, 2014 at 11:37 AM, Gerd Hoffmann kra...@redhat.com wrote: On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote: There's a bug filed against debian qemu package, there: http://bugs.debian.org/758881 which says about problems sending keypress events over VNC to a qemu guest, -- some keypresses gets lost, at least. So it looks like something else is not right here. Before this patch, it wasn't possible to use keyboard with VNC client with redhat 5 guest. Now, it isn't possible to use keyboard with VNC in another scenario which worked before (so it is a regression compared with 2.0 version). qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being 16 bytes instead of 256, matching real hardware). That may trip up software depending on old, broken behavior. IMO vncdotool should be fixed to add small delays between keyboard events, as if a real person is typing, instead of sending the key events at the maximum possible speed. I'm sure you can hit the issue with qemu 2.0 too, you just need longer user input strings to trigger it, so it is less likely to happen. I do confirm some chars don't get received with qemu 2.0 as well, e.g. by sending insecureinsecure: received string is ecure, first 11 missing. Thanks, -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: [bisected] VNC server can't get all sent chars correctly
Hi, On August 25, 2014 at 3:40:01 AM, Gabriele Giacone (1o5g4...@gmail.com) wrote: IMO vncdotool should be fixed to add small delays between keyboard events, as if a real person is typing, instead of sending the key events at the maximum possible speed. vncdotool does have a —delay=MILLISECONDS switch that inserts a delay between commands. Currently, the two behaviours causing trouble seem to be that delay defaults to 0 and type insecure” is considered one command, so there is no delay between key presses :( Is there a non-zero value for —delay that makes sense? I’m somewhat hesitant to change —delay as it would be a behavioural change for other users, but if the value is sufficiently small it could be a net usability gain. Are you requesting that the type command be fixed to insert delays after every character or that default for —delay should be non-zero? -- Marc
Bug#758881: [bisected] VNC server can't get all sent chars correctly
On Mo, 2014-08-25 at 21:11 -0700, Marc wrote: Hi, On August 25, 2014 at 3:40:01 AM, Gabriele Giacone (1o5g4...@gmail.com) wrote: IMO vncdotool should be fixed to add small delays between keyboard events, as if a real person is typing, instead of sending the key events at the maximum possible speed. vncdotool does have a —delay=MILLISECONDS switch that inserts a delay between commands. Currently, the two behaviours causing trouble seem to be that delay defaults to 0 and type insecure” is considered one command, so there is no delay between key presses :( Is there a non-zero value for —delay that makes sense? I’m somewhat hesitant to change —delay as it would be a behavioural change for other users, but if the value is sufficiently small it could be a net usability gain. Are you requesting that the type command be fixed to insert delays after every character or that default for —delay should be non-zero? There should be a delay after every character. It can be pretty small. 10ms should be enough (you should set TCP_NODELAY though to make sure the key events are not buffered in the network stack). I guess it makes sense to decouple that from the delay between commands as the time a qemu guest needs to process a command can be much higher than the time it needs to process a key event. cheers, Gerd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: [bisected] VNC server can't get all sent chars correctly
26.08.2014 09:40, Gerd Hoffmann wrote: There should be a delay after every character. It can be pretty small. 10ms should be enough (you should set TCP_NODELAY though to make sure the key events are not buffered in the network stack). Is this delay qemu-specific (or, rather, virtualization-specific, so to say, when the target - the VNC server - is working with a hardware being emulated), or applies to all VNC servers equally? /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: [bisected] VNC server can't get all sent chars correctly
Hi, From: Michael Tokarev [mailto:m...@tls.msk.ru] Sent: Saturday, August 23, 2014 4:56 PM To: qemu-devel Cc: Gerd Hoffmann; Gonglei (Arei); 758...@bugs.debian.org; Gabriele Giacone Subject: [bisected] VNC server can't get all sent chars correctly There's a bug filed against debian qemu package, there: http://bugs.debian.org/758881 which says about problems sending keypress events over VNC to a qemu guest, -- some keypresses gets lost, at least. The bisection between qemu 2.0 and 2.1 leads to this commit: commit 2858ab09e6f708e381fc1a1cc87e747a690c4884 Author: Gonglei arei.gong...@huawei.com Date: Thu Apr 24 20:06:19 2014 +0800 ps2: set ps/2 output buffer size as the same as kernel According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer size is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the very beginning. When I started a redhat5.6 32bit guest, meanwhile tapped the keyboard as quickly as possible, the screen would show me i8042.c: No controller found. As a result, I couldn't use the keyboard in the VNC client. Previous discussion about the issue in maillist: http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180 This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests. More easy meathod to reproduce: 1.boot a guest with libvirt. 2.connect to VNC client. 3.as you see the BIOS, bootloader, Linux booting, run the follow simply shell script: for((i=0;i1000;i++)) do virsh send-key redhat5.6 KEY_A; done Actual results: dmesg show i8042.c: No controller found. And the keyboard is out of work. Signed-off-by: Gonglei arei.gong...@huawei.com Reviewed-by: Juan Quintela quint...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com So it looks like something else is not right here. Before this patch, it wasn't possible to use keyboard with VNC client with redhat 5 guest. Now, it isn't possible to use keyboard with VNC in another scenario which worked before (so it is a regression compared with 2.0 version). What do we do with this? :) I tested the same command line with the reported Bug, as below: ./qemu-system-x86_64 -vnc :10 -enable-kvm -cpu host -m 1024 --kernel \ /home/linux --initrd /home/initrd.gz --append locale=en_US keymap=us \ video=vesa:ywrap,mtrr vga=788 And the VNC client I tested are TightVNC and RealVNC. But I could not reproduce this issue. So, I think maybe vncdotool client once send too many characters (and ps2 queue length PS2_QUEUE_SIZE), which leading to some characters are discarded by QEMU. More test cases will be useful IMHO. Best regards, -Gonglei
Bug#758881: [bisected] VNC server can't get all sent chars correctly
There's a bug filed against debian qemu package, there: http://bugs.debian.org/758881 which says about problems sending keypress events over VNC to a qemu guest, -- some keypresses gets lost, at least. The bisection between qemu 2.0 and 2.1 leads to this commit: commit 2858ab09e6f708e381fc1a1cc87e747a690c4884 Author: Gonglei arei.gong...@huawei.com Date: Thu Apr 24 20:06:19 2014 +0800 ps2: set ps/2 output buffer size as the same as kernel According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer size is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the very beginning. When I started a redhat5.6 32bit guest, meanwhile tapped the keyboard as quickly as possible, the screen would show me i8042.c: No controller found. As a result, I couldn't use the keyboard in the VNC client. Previous discussion about the issue in maillist: http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180 This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests. More easy meathod to reproduce: 1.boot a guest with libvirt. 2.connect to VNC client. 3.as you see the BIOS, bootloader, Linux booting, run the follow simply shell script: for((i=0;i1000;i++)) do virsh send-key redhat5.6 KEY_A; done Actual results: dmesg show i8042.c: No controller found. And the keyboard is out of work. Signed-off-by: Gonglei arei.gong...@huawei.com Reviewed-by: Juan Quintela quint...@redhat.com Signed-off-by: Gerd Hoffmann kra...@redhat.com So it looks like something else is not right here. Before this patch, it wasn't possible to use keyboard with VNC client with redhat 5 guest. Now, it isn't possible to use keyboard with VNC in another scenario which worked before (so it is a regression compared with 2.0 version). What do we do with this? :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
