Bug 223805

*** Bug 223804 has been marked as a duplicate of this bug. ***

The fix is in virt-manager 0.2.6-7.0.1.el5:

* Fri Feb 23 2007 Daniel P. Berrange <berrange> - 0.2.6-7.0.1.el5
- Grab cursor & hide local mouse in console window

And built into RHEL-5.0  Z-stream:

$ brew latest-pkg RHEL-5.0-Z-candidate virt-manager
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
virt-manager-0.2.6-7.0.1.el5              RHEL-5.0-Z-candidate  berrange

There was an issue wrt to handling the ungrab key sequence in the previous
build, so I've done a 2nd candidate build, version 0.2.6-7.0.2.el5:

* Tue Feb 27 2007 Daniel P. Berrange <berrange> - 0.2.6-7.0.2.el5
- Implement alternate approach to processing ungrab key sequence

$ brew latest-pkg RHEL-5.0-Z-candidate virt-manager
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
virt-manager-0.2.6-7.0.2.el5              RHEL-5.0-Z-candidate  berrange

verified using testing notes in errata advisory 2007:0114

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0112.html

*** Bug 216030 has been marked as a duplicate of this bug. ***

Upon the comment by RH Engineering, I'll close this ticket.
Regards,

Internal Status set to 'Resolved'
Status set to: Closed by Tech

This event sent from IssueTracker by mmatsuya 
 issue 107357

Given the following comment that I recieved from Dan Ottey I am closing
this issue. 

"They did change the mouse behavior with the upgraded software and it was
a great improvement.  It works similar to vmware where they lock the mouse
to a specific window and you have to enter a ctl xxx command to go outside
the window."

Sharon Lightcap

Internal Status set to 'Resolved'
Status set to: Closed by Client

This event sent from IssueTracker by Sharon.Lightcap 
 issue 110251

*** Bug 247792 has been marked as a duplicate of this bug. ***

The customer (IT 125628) says that the problem is still there.

Hi Matsuya-san,

