Bug 434807 - vmmouse cursor position doesn't match screen coordinates
vmmouse cursor position doesn't match screen coordinates
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vmmouse (Show other bugs)
9
All Linux
high Severity high
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened
: 439336 444395 461466 (view as bug list)
Depends On:
Blocks: F9Target
  Show dependency treegraph
 
Reported: 2008-02-25 11:35 EST by Charlie Moschel
Modified: 2008-11-14 07:45 EST (History)
10 users (show)

See Also:
Fixed In Version: xorg-x11-drv-vmmouse-12.6.1-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-29 11:02:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
xorg.0.log when vmmouse is specified in xorg.conf (26.51 KB, text/plain)
2008-02-26 00:53 EST, Charlie Moschel
no flags Details
log file with no xorg.conf (29.00 KB, text/x-diff)
2008-02-26 00:58 EST, Charlie Moschel
no flags Details
xorg.conf with no auto added devices, typical laptop screen setup (may need adjusted) (1.13 KB, text/plain)
2008-04-03 21:01 EDT, Andrew Farris
no flags Details
Log file with signal 11 & backtrace when using new vmmouse driver (18.66 KB, text/x-log)
2008-10-23 08:38 EDT, Charlie Moschel
no flags Details
F10 Rawhide Xorg.0.log w/ backtrace (19.39 KB, text/x-log)
2008-10-24 00:14 EDT, Charlie Moschel
no flags Details
"xinput -list" with AutoAddDevices=true (1.39 KB, text/plain)
2008-10-24 22:26 EDT, Charlie Moschel
no flags Details
"xinput -list" when AutoAddDevices=False (687 bytes, text/plain)
2008-10-24 22:29 EDT, Charlie Moschel
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 17489 None None None Never

  None (edit)
Description Charlie Moschel 2008-02-25 11:35:29 EST
Description of problem:

Recent (22-Feb-08) rawhide update breaks vmmouse.  Cursor appears and is mobile,
but screen coordinates are wrong; can't click on anything.  If you happen to see
a button or menu item highlight from mouseover, click will work, but cursor is
far away.

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

xorg-x11-drv-vmmouse-12.4.3-4.fc9.


How reproducible:
Always.  


Steps to Reproduce:
1. update a vmware image using vmmouse driver to at least 22-Feb-08 
2.Observe disconnected cursor position
3.
  
Actual results:
Cursor pos'n doesn't match screen coordinates

Expected results:
Cursor reflects correct coordinates.


Additional info:

