Red Hat Bugzilla – Bug 245193
Jerky pointer movement with Xen guest virtual pointer device
Last modified: 2008-01-18 16:50:37 EST
+++ This bug was initially created as a clone of Bug #243920 +++
Description of problem:
I setup an Xorg config under a Xen guest to use the evdev driver for input
instead of /dev/input/mice, since the former honours absolute pointer events &
thus avoids the insane 'double mouse' issues.
There appears to be a bug in the evdev driver though. If moving the cursor in
the X-axis only, or in the Y-axis only it works fine. If I move the cursor in
the X & Y axis at the same time (eg bottom-left -> top-right of screen), the
position of the cursor on screen seems to 'loose' the X co-ordinate updates
until I finish moving the mouse.
eg, move from bottom-left -> top-right of screen, while the mouse it moving the
cursor will only update the Y co-ordinate. When I stop moving the mouse, it
finally updates the X co-ordinate
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot a Fedora 7 paravirt Xen guest
2. Configure it to use attached Xorg config file
3. Start X
4. Move mouse at a medium speed from bottom-left to top-right corner of screen
Mouse moves up left-hand side of screen, and then at last movement flips over to
Mouse moves smoothly diagonally across the screen from bottom-left to top-right.
-- Additional comment from firstname.lastname@example.org on 2007-06-12 14:59 EST --
Created an attachment (id=156818)
Sample Xorg config to use evdev with Xen guest framebuffer
-- Additional comment from email@example.com on 2007-06-12 15:04 EST --
Looking at the way the evdev events are fed from kernel upto X, the data stream
has 3 core types of event
- X axis update
- Y axis update
- Sync event
The kernel normally sends a sequence of
- X axis update + Y axis update + sync event
- X axis update + sync event
- Y axis update + sync event
There is some extra code in the evdev driver, however, which does an explicit
sync after every individual X or Y axis event. This seems to be causing the X
axis update to be lost - resulting in the cursor travelling up the left-hand
side of the screen when moved diagonally. This manual sync looks unneccessary
since the kernel sends an explicit sync event whenever one ie needed.
So I wrote the attached patch which removed the two redundant calls to sync
pointer position. This resulted in smooth mouse movement expected.
I'm a little puzzelled why these explicit sync calls are in the driver at all -
not clear they could ever have worked correctly ?!?!
-- Additional comment from firstname.lastname@example.org on 2007-06-12 15:05 EST --
Created an attachment (id=156820)
Remove redundant pointer sync calls
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred. You may
reopen this bugzilla for consideration in the next release.
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
I talked to danpb about it and the problem only happens with the 1.1.2 version,
but we rolled the driver back to 1.0.2 in RHEL5 because the 1.1.2 was in very
bad shape. We just verified that under RHEL5, the Xen pointer is handled
correctly by the 1.0.2 driver. Closing bug.