+++ 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): xorg-x11-drv-evdev-1.1.2-3.fc7 How reproducible: Always 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 Actual results: Mouse moves up left-hand side of screen, and then at last movement flips over to top-right corner Expected results: Mouse moves smoothly diagonally across the screen from bottom-left to top-right. Additional info: -- Additional comment from berrange 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 berrange 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 berrange 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 release.
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.