Bug 754409

Summary: Local mouse looses sync in full screen when the client resolution is higher then the VMs
Product: Red Hat Enterprise Linux 8 Reporter: Simon Grinberg <sgrinber>
Component: spice-vdagent-winAssignee: Arnon Gilboa <agilboa>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: ---CC: acathrow, dblechte, pvine
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-15 15:15:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Simon Grinberg 2011-11-16 12:10:43 UTC 
Description of problem:

This happens on two monitors client machine. The mouse pointer is not aligned to the actual mouse location in the VM. And when getting to the right most corner of the screen it gets stack there.

To release it, they have too actually deactivate and reactivate the monitor in the guest using Keyboard

The only solution for them is to matches monitor resolution to the
guest resolution.

All guest tools installed
 
How reproducible:
The customer has 2 monitors of 1920x1200 but the guest is 1920x1080 as this is the max resolution configured for the spice driver. Under this configuration it always happens.



Expected results:
Mouse pointer to be placed on the right location in the VM
Please verify on 3.0 and fix if this is not the case.

Additional info:
The customer also have a third monitor on the client machines of 1280x1924 that is not used by Spice, but that does not seem related to the issue, as when setting the other two to the client resolution everything works well.
Comment 1 David Blechter 2011-12-15 15:03:04 UTC 
devel nack it:
1. the description does not include any versions, platforms, components, etc 
2. bug was found in 2.2.10 and is proposed to the 3.0 z-stream, and violate the z-stream cloning/approval process
Comment 2 RHEL Program Management 2011-12-15 15:15:18 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.