Red Hat Bugzilla – Bug 463729
virt-manager does not release mouse pointer after gtk-vnc update
Last modified: 2013-04-21 13:59:25 EDT
Description of problem:
After the update to gtk-vnc-0.3.7-1.fc9.x86_64 the console window in virt-manager does not release the mouse pointer anymore when pressing "ctrl+alt".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open a running VM's console window in virt-manager
2. Click in the console to make the window grab your mouse pointer
3. Try to release your mouse pointer using the suggested "ctrl+alt" key combination
The window does not release the mouse pointer.
The mouse pointer is released when pressing "ctrl+alt".
I have same versions installed and it releases the mouse without problem. Please provide more information
- What keyboard layout are you using ?
- Does it have same results with both left and right-hand Alt keys ?
- What window manager ? Metacity or compiz ?
- Does the window manager have any magic shortcuts bound to a sequence involing Ctrl+Alt ?
- Does the same problem occur with 'virt-viewer' ?
(In reply to comment #1)
> - What keyboard layout are you using ?
$ cat /etc/sysconfig/keyboard
> - Does it have same results with both left and right-hand Alt keys ?
Yes, I get the same result. The right one is labeled "Alt Gr". Using the left or the right "Ctrl" key does not make a difference too.
> - What window manager ? Metacity or compiz ?
I did not change the default configuration.
> - Does the window manager have any magic shortcuts bound to a sequence
> involing Ctrl+Alt ?
It is all in default configuration as far as I can say. I checked all the window manager and keyboard related settings in GNOME and could not find anything suspect.
> - Does the same problem occur with 'virt-viewer' ?
Virt-viewer doesn't really grab the mouse pointer. The pointer is automatically free if it leaves the view area.
While testing virt-viewer I observed something really interesting:
1. Close virt-viewer and do not shutdown the virtual machine (its ID must *NOT* change)
2. Open virt-managers console window of this virtual machine
-> The console window now exactly behaves like virt-viewer and does not grab the mouse pointer!
3. Now shut down and then restart the virtual machine (its ID has to change)
-> The console window grabs the mouse pointer again and does not release it
Just want to add a 'me too' to the above comment. I'm seeing all the same behavior, no different config beyond the norm.
Situation is kind of interesting. I have a stock F9 kvm guest. While the guest is booting up (bios, service OK/FAIL listing), the mouse grabs and releases no problem. Once it boots to the sign in screen though, when their is actually a pointer in the guest to control, it immediately does not release the pointer.
Switching to a vt and kill virt-manager, and then going back to still running VM, it will now not grab the pointer, as described in the previous comment.
virt-viewer acts the same: once booting into the sign in screen, the mouse doesn't release.
let me know if there is any other info I can provide.
If you can reproduce with virt-viewer, then can you run virt-viewer with the --gtk-vnc-debug flag enabled & capture the output.
This must be somehow related to one of the VNC mouse mode extensions
Created attachment 317616 [details]
Log when pointer gets stuck
I start the domain, connect with virt-viewer, have it grab the mouse a couple times while it is starting up, move the pointer away from the viewer window while it boots. When the log in console is reached, I have the mouse get stuck as mention in the previous comments, switch to a vt and kill virt-viewer.
Created attachment 317618 [details]
Log when mouse won't grab
After killing virt-viewer in the previous steps, I reopen virt-viewer and click a few times (mouse doesn't stick) and type a few letters.
Ahh, excellant, those two traces show that when the cursor gets stuck, we've switched into relateive pointer mode. This explains why I've not been able to reproduce.
Created attachment 317679 [details]
Allow ungrab if pointer is grabbed
There was logic added in 0.3.7 which turned off the Ctrl+Alt grab/ungrab handling if running in absolute pointer mode.
While this was fine if you started up the VNC client and it was already in absolute mode, it was broken if the server transitioned from relative to absolute mode while the pointer was already grabbed.
The fix is to always allow the ungrab sequence to be processed if holding an active grab.
gtk-vnc-0.3.7-2.fc9 has been submitted as an update for Fedora 9.
Okay, I confirmed that 0.3.7-2 fixes the issue, however there is another bug I'm hitting now (less severe though).
As guest is starting up, I can grab and release pointer no problem (as stated in previous comments.) Once the log in screen is reached though, I can only grab and release the pointer _once_. After that, the pointer will not grab again. Same for both virt-manager and virt-viewer.
I thing that is probably the correct behaviour.
If you run with gtk-vnc debugging enabled, you should see it start out with a message
(virt-viewer:1917): gtk-vnc-DEBUG: FramebufferUpdate(-257, 0, 0, 720, 400)
which indicates it is in relative mouse motion mode. When in relative mode, we allow mouse pointer grabbing because this is neccessary to get correct motion tracking with relative pointers.
I suspect that you will later be seeing a
(virt-viewer:1917): gtk-vnc-DEBUG: FramebufferUpdate(-257, 1, 0, 720, 400)
indicating that it has switched to absolute pointer mode. When this happens, host + guest pointers are all running absolute mode, so there is 1:1 motion tracking, and thus mouse pointer grabs are no longer required. Hence we disable them.
The patch was to allow ungrabs only, if we switched from relative to absolute mode while a grab was active. Once in absolute mode no more pointer grabbing is done.
I just installed gtk-vnc-0.3.7-2.fc9 for x86_64 from koji. Works great. Less annoying. :-)
gtk-vnc-0.3.7-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 659363 [details]