We tested the fix(Bugzilla #223805) and the result is no good.
By the fix there is one cursor(dot)on screen. But we can handle with guest
domain by vanished cursor(arrow).
The dot cursor is in the corner of guest domain's screen, it is remarkabley
mismatched.
Then it is more difficult to control guest domain by dot cursor.

We think the fix(Bugzilla #223805) not solve this problem.

Thank you.                                   Nishi

*** Bug 249273 has been marked as a duplicate of this bug. ***

I tested this issue with 5.1 beta again.
On PV guest of virt-manager, I cannot point the right edge in the screen.
Also, as often as I moved the pointer at the right edge, the boundary of
right edge was changed. Please try moving the pointer several times. When
the pointer is moved very slowly, it seems the pointer cannot reach the
right edge at all.


This event sent from IssueTracker by mmatsuya 
 issue 125628

I saw this issue several times when I reviewed several xen issues. 
After I moved the mount pointer repeatedly and fast, I could point the
edge of screen. But, this is really poor usability, I think.

Priority set to: 1

This event sent from IssueTracker by mmatsuya 
 issue 125628

Please confirm the package installed on the system used for testing and list
them on this BZ.

This issue has been already resolved, see comments above.

Fill new bugzillas if you need to report new issues.

See comment #28. Customer says that the bug is still there.

I wanted to know so that engineering will be able to still use the same
sosreport while investigating the fix.

Internal Status set to 'Waiting on Engineering'

This event sent from IssueTracker by alanm 
 issue 125628

With the virt-manager re-base for RHEL-5.2, all Windows guests will automatically
be given a USB tablet as their mouse. This gives pixel perfect mouse movement.
Linux guests also have the option to have a USB tablet - there is UI to
add it post-install, but we don't enable it by default because Linux needs
manual Xorg config to use it. Finally, virt-maanger now uses GTK-VNC instead
of its old Python VNC viewer widget. This has improved mouse pointer tracking
too, although not perfect - the USB tablet is still the best option

Greetings Red Hat Partner,

A fix for this issue should be included in the latest packages contained in
RHEL5.2-Snapshot1--available now on partners.redhat.com.  

Please test and confirm that your issue is fixed.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to ASSIGNED.

If you are receiving this message in Issue Tracker, please reply with a message
to Issue Tracker about your results and I will update bugzilla for you.  If you
need assistance accessing ftp://partners.redhat.com, please contact your Partner
Manager.

Thank you

feedback from Fujitsu. This problem isn't fixed yet.

------------------------------------------
We tested this problem with RHEL5.2 beta.
The result is no good.
And I have sent the sysreports.


This event sent from IssueTracker by mmatsuya 
 issue 125628

Created attachment 299426 [details]
sosreport#1 in C#36

Created attachment 299427 [details]
sosreport#2 in C#36

The last comment contains insufficient information:

"feedback from Fujitsu. This problem isn't fixed yet."

Please provide a clear & concise statement of what problem you are seeing.

We addressed the problem of the mouse cursors being out of sync / different
speeds by always grabbing the mouse cursor & confining it to the guest window &
hiding the local cursor. It is not clear what further issues are being seen

Hi, I could reproduce this problem on the pv guest. I used the following
packages.

Host OS:
# rpm -qa |grep  -e xen -e virt
kernel-xen-2.6.18-53.el5
xen-libs-3.0.3-58.el5
libvirt-0.3.3-6.el5
xen-3.0.3-58.el5
kernel-xen-2.6.18-87.el5
virt-viewer-0.0.2-1.el5
xen-devel-3.0.3-58.el5
kernel-xen-2.6.18-84.el5
python-virtinst-0.300.2-7.el5
virt-manager-0.5.3-5.el5
libvirt-python-0.3.3-6.el5

PV Guest:
kernel-xen-2.6.18-87.el5

There is the case I could not point the right edge. Please note that this
is not always. To reproduce, you need to move the pointer slowly from left
edge to right edge and from right edge to left edge repeatly in the window
of pv guest. I can reproduce in one minute. I'm not sure that the precise
condition for the reproduction. In a worst case, I could not point the
region of 5cm from right edge at all. After this problem occurs, if I
moved the pointer to the left once, I sometimes can move the pointer on
the right edge.



This event sent from IssueTracker by mmatsuya 
 issue 125628

Created attachment 299874 [details]
small picture of pv guest window

I uploaded one picture of the pv guest window. Please check the mouse pointer
on this picture. Really I cannot move this point to the right much more.

Thanks for the info. We have seen this 'invisible wall' problem. The core
problem is the mis-match in the VNC server - VNC works in an absolute mouse
coords mode, while the guest works in relative mode. 

In fullvirtualized guests you can work around this problem by configuring a USB
tablet in the guest. Virt-manager in RHEL-5.2 allows you to add a USB tablet to
any existing fullvirt guests.

The other option is to add support for the VNC relative mouse motion protocol
extension recently added to upstream QEMU.

*** Bug 282181 has been marked as a duplicate of this bug. ***

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
To workaround the issues of the mouse pointer hitting an "invisible wall" in fully virtualized guests use virt-manager to configure a USB table device for the guest. This will eliminate the issue.

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-To workaround the issues of the mouse pointer hitting an "invisible wall" in fully virtualized guests use virt-manager to configure a USB table device for the guest. This will eliminate the issue.+Fully virtualized guests created through virt-manager may sometimes prevent the mouse from moving freely throughout the screen. To work around this, use virt-manager to configure a USB tablet device for the guest.

*** Bug 439048 has been marked as a duplicate of this bug. ***

The solution for this problem is non-trivial and isn't actually solved as part of virt-manager. There are 3 aspects to it which play together to solve the whole invisible wall problem

First a statement about the problem:

The VNC desktop sends mouse events as absolute coordinates to QEMU
QEMU emulates a mouse device which operates with either absolute or relative motion events. For a HVM guests a PS/2 mouse provides relative motion evnts to the guest, so upon receiving an absolute pointer movement from VNC client, QEMU converts this into a relative delta movement and sends it to the guest. Due to the absolute -> relative conversion IN QEMU, the VNC client may hit the edge of what it believes is the desktop space before the guest cursor actually hits the edge. For paravirt guests the PVFB provides a mouse which can work in absolute or relative mode, and unfortunately it defaults to absolute mode, while Xorg defaults to using it in relative mode. So here the guest kernel does a conversion of absolute -> relative motion events, again causing a potential invisible wall in the client.


The are two possible ways to avoid the invisible wall

- Use relative motion events from the VNC client, all the way to the guest OS
- Use absolute motion events from the VNC client, all the way to Xorg in the guest

It is the conversion between the 2 modes halfway along that causes problems.

Thus to solve this we are doing several things

 - In Xen, the QEMU VNC sever is gaining support for a 'relative mouse motion' extension. This allows QEMU to tell the VNC client whether the mouse exposed to the guest is working in relative or absolute mode. https://bugzilla.redhat.com/show_bug.cgi?id=487559
 - In kernel-xen, the PVFB mouse is made to default to relative motion matching Xorg defaults in the guest.  https://bugzilla.redhat.com/show_bug.cgi?id=492866
 - In GTK-VNC client, if it gets told by QEMU that its running in relative mode, then it does some magic when the local cursor hits the edge of the screen, so that it keeps generating relative motion events. https://bugzilla.redhat.com/show_bug.cgi?id=487560

The combination of all these ensures no invisible wall is encountered.

FYI, there were no changes required to virt-manager itself in order to resolve this. The fixes were in the kernel, xen and gtk-vnc. For more info see bug 487559, bug 487560 and bug 492866

~~ Attention Partners RHEL 5.4 Partner Alpha Released! ~~

RHEL 5.4 Partner Alpha has been released on partners.redhat.com. There should
be a fix present that addresses this particular request. Please test and report back your results here, at your earliest convenience. Our Public Beta release is just around the corner!

If you encounter any issues, please set the bug back to the ASSIGNED state and
describe the issues you encountered. If you have verified the request functions as expected, please set your Partner ID in the Partner field above to indicate successful test results. Do not flip the bug status to VERIFIED. Further questions can be directed to your Red Hat Partner Manager. Thanks!

~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~

RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching.

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1285.html