Bug 473825 - Mouse intermittently stops working in X
Summary: Mouse intermittently stops working in X
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 475945 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-30 22:36 UTC by Edward Kuns
Modified: 2018-04-11 08:04 UTC (History)
10 users (show)

Fixed In Version: 1.5.2-6.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-24 20:46:12 UTC


Attachments (Terms of Use)
xorg.conf (1.89 KB, text/plain)
2008-11-30 22:36 UTC, Edward Kuns
no flags Details
My Xorg.0.log (15.43 KB, text/plain)
2008-12-01 22:40 UTC, Robert Peterson
no flags Details
My .xsession-errors (17.67 KB, text/plain)
2008-12-01 22:41 UTC, Robert Peterson
no flags Details
My xorg.conf file (4.34 KB, text/plain)
2008-12-01 22:42 UTC, Robert Peterson
no flags Details
dmesg from bootup where the mouse was non-responsive (38.10 KB, text/plain)
2008-12-16 04:45 UTC, Edward Kuns
no flags Details
dmesg from bootup where the mouse was responsive and normal (38.30 KB, text/plain)
2008-12-16 04:46 UTC, Edward Kuns
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 18668 None None None Never

Description Edward Kuns 2008-11-30 22:36:18 UTC
Created attachment 325155 [details]
xorg.conf

With a Dell Latitude D820, recently upgraded from Fedora 8 to Fedora 10, the mouse sometimes becomes totally unresponsive to all input.  I saw this under Fedora 8, but FAR more rarely.  Usually when I have this problem, I have the problem immediately after starting X, but sometimes the mouse -- for no obvious reason -- becomes non-responsive.  In all cases, the keyboard continues to work.  Sometimes if I switch from X to a text console and back, the mouse will start working again.  So far always, if I use keyboard shurtcuts to log out and then log back in, the mouse will start working again.

How reproducible:

Since upgrading to Fedora 10, I see this daily.  I don't know how to cause this to occur and so far looking in logs I have not seen any obvious complaint correlated with this.  I did see this message at my previous login (where I had this prolblem)

GSynaptics couldn't initialize.
You have to set 'SHMConfig' 'true' in xorg.conf or XFree86.conf to use GSynaptics

but when I look at the xorg.conf (attached), it already has this line.  I logged out and logged back in, and the second login (without this problem) does not have this complaint in .xsession-errors.  There is no obvious problem in dmesg output or int messages.log.

Comment 1 Matěj Cepl 2008-12-01 15:11:03 UTC
a) we would need /var/log/Xorg.0.log from your computer as well,
b) SHMConfig has been switched off in Fedora since at least early Fedora 9 (it is a security disaster in making)

Thank you

Comment 2 Robert Peterson 2008-12-01 22:40:37 UTC
Created attachment 325310 [details]
My Xorg.0.log

I'm having the same problem.  I tried xev, and it showed no events
when I click any mouse buttons and such.  Keyboard continues to work.
I'm seeing the problem 4 times a day.  I will attach my xorg.conf
file and .xsesson-errors as well.

Comment 3 Robert Peterson 2008-12-01 22:41:30 UTC
Created attachment 325311 [details]
My .xsession-errors

This is my .xsession-errors file at the time of failure

Comment 4 Robert Peterson 2008-12-01 22:42:25 UTC
Created attachment 325312 [details]
My xorg.conf file

Here is my xorg.conf file.

Comment 5 Robert Peterson 2008-12-01 22:44:46 UTC
I'm willing to take test code and/or patches to debug this.
I'm a Red Hat file system/kernel level developer and I'm willing to
do whatever it takes to solve the problem.

Comment 6 Peter Hutterer 2008-12-02 23:22:08 UTC
FYI, you can remove all mouse/keyboard input sections from the xorg.conf, they're not doing anything anymore anyway.

