Bug 785963
Summary: | keys left pressed on the vncserver when closing the connection | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | daiwei <wdai> |
Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.3 | CC: | acathrow, bsarathy, flang, juzhang, michen, minovotn, mkenneth, pbonzini, shuang, tburke, virt-maint |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-0.12.1.2-2.258.el6 | Doc Type: | Bug Fix |
Doc Text: |
Cause: keys that were pressed when a VNC connection was closed were treated as pressed when the next VNC connection was opened.
Consequence: after closing a VNC viewer with Alt+F4, the next connection would treat all keys as modified by Alt, until the Alt key was pressed and depressed again.
Fix: QEMU will inject key-released events for all keys that were pressed at the time the VNC client disconnected
Resolution: when closing a VNC viewer with Alt+F4, QEMU will inject a key-released event for Alt, so that the next connection will see a clean state.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-20 11:38:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
daiwei
2012-01-31 03:05:14 UTC
It seems like a problem in your setup. I tested it on F16 and it worked nicely. The only exception to that is whether you caught the guest in a very specific transition and I doubt it happened. Hi,Dor Do you mean your vnc client is on F16 then to connect a kvm guest? I also tested on F16 with vnc client:tigervnc-1.1.0-3.fc16.x86_64,always encounter this problem. After step 4,I can't type anything into vnc client even after waiting for a long time( > 1 hour). Any mistake,please correct me and free to close this issue. Change bug status from closed to assigned in order to request needinfo Can you request another QE person to re-test this on a different setup to validate the issue? Hi,Dor Juzhang and Xiaomei Gao helped me to reproduce this bug,both of them can reproduce. Click shutdown button to close vnc client not have this problem. Both Gleb and I managed to reproduce the issue (each separably). We see slightly different issue where after we close the vncclient w/ alt-f4 we can connect to it again but it seems that the vnc server in qemu has a mouse button or shift pressed and you can't operate the keyboard mouse well. Daiwei, cheers for insisting on this! The above problem is caused because the 'alt' key remains pressed on the vncserver side. Once you reconnect w/ a new vnc-client, if you 'play' a lot w/ the 'alt' key, it gets back to normal. I guess it is any key, not just alt, it is just that alt has a very noticable effect ;) Workaround is easy: just tap alt once and things return to normal. Fix most likely is easy too, qemu already keeps track of pressed keys, we just have to eject key-up events into the guest on vnc disconnect. (In reply to comment #9) > I guess it is any key, not just alt, it is just that alt has a very > noticable effect ;) > > Workaround is easy: just tap alt once and things return to normal. > Fix most likely is easy too, qemu already keeps track of pressed keys, > we just have to eject key-up events into the guest on vnc disconnect. Yonit said that spice resets all the special keys on client disconnect. Seems like vnc should do the same http://brewweb.devel.redhat.com/brew/taskinfo?taskID=4053507 patches posted. reporduce this issue with steps and environment as follows: #uname -r 2.6.32-257.el6.x86_64 #rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.256.el6.x86_64 steps: 1)boot guest with vnc /usr/libexec/qemu-kvm -m 2G -smp 1 -cpu Penryn,+x2apic, -usbdevice tablet -drive file=/mnt/RHEL-Server-6.3-64-virtio.qcow2-newinstall5,format=qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=00:10:20:2d:31:21,bus=pci.0,addr=0x4,id=net0 -boot order=cdn,once=n,menu=on -uuid 043b28a2-f400-4538-9d29-c30588a08709 -rtc base=utc,clock=host,driftfix=slew -no-kvm-pit-reinjection -monitor stdio -name rhel6.1 -vnc :10 -device virtio-balloon-pci,bus=pci.0,id=balloon0 2) after login guest run some operation in guest ,guest can be work normally 3)close vncviewer by press hotkey "Alt+F4" 4)relogin guest by vncviewer results: can't type anything into vnc client,vncviewer become to no-response. verify this issue with steps and environment as follows: #uname -r 2.6.32-257.el6.x86_64 #rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.262.el6.x86_64 steps: the same as reproduce results: vncviewer work well.so the issue has been fixed. Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No Documentation Needed Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1,7 @@ -No Documentation Needed+Cause: keys that were pressed when a VNC connection was closed were treated as pressed when the next VNC connection was opened. + +Consequence: after closing a VNC viewer with Alt+F4, the next connection would treat all keys as modified by Alt, until the Alt key was pressed and depressed again. + +Fix: QEMU will inject key-released events for all keys that were pressed at the time the VNC client disconnected + +Resolution: when closing a VNC viewer with Alt+F4, QEMU will inject a key-released event for Alt, so that the next connection will see a clean state. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0746.html |