Bug 243920 - Jerky pointer movement with Xen guest virtual pointer device
Summary: Jerky pointer movement with Xen guest virtual pointer device
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-evdev   
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Kristian Høgsberg
QA Contact:
Depends On:
Blocks: 221360 245193
TreeView+ depends on / blocked
Reported: 2007-06-12 18:59 UTC by Daniel Berrange
Modified: 2018-04-11 10:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-17 01:34:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample Xorg config to use evdev with Xen guest framebuffer (786 bytes, text/plain)
2007-06-12 18:59 UTC, Daniel Berrange
no flags Details
Remove redundant pointer sync calls (635 bytes, patch)
2007-06-12 19:05 UTC, Daniel Berrange
no flags Details | Diff
Remove redundant pointer sync calls (1.19 KB, patch)
2007-08-24 14:07 UTC, Daniel Berrange
no flags Details | Diff

Description Daniel Berrange 2007-06-12 18:59:28 UTC
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):

How reproducible:

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:

Comment 1 Daniel Berrange 2007-06-12 18:59:28 UTC
Created attachment 156818 [details]
Sample Xorg config to use  evdev with Xen guest framebuffer

Comment 2 Daniel Berrange 2007-06-12 19:04:40 UTC
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 ?!?!

Comment 3 Daniel Berrange 2007-06-12 19:05:22 UTC
Created attachment 156820 [details]
Remove redundant pointer sync calls

Comment 4 Daniel Berrange 2007-08-24 14:07:44 UTC
Created attachment 172417 [details]
Remove redundant pointer sync calls

The xorg-x11-drv-evdev	code currently in F7/rawhide doesn't compile. This
updated patch includes a fix to also remove use of
SendCoreEvents/DontSendCoreEvents flags which allows the driver to be rebuilt
with the pointer sync fix.

Comment 5 Bug Zapper 2008-05-14 13:02:34 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Bug Zapper 2008-06-17 01:33:58 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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