Bug 920822

Summary: RFE: virt-viewer does not release the cursor during guest shutdown
Product: Red Hat Enterprise Virtualization Manager Reporter: Bryan Yount <byount>
Component: mingw-virt-viewerAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.2CC: acathrow, cfergeau, dblechte, dyasny, marcandre.lureau
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-23 00:31:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bryan Yount 2013-03-12 20:56:36 UTC
Description of problem:
When the user clicks powers down or reboots a Windows guest, the cursor is not released from virt-viewer. The user is required to wait until the VM fully powers down or they have to press SHIFT + F12.

Version-Release number of selected component (if applicable):
RHEV-toolsSetup_3.1_9
vdservice.exe (1.1.0.10012)

How reproducible:
Very

Steps to Reproduce:
1. Connect to a Windows 7 guest
2. Click Shutdown/reboot in the guest
  
Actual results:
The mouse cursor is grabbed by virt-viewer and the user is required to wait until guest fully shuts down or until the user presses SHIFT+F12.

Expected results:
The mouse should auto-release from virt-viewer

Additional info:
This behavior did not seem to happen on a RHEL 6.4 guest, so it seems to be confined to the windows vdagent.

Comment 2 Arnon Gilboa 2013-03-13 10:49:49 UTC
Bryan, IMHO it has nothing to do with vdagent, but virt-viewer. On shutdown or reboot of the guest, vdagent closes virtio-serial which causes virt-viewer (via message from server) to switch from "client mouse" to "server mouse" (captured) mode. Please change component accordingly.

Comment 3 Marc-Andre Lureau 2013-03-13 12:40:58 UTC
(In reply to comment #0)
> Steps to Reproduce:
> 1. Connect to a Windows 7 guest
> 2. Click Shutdown/reboot in the guest
>   
> Actual results:
> The mouse cursor is grabbed by virt-viewer and the user is required to wait
> until guest fully shuts down or until the user presses SHIFT+F12.

This is normal behaviour, when the agent goes away, the mouse is grabbed in "server mode" (unless you have qxl & usb tablet iirc)

I am not sure auto-grabbing is the most sensible thing to do, but not grabbing would be equally anoying (ex: stop agent would release the grab, so mouse would be "frozen" until you click/grab again).

> Expected results:
> The mouse should auto-release from virt-viewer

If the agent would be around longer during shutdown, it wouldn't be visible, or it would be as visible as RHEL guest.

Comment 4 Arnon Gilboa 2013-03-13 12:59:01 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > Steps to Reproduce:
> > 1. Connect to a Windows 7 guest
> > 2. Click Shutdown/reboot in the guest
> >   
> > Actual results:
> > The mouse cursor is grabbed by virt-viewer and the user is required to wait
> > until guest fully shuts down or until the user presses SHIFT+F12.
> 
> This is normal behaviour, when the agent goes away, the mouse is grabbed in
> "server mode" (unless you have qxl & usb tablet iirc)
> 
> I am not sure auto-grabbing is the most sensible thing to do, but not
> grabbing would be equally anoying (ex: stop agent would release the grab, so
> mouse would be "frozen" until you click/grab again).

Mouse won't be "frozen", but simply ungrabbed and free for use outside of virt-viewer, which seems ok for me, but PM can advise us here.

> 
> > Expected results:
> > The mouse should auto-release from virt-viewer
> 
> If the agent would be around longer during shutdown, it wouldn't be visible,
> or it would be as visible as RHEL guest.

It can't be around longer, as it's unusable & invisible during the shutdown screen even in desktop windows. It also cannot be emulated by vdagent in this stage.

I think this BZ should move to virt-viewer (as RFE?).

Comment 5 Bryan Yount 2013-03-14 00:38:16 UTC
(In reply to comment #2)
> Bryan, IMHO it has nothing to do with vdagent, but virt-viewer. On shutdown
> or reboot of the guest, vdagent closes virtio-serial which causes
> virt-viewer (via message from server) to switch from "client mouse" to
> "server mouse" (captured) mode. Please change component accordingly.

Yeah sorry about that. We weren't sure what component this fit. We thought maybe it could be rhev-agent needs to tell virt-viewer to release the cursor or, as you're saying, this is expected virt-viewer behavior so maybe we do need to move the component. Can I leave this up to you since I don't know where in the code this is defined?

(In reply to comment #3)
> This is normal behaviour, when the agent goes away, the mouse is grabbed in
> "server mode" (unless you have qxl & usb tablet iirc)
> 
> I am not sure auto-grabbing is the most sensible thing to do, but not
> grabbing would be equally anoying (ex: stop agent would release the grab, so
> mouse would be "frozen" until you click/grab again).

Well, I would imagine that if vdagent stops, the user probably shut down the VM or the service and we should release the mouse cursor. The user can click back inside the Window if they really want. I think the shutdown scenario, and thus the user wants the mouse cursor back on their client, happens way more often than the user wanting the cursor to stay grabbed, right?

> If the agent would be around longer during shutdown, it wouldn't be visible,
> or it would be as visible as RHEL guest.

I think we just need to change the default behavior to "release mouse if vdagent is shut down or dies". As long as the virt-viewer window is still in focus, the user's keystrokes enter into the guest.

Comment 6 Arnon Gilboa 2013-03-21 09:12:32 UTC
Set as RFE, updated component and summary, as it has nothing to do with vdagent.

Comment 7 Marc-Andre Lureau 2013-03-21 11:05:15 UTC
See also related bug #830760, which I am tempted to close as duplicate.

Comment 8 Marc-Andre Lureau 2013-03-23 00:31:10 UTC

*** This bug has been marked as a duplicate of bug 830760 ***

Comment 9 Marc-Andre Lureau 2013-03-25 14:48:29 UTC
fyi

bug 830760 is original bug, where discussion and solution should take place.  
bug 873272 is the mingw duplicate.