Bug 463729 - virt-manager does not release mouse pointer after gtk-vnc update
virt-manager does not release mouse pointer after gtk-vnc update
Product: Fedora
Classification: Fedora
Component: gtk-vnc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-24 06:15 EDT by Torsten Rausche
Modified: 2013-04-21 13:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-28 14:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Log when pointer gets stuck (2.45 MB, text/plain)
2008-09-24 15:53 EDT, Cole Robinson
no flags Details
Log when mouse won't grab (23.80 KB, text/plain)
2008-09-24 15:55 EDT, Cole Robinson
no flags Details
Allow ungrab if pointer is grabbed (635 bytes, patch)
2008-09-25 08:06 EDT, Daniel Berrange
no flags Details | Diff
new patch (466.39 KB, patch)
2012-12-07 08:17 EST, mccartney su
no flags Details | Diff

  None (edit)
Description Torsten Rausche 2008-09-24 06:15:57 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):

How reproducible:

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
Actual results:
The window does not release the mouse pointer.

Expected results:
The mouse pointer is released when pressing "ctrl+alt".
Comment 1 Daniel Berrange 2008-09-24 06:25:14 EDT
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' ?
Comment 2 Torsten Rausche 2008-09-24 08:10:05 EDT
(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
Comment 3 Cole Robinson 2008-09-24 14:15:49 EDT
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.
Comment 4 Daniel Berrange 2008-09-24 15:36:34 EDT
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
Comment 5 Cole Robinson 2008-09-24 15:53:49 EDT
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.
Comment 6 Cole Robinson 2008-09-24 15:55:00 EDT
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.
Comment 7 Daniel Berrange 2008-09-25 05:52:37 EDT
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.
Comment 8 Daniel Berrange 2008-09-25 08:06:09 EDT
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.
Comment 9 Fedora Update System 2008-09-25 08:44:26 EDT
gtk-vnc-0.3.7-2.fc9 has been submitted as an update for Fedora 9.
Comment 10 Cole Robinson 2008-09-25 09:35:39 EDT
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.
Comment 11 Daniel Berrange 2008-09-25 09:48:37 EDT
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.
Comment 12 Jerry Amundson 2008-09-26 12:39:57 EDT
I just installed gtk-vnc-0.3.7-2.fc9 for x86_64 from koji. Works great. Less annoying. :-)
Comment 13 Fedora Update System 2008-09-28 14:39:11 EDT
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.
Comment 14 mccartney su 2012-12-07 08:17:38 EST
Created attachment 659363 [details]
new patch

Note You need to log in before you can comment on or make changes to this bug.