Edward: regarding the synaptics issue - remove the line Option "Device" "/dev/input/mice" (and the one with Procool auto-dev, it's default anyway).
Also, when you say the "mouse" becomes unresponsive are you talking about a physical mouse you have connected as well (i.e. touchpad still works) or about the pointer on the screen?

Edward and Robert:
Please get evtest from http://people.freedesktop.org/~whot/evtest.c, compile it with gcc -o evtest evtest.c and run it against the device's event file (see /proc/bus/input/devices). Does it still show events there when the pointer is dead?

Comment 7 Edward Kuns 2008-12-03 03:51:28 UTC
Hmm, OK, I compiled evtest and /proc/bus/input/devices gives me

I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="PS/2 Mouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=6337
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse2 event6 
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

evtest doesn't do anything but complain with files I tried under /sys/devices/platform/i8042/serio1/input/input6/, but if I try with /dev/input/event5 or event6 it appears to mostly work.  So I run evtest when things are working OK and I get:

$ ./evtest /dev/input/event6
Input driver version is 1.0.0
Input device ID: bus 0x11 vendor 0x2 product 0x8 version 0x6337
Input device name: "AlpsPS/2 ALPS GlidePoint"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 273 (RightBtn)
    Event code 274 (MiddleBtn)
    Event code 325 (ToolFinger)
    Event code 330 (Touch)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value    537
      Min        0
      Max     1023
    Event code 1 (Y)
      Value    453
      Min        0
      Max      767
    Event code 24 (Pressure)
      Value      0
      Min        0
      Max      127
Grab failed: Device or resource busy
Testing ... (interrupt to exit)

but I get no events.  I'm guessing I get no events because of the "Grab failed" complaint.  So far, I've not tried a PS/2 mouse (or an external USB mouse) on this laptop.  Thus, if I run evtest on the other mouse device, not surprisingly, the grab succeeds but I get no events.

Next time things freeze up, I'll try plugging in a USB mouse and I'll run the above again and see if anything is different.

What happens to me when things freeze up is that the touchpad *and* the button mouse *and* both sets of mouse buttons (above and below the touchpad) all become non-responsive.

Comment 8 Peter Hutterer 2008-12-03 04:01:30 UTC
synaptics puts a grab on the device, so the "grab failed" message will happen for any device using synaptics. For normal mice it should succeed though.

There's another thing that you could try: add Option AutoAddDevices "off" to the ServerLayout This will force the mouse driver to load. If you can reproduce the problems with the mouse driver as well, that means it's either the X server, or the kernel. If not, then it's the driver. However, since Robert doesn't have a touchpad but sees the same issues, it doubt it's the driver.

Comment 9 Edward Kuns 2008-12-03 04:44:37 UTC
OK, I deleted the mouse and keyboard sections, whole, from /etc/X11/xorg.conf,
as well as references to them.  I logged out and back in to restart X.  Most
everything appears to work as it did before.  However, now I cannot configure
my Synaptics touchpad.  I bring up System -> Preferences -> Hardware ->
Touchpad and I get a pop-up complaint 

GSynaptics couldn't initialize.
You have to set 'SHMConfig' 'true' in xorg.conf or XF86Config to use GSynaptics

Either the SHM line does something or GSynaptics has an intermittent failure to
operate.  My experience says it could be either one.

Oddly, I was seeing this issue regularly, one or more times every day, until I reported the bug.  I haven't seen it since.  But I'm positive it will recur.  When it does, I'll run the requested tests and gather the requested logs.  Hopefully Robert will be able to reproduce this.

Comment 10 Peter Hutterer 2008-12-03 06:17:00 UTC
Do you still have the Synaptics line in your config? If not, add the line 
<merge key="input.x11_options.SHMConfig" type="string">1</merge> to 
 /usr/share/hal/fdi/policy/20thirdparty/10-synaptics.fdi

Try the command synclient -l. Does that report an error too? If so, then I need to see your log file.

Comment 11 Edward Kuns 2008-12-03 13:40:10 UTC
I totally removed the keyboard and mouse sections from xorg.conf, meaning there is no reference at all to Synaptics.

$ synclient -l
Can't access shared memory area. SHMConfig disabled?

I've updated 10-synaptics.fdi so it now contains

      <match key="info.product" contains="AlpsPS/2 ALPS">
	<merge key="input.x11_driver" type="string">synaptics</merge>
	<merge key="input.x11_options.SHMConfig" type="string">1</merge>
      </match>

I'll let you know if this helps.

Comment 12 Robert Peterson 2008-12-03 13:46:00 UTC
Just an FYI--

I'm trying to recreate the problem now, but of course, it won't when
I most need it to.  I'll let you know the results of evtest as soon
as the problem recreates.  Unfortunately, that particular system won't
get a lot of use until probably Monday.

Comment 13 Edward Kuns 2008-12-03 14:30:18 UTC
Updating 10-synaptics.fdi does allow me to run synclient.  I only updated the one XML stanza that matches my touchpad, but probably all synaptics products need this setting?

Comment 14 Peter Hutterer 2008-12-04 01:54:27 UTC
Edward: 
Just a heads-up, I had debugging session with Robert and we couldn't identify the issue yet. But here's a few things I'd need from you:

- are you on a 64 bit box?
- please get http://people.freedesktop.org/~whot/grabtest.c, compile it with gcc -o grabtest -lX11 grabtest.c and run it when the mouse is stuck. Does it report success for both mouse and keyboard?
- does xev show anything (movements, button events) when the mouse is stuck?
- does evtest show events when the mouse is stuck in X?

I'm waiting on a rather special logfile from Robert now, but the above information will help figuring out whether you two see the same issue.

Comment 15 Edward Kuns 2008-12-04 02:24:19 UTC
I am not on a 64 bit platform.  It's a Core 2 Duo with Fedora 10 x86 installed.

If I run xev when things are OK, I only get events when the mouse moves over the pop-up window.  I'll try this the next time the mouse freezes, but if I cannot get the window moved under where the mouse is, it may not do much good.

grabtest when all is well successfully grabs both keyboard and mouse, of course.

Next time things freeze up, I'll thy the things mentioned here.

Comment 16 Robert Peterson 2008-12-06 00:01:12 UTC
I recreated the problem, then tried variations of:

xmond -verbose 4 -server :0 -port 4
xev

The xmond program seemed to receive nothing from any mouse clicks.
When I <ctrl-c> out of xmond, the resulting file is 0 length.
Also, when I run it interactively, it produces no output on the screen.
Either it's getting nothing or I'm doing something wrong.

Comment 17 Peter Hutterer 2008-12-08 00:30:21 UTC
(In reply to comment #16)
> I recreated the problem, then tried variations of:
> 
> xmond -verbose 4 -server :0 -port 4
> xev

Just for the archives (we already talked about that over IRC):
you need to run xev through the new display provided by xmond, i.e. DISPLAY=localhost:4 xev

Edward:
Some handy shortcuts we figured out today:
Alt+F7 is GNOME's default shortcut for move window.
Alt+F10 for maximise window.

Do you have a multi-monitor setup too? That seems to be Robert's issue. If you do, try moving the xev window around between the monitors and mouse functionality comes back at some point. Robert will post more detailed information on that soon.

Comment 18 Robert Peterson 2008-12-08 04:04:34 UTC
First, here is a detailed description of how to recreate the failure,
at least in my case:

You need to have more than one monitor.  I'm running xinerama so my
desktop is spanning between multiple monitors.  Also, I believe you
need to have auto-raise set on (no proof of this).  To set it on, do:
System->Preferences->Look and Feel->Windows, then check the box that
indicates "Select windows when the mouse moves over them".  Also, set
a half-second delay, so check the box next to "Raise selected windows
after an interval", and an interval value of 0.5 seconds.
Next, open a few windows on each monitor.  Then move your mouse cursor
back and forth a few times between the two monitors, briefly highlighting
the windows on each monitor.

Peter's description of the problem from a debug session earlier today:
"The server thinks that the sprite window is the root window, so it's
trying to deliver all events to the root window."

The Sprite window is the window underneath your mouse cursor.  The root
window is the very first grey window, the initial one with "X" displayed
when x is starting.

My theory as to what's going on:
Suppose I have monitor #1 and monitor #2.  Suppose I open a window on
monitor #2.  When I move my mouse cursor over the window, the auto-raise
timer of 0.5 seconds starts ticking.  During that time, I move my
mouse cursor to the other monitor.  After 0.5 seconds, auto-raise
tries to raise the window I last hovered over.  However, when it does,
the mouse cursor has been repositioned to monitor #1.  In other words,
there is no more sprite window because the mouse cursor is on a
different monitor.  So X loses track of the sprite window which appears
only on monitor #2.  Unable to find a valid sprite window, it defaults
back to the root window.  The root window cannot handle the mouse click
events, so they are ignored.  This is just my theory.

We did find a viable circumvention:
If you encounter this problem, use the keyboard to navigate around
the screen.  Use <alt><tab> to switch between windows.  Once you've
gotten to a window, use <alt><F7> to move the window from one monitor
to the next.  Then move it back again.  This seems to allow X to
re-sync its sprite window and mouse clicks are then processed correctly.

Comment 19 Robert Peterson 2008-12-08 04:07:29 UTC
Other possible circumventions:

1. Don't use auto-raise.
2. Don't use a delay for auto-raise (set value to 0)
3. Don't move your cursor until your windows are fully brought
   to the foreground.

Comment 20 Edward Kuns 2008-12-08 05:12:10 UTC
I don't have multiple monitors.  This is a laptop to which I have never (so far) connected an external monitor.  However, I do use auto-raise with an interval of 2 seconds.  With this clue, next time this happens I'll pay attention to what I was doing immediately before the mouse freezes.

Comment 21 Edward Kuns 2008-12-10 05:36:29 UTC
Hmm, my mouse just froze for the first time in a while.  I was able to use keyboard shortcuts to start Firefox.  But something about the process of navigating to this web site to get the full list of "to do" items woke the mouse up again.  I'll have to try next time, but wanted to put a note that my mouse finally froze up again, for a good part of a minute, while the keyboard and rest of the system were responsive.

Comment 22 Edward Kuns 2008-12-10 05:45:03 UTC
Ah, THIS time, /var/log/messages and dmesg have the following messages:

psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.
psmouse.c: resync failed, issuing reconnect request

This may be a different failure than what I've seen before, as /var/log/messages.* files don't have other occurrences of the above text.

Comment 23 Peter Hutterer 2008-12-15 00:16:14 UTC
Adding upstream bug reference.

Edward: please run xdpyinfo | grep root to get the the root window ID, then run xev -id <root id> when the problem occurs. Do you see events?

(In reply to comment #22) 
> psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3
> bytes away.
> psmouse.c: resync failed, issuing reconnect request

If that happens, the mouse should only stop for a second or so and then come back (unless it never came back of course).

Comment 24 Edward Kuns 2008-12-16 04:30:52 UTC
OK, I finally reproduced the problem, but the behavior was a little different from before.  From when I booted up, the mouse failed to do anything.  xev gave nothing.  Looking at /proc/bus/input/devices, I noticed that my two mouse devices were missing, and everything else was identical except for a few device numbers that of course changed with a few devices in the middle going away.  The following devices went missing:


I: Bus=0011 Vendor=0002 Product=0008 Version=0000
N: Name="PS/2 Mouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0002 Product=0008 Version=6337
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse2 event6 
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

I'll attach my demsg of my original boot tonight (where the mouse device was absent) and my 2nd boot tonight (where the mouse works as it should).  Unlike before, nothing could fix the problem, including going to a console and then back to X, logging out and back in, killing X with Ctrl-Alt-Backspace.  The only thing that helped was rebooting.

Comment 25 Peter Hutterer 2008-12-16 04:41:51 UTC
That would indicate that you have a very different problem than Robert, and chances are that it's kernel in your case.
Do you mind cloning the bug and attach your xorg.log (next time it breaks) and dmesg to the cloned bug? Let's leave this one for the multi-screen problem. Thanks.

Comment 26 Edward Kuns 2008-12-16 04:45:02 UTC
Created attachment 327058 [details]
dmesg from bootup where the mouse was non-responsive

Comment 27 Edward Kuns 2008-12-16 04:46:55 UTC
Created attachment 327059 [details]
dmesg from bootup where the mouse was responsive and normal

Comment 28 Peter Hutterer 2008-12-17 23:34:07 UTC
*** Bug 475945 has been marked as a duplicate of this bug. ***

Comment 29 Robert Peterson 2008-12-18 15:28:37 UTC
Peter and I worked on this problem some more.

My configuration is proprietary nvidia driver, two GEForce cards
and three screens (screen0=card0,0.  screen1=card0,1.  screen2=card1,0.)
All screens are running at 1280x1024 resolution, and I've got xinarama.

I can recreate the problem easily by dragging my mouse from screen1 to
screen2, which spans between the two nvidia cards.  During a gdb
debugging session, during which every slowed down, my mouse cursor
intermittently jumped from its current location (call it x,y) on screen1
to the same (x,y) on screen2, and back.

I tried to recreate the problem between screen0 and screen1 (staying
within the same video card) and was unable.  However, this morning the
problem recreated "by accident" between screen0 and screen1, and my
mouse cursor was no where near screen2.  So the problem is easily
recreated when switching between card screens and difficult (but still
possible) to recreate when switching between screens on the same card.

Yesterday, I was able to recreate the problem, even with auto-raise
turned off.  I just had to move the cursor from screen to screen and
click on windows instead of having auto-raise bring them to the top.

Peter seemed to think this is a scaling issue.

Again, once the mouse stops responding, the problem can be corrected
by using <alt-tab> to select a window, then <alt-f7> to move the window
to screen0 (and only screen0).  Once the mouse cursor is moved back to
screen0 via the keyboard arrow keys, the mouse starts working again.

Edward: This does seem like a different issue from the original problem
so maybe you should create a clone bug record.

Comment 30 Robert Peterson 2008-12-18 15:42:34 UTC
I just recreated the problem again between screen0 and screen1.
All I did was drag my mouse cursor slowly from screen0 to screen1.
When it got to screen1, the cursor still moved, but all other
functionality (auto-raise and button clicks) stopped working.

Comment 31 josef radinger 2008-12-22 14:33:35 UTC
exactly what happens with my system. and the "fix" works, too.

(In reply to comment #29)

> Again, once the mouse stops responding, the problem can be corrected
> by using <alt-tab> to select a window, then <alt-f7> to move the window
> to screen0 (and only screen0).  Once the mouse cursor is moved back to
> screen0 via the keyboard arrow keys, the mouse starts working again.
> 
> Edward: This does seem like a different issue from the original problem
> so maybe you should create a clone bug record.

Comment 32 Peter Hutterer 2008-12-22 22:40:29 UTC
We had another debugging session and it looks like the cursor rendering for animated cursors is at fault. If you step through it in gdb, the cursors actually jump back to the old screen for a fraction of a second. This confuses the internal screen variables and triggers the bug.

Can you try to recreate the bug by switching the cursor theme to something without animated cursors?

Comment 33 Robert Peterson 2009-01-05 17:41:28 UTC
I spent some time looking around for a non-animated cursor theme.
I didn't have much luck.  It's difficult to even tell which themes
are animated and which are not.  Also, I'm using gnome and it seems
as if most of the features for doing this seem to be kde-related.

Over the course of last week, I pulled both of my slow PCI nvidia
geforce fx5200 video cards out of the system and added a faster
9600GT pci-express card.  (So now I'm down to two displays rather
than three).  So far I haven't seen the problem with the faster
card.  If necessary, I can go back to the older config for debugging
purposes.  If not necessary, I'd rather keep my current configuration.
The problem is easy to recreate, given the other configuration, so
perhaps you can recreate the problem there with slower hardware.

I'll post again if the problem occurs with the fast video card.

Comment 34 Robert Peterson 2009-01-07 15:38:00 UTC
I did manage to recreate the failure once on my faster video card
yesterday, but it's not easy to do.

Comment 35 Peter Hutterer 2009-01-30 01:50:59 UTC
Finally tracked it down. Caused by a WarpPointer request that would reset the root window of the sprite. In Xinerama, there's only one protocol root window (but more in the server), so suddenly the sprite ends up on a root window that doesn't have any actual windows.

Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1092389
RPMS available from: http://koji.fedoraproject.org/scratch/whot/task_1092389/

Comment 36 Fedora Update System 2009-02-05 02:16:54 UTC
xorg-x11-server-1.5.3-10.fc10 has been pushed to the Fedora 10 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-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1308

Comment 37 Fedora Update System 2009-02-06 05:19:09 UTC
xorg-x11-server-1.5.3-11.fc10 has been pushed to the Fedora 10 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-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1390

Comment 38 Fedora Update System 2009-02-24 20:45:51 UTC
xorg-x11-server-1.5.3-13.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 39 Chris Underhill 2009-02-26 00:13:43 UTC
I'm hoping this also fixes bug 460793 as well, which has been bugging me since I upgraded to Fedora 9 over 6 months ago,

Comment 40 Maxim Egorushkin 2009-03-02 15:40:56 UTC
(In reply to comment #38)
> xorg-x11-server-1.5.3-13.fc10 has been pushed to the Fedora 10 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

I've been experiencing the same problem. The problem still persists with xorg-x11-server-Xorg-1.5.3-13.fc10.x86_64.

Can provide more info if necessary.

Comment 41 Peter Hutterer 2009-03-03 01:52:13 UTC
Maxim:
open a window, press alt+f7 to move it (if you're running metacity), then move the window with the cursor keys to the second screen. press enter to release the pointer - does the pointer work now? (same way to restore it, btw, just move the window back)

If not, this is the same problem (although I thought it'd been fixed). If it works, then what you are seeing is a different problem, please open a new bugreport for that.

Comment 42 Stephen Tweedie 2009-03-03 11:52:30 UTC
I had been seeing this occur once every 2 or 3 days since updating to F10, but am now at 10 days without issue using xorg-x11-server-Xorg-1.5.3-13.fc10.i386.  I'm using Xinerama over two DVI displays on a single card.  Looks good so far, I'll followup here if I see it occur again.

Comment 43 Maxim Egorushkin 2009-03-03 12:22:09 UTC
(In reply to comment #41)
> Maxim:
> open a window, press alt+f7 to move it (if you're running metacity), then move
> the window with the cursor keys to the second screen. press enter to release
> the pointer - does the pointer work now? (same way to restore it, btw, just
> move the window back)

This test works as expected.

> If not, this is the same problem (although I thought it'd been fixed). If it
> works, then what you are seeing is a different problem, please open a new
> bugreport for that.

Okay.

Comment 44 josef radinger 2009-03-03 13:45:52 UTC
seems to be fixed, as i no longer have that problem. thanks.

Comment 45 Chris Underhill 2009-03-04 00:33:29 UTC
As per my comment #39, this is now fixed for my setup - Hooray :-)

Comment 46 Thomas Jarosch 2009-03-17 10:23:08 UTC
The problem also affects Fedora 9 badly. We've been running Peter's patch for over a month now on five dual head workstations without trouble.

Would be nice if the patch would also be pushed out to other Fedora 9 users
as this really hurts productivity. Thanks!

Comment 47 Fedora Update System 2009-03-17 23:54:03 UTC
xorg-x11-server-1.5.2-6.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-6.fc9

Comment 48 Fedora Update System 2009-04-06 20:26:40 UTC
xorg-x11-server-1.5.2-6.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.