May be related to vmmouse-coord-hack.patch, added 2-Jan to work around an
upstream bug.  Both Fedora (https://bugs.freedesktop.org/show_bug.cgi?id=13552)
and Debian added the workaround
(http://groups.google.com/group/linux.debian.maint.x/browse_thread/thread/9c2ecc22fba0f03a)

Upstream bug: (https://bugs.freedesktop.org/show_bug.cgi?id=10324).

This upstream bug seems to be fixed in xorg-x11-server 02-05-08, so I would
guess that the vmmouse-coord-hack.patch can be backed out.  

I will downgrade to xorg-x11-drv-vmmouse-12.4.3-2.fc9, before the coord-hack
patch was applied, to see if it fixes the issue, and add that info later
tonight.  (I first tried downgrading to just 12.14.3-3.fc9 before I looked into
any details, and of course it didn't fix anything).
Comment 1 Matěj Cepl 2008-02-25 12:00:26 EST
Let us know, how the downgrading went.
Comment 2 Charlie Moschel 2008-02-26 00:53:12 EST
Created attachment 295874 [details]
xorg.0.log when vmmouse is specified in xorg.conf

xorg.0.log when vmmouse is specified in xorg.conf
Comment 3 Charlie Moschel 2008-02-26 00:56:12 EST
Well, reverting to xorg-x11-drv-vmmouse-12.4.3-2.fc9 does not help; exact same 
symptoms.

Let me know what other info can help diagnose the problem.

(Sorry, I attached the first file before sending these comments).

Next attchment will be Xorg.0.log with no xorg.conf.
Comment 4 Charlie Moschel 2008-02-26 00:58:29 EST
Created attachment 295875 [details]
log file with no xorg.conf

Everything is autodetected here.  Mouse works OK in this case, but is captured
by the vmware window.
Comment 6 Charlie Moschel 2008-02-27 00:09:03 EST
Found a work-around: add 'Option "AutoAddDevices" "no"' to xorg.conf 
ServerLayout section.  This prevents "Macintosh mouse button emulation" and 
ImPS/2 from loading (presumably from hal), and hence evdev is not loaded 
either.  vmmouse then works OK when specified in xorg.conf.

Is that expected behaviour?
Comment 7 Andrew Farris 2008-02-27 18:57:54 EST
Denying AutoAddDevices also fixes this mouse location weirdness for me with VMware Fusion 1.1.  The 
input devices are manually configured instead and it works for logging in via startx.  Having this 
configuration and the latest gdm is still an unworkable situation for me (gdm respawning with any input) 
but the accurate location of the mouse click is fixed.

It seems like creating the multiple input pointers is causing them to fight over where the mouse currently 
is?
Comment 8 Andrew Farris 2008-02-27 18:58:12 EST
Denying AutoAddDevices also fixes this mouse location weirdness for me with VMware Fusion 1.1.  The 
input devices are manually configured instead and it works for logging in via startx.  Having this 
configuration and the latest gdm is still an unworkable situation for me (gdm respawning with any input) 
but the accurate location of the mouse click is fixed.

It seems like creating the multiple input pointers is causing them to fight over where the mouse currently 
is?
Comment 9 Charlie Moschel 2008-03-08 10:04:34 EST
One of the recent updates appears to have fixed this.  I tried with updates of 
7-Mar, and vmmouse driver works without denying "AutoAddDevices".  evdev is 
loaded.  xorg-x11-drv-vmmouse version has not changed though, some other 
update fixed it.  

(Now vmware screen driver can't find any valid screens though, so today's test 
is with the VESA driver, FWIW)
Comment 10 Charlie Moschel 2008-03-08 19:58:21 EST
Sorry, I spoke too soon: there's still a problem when evdev is loaded, but the 
symptoms are different.  Now the cursor location in the virtual machine window 
is as expected, but the cursor jumps out of the window at strange locations.

For example, moving toward the left side of the virtual screen, the pointer 
may jump into the host window way before reaching the left border of the 
virtual screen.  Additionally, this discrepancy is variable, so sometimes it 
jumps out too early, sometimes it's about right, and sometimes it's too late 
(stopping at the VMs window momentarily before popping onto the host screen).  
The vertical locations do not match either, differing by 1/4 to 1/2 of the 
screen height.

This can make it difficult to reach menus at the top and/or bottom of the 
screen.

These issues go away again if evdev is prevented from loading using the 
work-around above.
Comment 11 Jeff Bastian 2008-03-18 12:30:56 EDT
I'm using VMware Fusion 1.1.1 and have the same problem.  I just added
   Option "AutoAddDevices" "no"
to my xorg.conf and the mouse works correctly now.

Since many folks (like myself) tend to use virtual machines for testing alpha
and beta releases, I've increased the priority and severity on this bug.
Comment 13 Charlie Moschel 2008-03-31 11:07:32 EDT
Now, after recent vmmouse & x11server updates, behaviour is back to original:
Still have a disconnect between the 'hotspot' and the pointer position.  But no
more pointer jumps when passing between vm window and host window; behaviour
described in comment #10 is gone.

As before, works fine if evdev is suppressed by Option "AutoAddDevices" "No"

Should this be reclassed against evdev?
Comment 14 Andrew Farris 2008-03-31 11:28:16 EDT
I can verify it returned (comment #13), using both the Rawhide snapshot Live disks of 20080327 I see the 
same problem on vmware fusion (osx 10.5 host).
Comment 15 Austin 2008-04-03 18:22:05 EDT
I think a bug I reported (bug# 439336) is a duplicate of this one. Some
suggestions there helped by turning off mouse acceleration (xset m 0). It works
as long as the cursor stays in the main window. Once it leaves and returns it
has the same problem.

Have a a read of the bug to see for yourself if any of the problems and proposed
solutions there are applicable.
Comment 16 Andrew Farris 2008-04-03 21:01:41 EDT
Created attachment 300370 [details]
xorg.conf with no auto added devices, typical laptop screen setup (may need adjusted)

Austin, after reading your bug it is nearly identical to the situation
described here.  I would suggest trying this xorg.conf and if it works fine for
your setup then the auto added devices are partly to blame, not just
acceleration.

It is interesting however that the acceleration set to 0 does help.  I noticed
the same behavior you're describing where the mouse location is somewhat
predictable if you move extremely slowly and smoothly.	It really has a
predictable offset in x/y until you move fast again, so each time the mouse
accelerates it ends up with a recalc of its location offset from where you see
the cursor.  With NoAutoAddDevices this doesn't happen.
Comment 17 Austin 2008-04-07 01:55:06 EDT
I'm going to guess that there's more than one "mouse" being picked up (somehow).
Disabling auto-add stops the additional "mice", and the acceleration problems is
because both "mice" are being accelerated resulting in twice the distance being
reported back. Or something like that.

If the mouse is moved slowly, there's no problem, because it doesn't enter the
"acceleration stage".

These are just guesses based on observations. I'll try the "no auto add devices"
trick to see if that helps some more.

Any word from a developer?
Comment 18 Jon Stanley 2008-04-16 21:27:17 EDT
I thought that evdev was gone for mice (or is that just keyboards?).  I do most
of my testing in VMWare, however, I just let it autoconfigure stuff for me in X
(I do most of my X work on an HP laptop that I use for testing).  I've not
noticed a problem with the mouse.  I'll make sure that it really is using
vmmouse and test again hopefully this evening or tomorrow
Comment 19 Jon Stanley 2008-04-17 23:22:16 EDT
OK, sorry that took awhile.  I'm not an X guy and had to figure some things out
:).  Being that this config is not the default, that it is difficult and
requires manual intervention to get into a non-working configuration (and I have
verified that the config is bustificated), it doesn't take much more to get to a
working config, as mentioned in comment #16 - I'm going to remove this from the
F9 blocker and put it on F9Target.  
Comment 20 Andrew Rechenberg 2008-04-18 16:38:45 EDT
Adding a "me too" to this bug.

This seems to a problem across VMware products.  I've duplicated it with the F9
Beta Live CD on both VMware Fusion (1.1, OS X 10.4.10 [I think - dont have my
MBP with me at work]) and VMware Server (1.0.5, Fedora 8 host).

Let me know if you want me to test or attach anything.
Comment 21 Michael Monreal 2008-04-19 07:56:27 EDT
I restently installed Fedora9Pre on KVM. Using vmmouse, all mouse actions
(moving, pressing) result in horizontal movement of the mouse pointer to the
right. I'm wondering if this is releated to this bug?

Also, using the default mouse (which was using evdev I guess) I was unable to
get the mouse wheel working.

Anyway, after adding the suggested workaround I can use the wheel with the
"mouse" driver (the ZAxisMapping setting is now picked up). But, if I use
vmmouse I still see the same bad movement :(
Comment 22 Andrew Rechenberg 2008-04-25 12:41:57 EDT
FYI, this bug no longer seems to be present in the F9-Preview-LiveCD when
running on VMware Server 1.0.5 on a F8 host.  Will check on Fusion this weekend
Comment 23 Michael Monreal 2008-04-25 12:53:51 EDT
My problem still exists (running Preview+updates on KVM). If this turns out to
not be the same problem, I'll file another bug.
Comment 24 Jon Stanley 2008-04-25 16:52:57 EDT
As of rawhide 20080417 this problem existed for me, using VMWare Server 1.0.4. 
There have been no updates to the vmmouse driver since that time (however, there
have been core X updates).

I'll test again this weekend as well.
Comment 25 Charlie Moschel 2008-04-25 20:41:48 EDT
Still exists for me (rawhide updated to 25-Apr-08)

Summary, just retested:
* No xorg.conf: pointer works normally, but captured by VM window 
* vmmouse in xorg.conf: pointer problem is as described above
* vmmouse in xorg.conf, with AutoAddDevices set to false: pointer works 
normally, and seamlessly across host & VM windows.

Although Jon is right in comment #19 about it needing work to get it to a 
broken state, adding vmmouse for seamless pointers is the first thing most 
people do when setting up a VM.

Maybe the workaround should be listed in the release notes?
Comment 26 Jon Stanley 2008-04-26 01:18:20 EDT
I already put the release note in at the same time I yanked this from the blocker.

http://fedoraproject.org/wiki/Docs/Beats/Desktop
Comment 27 Michael Monreal 2008-04-26 04:00:16 EDT
(In reply to comment #26)
> I already put the release note in at the same time I yanked this from 
> the blocker.

Uhm... first, this does not fix things for me. Second, isn't xorg using the
"mouse" driver when "NoAutoAddDevices" is used, so all this "workaround" does is
enabling the mouse section (which then can contain vmmouse, which does not work
correctly)?
Comment 28 Charlie Moschel 2008-04-26 21:10:51 EDT
(In reply to comment #26)
> I already put the release note in at the same time I yanked this from the 
blocker.
> 
> http://fedoraproject.org/wiki/Docs/Beats/Desktop

Sorry Jon, I should have re-checked.

Michael, it sounds like the problem you described in comment #21 (horizontal 
pointer movement on button presses) is something different than this bug, 
especially if the workaround doesn't fix it.  Probably worth a new bugzilla 
entry.
Comment 29 Michael Monreal 2008-04-28 02:57:39 EDT
(In reply to comment #28)
> Probably worth a new bugzilla entry.

I filed a new bug: #444395.

Just after filing it I realized what is wrong: my xorg never actually uses the
vmmouse driver! it seems to load it just fine but loads evdev after it. After
renaming the evdev driver, vmmouse works correctly.

Nobody else here seeing such a problem? Do you all have evdev installed?
Comment 30 Bug Zapper 2008-05-14 01:38:06 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Peter Hutterer 2008-08-22 04:42:32 EDT
Here's what happens:
VMMouse attaches to /dev/input/mice and communicates with the VM to get absolute data. If we're not running inside a VM, then the driver actually instantiates the mouse driver.

Now with F9 we use input hotplugging with the evdev driver. This driver grabs each device, stopping it from sending to /dev/input/mice. The vmmouse driver becomes essentially ineffective as it'll never receive any events.

The only way to stop evdev from grabbing the event device is by disabling it - AutoAddDevices off. I'm afraid there's no better solution to this.

To resolve this issue, the upstream driver needs to be updated to work on the event devices instead.

A long description of evdev's interaction with devices can be found here:
http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html
Comment 32 Peter Hutterer 2008-09-08 16:52:23 EDT
*** Bug 461466 has been marked as a duplicate of this bug. ***
Comment 33 Peter Hutterer 2008-09-10 10:55:25 EDT
*** Bug 444395 has been marked as a duplicate of this bug. ***
Comment 34 Fedora Update System 2008-10-21 02:06:16 EDT
xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.5.2-1.fc9
Comment 35 Peter Hutterer 2008-10-22 01:12:06 EDT
*** Bug 439336 has been marked as a duplicate of this bug. ***
Comment 36 Charlie Moschel 2008-10-23 08:38:51 EDT
Created attachment 321276 [details]
Log file with signal 11 & backtrace when using new vmmouse driver

(In reply to comment #34)
> xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been submitted as an update for Fedora 9.
> http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.5.2-1.fc9

Sorry, but I get X backtraces whenever this new vmmouse is used.

I tested in sequence, with the following results:

* Freshly installed F9 system, new vmmouse: would not load vmmouse driver (wrong version), no mouse movement.
* Same, but now add up-to-date evdev: same result (wrong version) and no mouse.
* Same, but now add 'yum update xorg*': signal 11 & backtrace.
* finally, a fully updated F9: same signal 11 & backtrace.

Log file is attached.  I did verify that there were no backtraces and X came up normally if vmmouse was commented out.
Comment 37 Charlie Moschel 2008-10-23 09:06:24 EDT
Forgot to mention that current F10 rawhide seems to be fixed.  When I remove the workaround I had been carrying (comment #6), the mouse still works properly: no offsets.
Comment 38 Fedora Update System 2008-10-23 12:35:23 EDT
xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-vmmouse'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9035
Comment 39 Charlie Moschel 2008-10-23 22:14:11 EDT
(In reply to comment #37)
> Forgot to mention that current F10 rawhide seems to be fixed.  When I remove
> the workaround I had been carrying (comment #6), the mouse still works
> properly: no offsets.

Well now rawhide X server generates backtraces too, since xorg-x11-drv-12.5.2-1.fc10 has been installed.  

Reverting it gets X working again, and as before, the workaround is not needed.
Comment 40 Peter Hutterer 2008-10-23 23:13:30 EDT
Pulled it from F9 again. can you please attach your log with the backtrace. Thx.
Comment 41 Charlie Moschel 2008-10-24 00:14:02 EDT
Created attachment 321369 [details]
F10 Rawhide Xorg.0.log w/ backtrace

(In reply to comment #40)
> Pulled it from F9 again. can you please attach your log with the backtrace.
> Thx.

Sure.  F9 (up-to-date) log is https://bugzilla.redhat.com/attachment.cgi?id=321276
and I'm just attaching F10 Rawhide log now.
Comment 42 Peter Hutterer 2008-10-24 01:20:41 EDT
I got it narrowed down to two issues that could trigger that:

Here's a vmmouse update that should merely avoid it: http://koji.fedoraproject.org/scratch/whot/task_900206/

And that's a xserver with additional sanity checks that should not fail even if the driver misbehaves: http://koji.fedoraproject.org/scratch/whot/task_900222/

Can you please give them a try? Thanks.
Comment 43 Peter Hutterer 2008-10-24 02:21:55 EDT
Philip just released vmmouse 12.6.0 which fully supports HAL etc. Can you give the package a try too please? I fail at getting vmware to run.

http://koji.fedoraproject.org/scratch/whot/task_900326/
Comment 44 Charlie Moschel 2008-10-24 21:35:07 EDT
(In reply to comment #42)
> I got it narrowed down to two issues that could trigger that:
> 
> Here's a vmmouse update that should merely avoid it:
> http://koji.fedoraproject.org/scratch/whot/task_900206/
> 
> And that's a xserver with additional sanity checks that should not fail even if
> the driver misbehaves: http://koji.fedoraproject.org/scratch/whot/task_900222/
> 
> Can you please give them a try? Thanks.

All tests below are under F10 rawhide, up to date 23-Oct-08:

First updated xerver: new xserver keeps xorg-x11-drv-vmmouse-12.5.2-1 from segfaulting, mouse seems to track properly.  But under gnome I need to hold down LMB to keep menu panels up.  Selection is made when LMB is released.  It's worse under KDE, as menus flash then disappear, even if LMB is held down.  A single click & hold LMB on Konsole titlebar will maximize the window.  Not sure if this is related to the new xserver, bad vmmouse, or general rawhide dementia.  Note that this is fixed if I set AutoAddDevices to "No" in xorg.conf: clicks are back to normal

Next I updated vmmouse to 12.5.2-2:  Works just like description above.  No segfaults, but weird click events.  Seems to send two click events, turning everything into double clicks.  As above, click dementia can be fixed by suppressing AutoAddDevices.

Finally I updated to vmmouse 12.6.0-1:  Same as above: no segfaults, proper tracking, good behavior when passing between host & guest window, but still has click dementia.  Again, fixed by suppressing AutoAddDevices.
Comment 45 Charlie Moschel 2008-10-24 22:26:50 EDT
Created attachment 321483 [details]
"xinput -list" with AutoAddDevices=true

xinput list when devices are auto added.  vmmouse-12.6.0, xserver-1.5.2-9

This configuration has 'unintentional double-click dementia'
Comment 46 Charlie Moschel 2008-10-24 22:29:57 EDT
Created attachment 321484 [details]
"xinput -list" when AutoAddDevices=False

xinput list when devices are *not* auto added.  vmmouse-12.6.0, xserver-1.5.2-9

This configuration works no problem.

Let me know if you need any Xorg.0.log files
Comment 47 Charlie Moschel 2008-10-24 23:18:10 EDT
Further update: things look fixed under rawhide :)

I updated to today's (24-Oct) rawhide, rebooted, and mouse is working!  No workaround needed!  Not sure what fixed it.  Testing in comments 44 to 46 was done without rebooting, only 'telinit 3' and 'telinit 5' or startx.  Should I have rebooted?

So AFAICT, this can be closed under Rawhide.  I'll test vmmouse-12.6.0 under F9 shortly.
Comment 48 Charlie Moschel 2008-10-24 23:25:46 EDT
(In reply to comment #47)
> So AFAICT, this can be closed under Rawhide.  I'll test vmmouse-12.6.0 under F9
> shortly.

F9 is still not working.

On a fully up-dated F9, I tried to update to vmmouse-12.6.0, and got the same segfaults & backtrace as before.

Then I updated to xserver-1.5.2-9 (with the sanity checks), and backtraces stopped.  Mouse works OK as long as workaround (AutoAddDevice=false) is still in place.  Without workaround, the clicking is OK, but the original problem is still there: the pointer location does not correspond to the 'hot-spot'.
Comment 49 Fedora Update System 2008-10-26 21:47:07 EDT
xorg-x11-drv-vmmouse-12.6.1-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.6.1-1.fc9
Comment 50 Fedora Update System 2008-10-26 22:49:23 EDT
xorg-x11-server-1.5.2-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-2.fc9
Comment 51 Charlie Moschel 2008-10-27 10:38:40 EDT
Applying updates in comment #49 and comment #50 fixed this for me!  On a test F9 system, fully up to date, I get no segfaults and good tracking / release with no workaround needed.

Great job, thanks!
Comment 52 Denis Leroy 2008-10-28 05:34:27 EDT
I'm curious how you work around bug 461465. Do you use a custom xorg.conf file ?
Comment 53 Charlie Moschel 2008-10-28 08:29:29 EDT
(In reply to comment #52)
> I'm curious how you work around bug 461465. Do you use a custom xorg.conf file
> ?

Yes, I've generated a default one using 'Xorg -configure', and modified it by hand  to add vmmouse.  Newest vmware-tools should be able to do that for you; I haven't tried recently.

Reading through your bug, it seems that the way is clear to add autodetect for vmmouse, now that the evdev situation is fixed.  Perhaps re-open it for an F11 feature?  That would be *great* for virtual clients.  (Do other VM systems use the vmmouse driver too?  I only have experience with VMware).
Comment 54 Denis Leroy 2008-10-28 13:05:51 EDT
Actually, after retesting without xorg.conf, autodetect now works! So vmmouse is back to 100% support.
Comment 55 Fedora Update System 2008-11-03 00:51:14 EST
xorg-x11-server-1.5.2-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-3.fc9
Comment 56 Fedora Update System 2008-11-05 23:06:07 EST
xorg-x11-drv-vmmouse-12.6.1-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 57 Fedora Update System 2008-11-14 07:44:57 EST
xorg-x11-server-1.5.2-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

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