Bug 890230 - Mouse does not function at all
Summary: Mouse does not function at all
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 5.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-25 23:59 UTC by mkruger
Modified: 2019-12-19 02:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-03 11:38:29 UTC
Target Upstream Version:
Embargoed:
intotheapex: needinfo-
intotheapex: needinfo-


Attachments (Terms of Use)

Description mkruger 2012-12-25 23:59:08 UTC
Description of problem:
The QXL driver does not work reliably when employed in a Qemu-KVM guest using virt-manager configured with the SPICE protocol. The mouse only works about 5 percent of the time. In other words, I can start the guest virtual machine 20 times and it may work correctly once. When I restart the virtual machine, the mouse moves, but I am unable to click on anything. This is 100 percent repeatable on other platforms using virt-manager, i.e, RHEL 6.3, Fedora 17, etc. The issue here is not an accuracy problem. I resolved the accuracy issue by adding a tablet and modifying xorg.conf, which provides perfect accuracy (the 5 percent of the time that it actually works). I am experiencing this problem with Centos 5.8 guests and felt it would be best to also report the problem upstream.

Version-Release number of selected component (if applicable):

xorg-x11-drv-qxl-0.0.12-2.el5

How reproducible:
100 %

Steps to Reproduce:
1. Configure guest OS with QXL driver
2. Configure guest hardware for QXL
3. Power off and restart virtual machine.
  
Actual results:
Mouse functions 5 percent of the time. Or when it works for extended periods of time (as sometimes seen on RHEL 6.3 platform), the mouse fails completely on any cloned virtual machines.

Expected results:
Mouse should always work. Whether a clone or the original virtual machine.

Additional info:

http://bugs.centos.org/view.php?id=6128

Comment 1 David Jaša 2013-01-03 14:11:04 UTC
I'd bet that your pointer position is out-of-sync with cursor position which is pretty easy to get in RHEL 5 guests if not configured properly. To fix it, follow these steps:

1) remove tablet device in virt-manager VM configuration if present there

2) in the VM, add EPEL repository (if not present), install spice-vdagent package, start the spice-vdagentd service

3) copy /usr/share/doc/spice-vdagent-VERSION/xorg.conf.RHEL-5 as new /etc/X11/xorg.conf (why you should do that is documented in README.RHEL-5 a

4) (re)start X

PS: if the steps above do work for you, please close the bug.

Comment 2 mkruger 2013-01-04 19:29:07 UTC
Thanks, that did the trick. 

I was already using the spice-vdagent but didn't know about the reference xorg.conf file, or the need to pull the table hardware device (given virt-manager itself says to use one to sort out these kinds of problems). Here's the diff of xorg.conf. 

diff xorg.conf xorg.conf.old 
0a1,2
> # Xorg configuration created by system-config-display
> 
2c4
< 	Identifier     "Default Layout"
---
> 	Identifier     "single head configuration"
5,6c7,8
<         InputDevice    "Mouse" "CorePointer"
<         InputDevice    "Tablet" "SendCoreEvents"
---
> 	InputDevice    "Tablet" "SendCoreEvents"
> 	InputDevice    "Mouse" "CorePointer"
17,20c19,20
<         Identifier  "Mouse"
<         Driver      "mouse"
<         Option      "Device" "/dev/input/mice"
<         #Option      "Emulate3Buttons" "yes"
---
> 	Identifier  "Mouse"
> 	Driver      "void"
24,26c24,37
<         Identifier  "Tablet"
<         Driver      "evdev"
<         Option      "Device" "/dev/input/event3"
---
> 	Identifier  "Tablet"
> 	Driver      "evdev"
> 	Option	    "Device" "/dev/input/event2"
> 	Option	    "CorePointer" "true"
> EndSection
> 
> Section "Monitor"
> 
> 	Identifier   "Monitor0"
> 	ModelName    "LCD Panel 1280x1024"
>  ### Comment all HorizSync and VertSync values to use DDC:
> 	HorizSync    31.5 - 64.0
> 	VertRefresh  56.0 - 65.0
> 	Option	    "dpms"
36a48
> 	Monitor    "Monitor0"
39a52
> 		Virtual   1280 800
40a54
> 		Modes    "1280x1024" "1280x960" "1280x800" "1152x864" "1024x768" "800x600" "640x480"
42a57
>

Comment 3 mkruger 2013-01-04 23:43:30 UTC
Probably should pull this information (from the 3.0 guide) as it doesn't work for Rhel 5 guests:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/SPICE_for_RHEL.html

I noticed the version 3.1 guide (https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Virtualization/) lacks guidance about using spice.

Comment 4 mkruger 2013-01-21 16:23:40 UTC
I discovered for older releases such as RHEL/Centos 5.6, in addition to using the reference Xorg file, to obtain screen sizes larger than 1024x768, you also need to add "Virtual 1280 800" (or something similar - without quotes) to the “screen” section as it was not enough to simply enlarge the size of the display.

Comment 5 Tim Hildred 2013-02-21 05:20:14 UTC
Hey Mkruger, 

The 3.1 one guide actually does contain that same content:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html-single/Administration_Guide/index.html#sect-Configuring_Red_Hat_Enterprise_Linux_5.4_or_Higher_Virtual_Machines_to_use_SPICE

We're hoping to work with David Jasa to update the existing content.

Comment 6 RHEL Program Management 2014-03-07 13:54:16 UTC
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.

Comment 7 RHEL Program Management 2014-06-03 11:38:29 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).


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