No more mouse events after using rdesktop

[jmspeex]

Binary package hint: xorg

I'm running Ubuntu Dapper and "sometimes" X just stops sending any mouse events (or so it seems). This usually seems to be triggered by using rdesktop. At some point, my desktop becomes unusable. I can see the mouse pointer move, but I can't click on or interact with anything. If I manage to get the focus to a window, the keyboard works fine. Restarting metacity, gnome-panel, nautilus, ... doesn't seem to change anything. Usually, I end up killing X to get things working again. ...except the last time, I was able to start a new terminal using the keyboard only and it "unlocked the mouse" -- and everything started working fine again.

There is no simple step to reproduce the problem, but rdesktop seems to make it happen more often. I have confirmation from another use who observed the same kind of behaviour on his machine (also seemed rdesktop-related).

Also happens with Feisty.

[Alex Selby (launchpad-archduke)]

I've got what I think is the same problem, as mentioned at
http://ubuntuforums.org/showthread.php?t=255898
The pointer is movable, but it can't be used to click in anything, so you are usually stuck with having to restart X. On one occasion I managed to cure it by logging in via a remote terminal and killing Firefox (the application I clicked in which appeared to provoke the problem).

For me it is usually happens when using Firefox, but I believe I've seen it with another application, so I don't think it is Firefox's fault (though it's hard to be sure either way).

I'm also wondering if the bug reported at
https://launchpad.net/distros/ubuntu/+bug/52380
is the same thing.

[jmspeex (jean-marc-valin)]

Well, Firefox (and rdesktop in my case) may (or may not) be buggy, but in any case the X server should contain the bug to these applications instead of causing the whole system to be unusable.

[jmspeex (jean-marc-valin)]

Yet another user affected by this bug. See blog post http://www.advogato.org/person/berend/diary.html?start=286
Considering there's no way to get out of this except doing a "ctrl-alt-backspace", this is *really* annoying.

[Alex Selby (launchpad-archduke)]

I've noticed a workaround. Pressing Alt-Tab a few times seems to cure it, which is quite a relief.

By the way, I'm using focus-follows-pointer (System->Preferences->Windows, Select windows when the mouse moves over them). I'm wondering if everyone who experiences this bug has focus-follows-pointer.

[jmspeex (jean-marc-valin)]

I've got focus-follows-pointer as well. I'll try Alt-tab next time I get the bug. I also found this page http://www.jwz.org/xscreensaver/changelog.html and started thinking it it could actually be screensaver-related because it usually happens after a bit of idle time. Have you seen the same thing?

[Alex Selby (launchpad-archduke)]

No, for me it always happens when I'm actively using the computer. In fact, it mostly seems to happen following some rapid mouse clicking.

I bet focus-follows-pointer is a necessary condition to trigger the bug. That would explain why lots of other people haven't noticed it. f-f-p is probably a minority choice, and there are probably other necessary conditions too which we don't know about which further reduce the prevelance of this bug (e.g., my graphics driver is mga).

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Do you still have this issues with the latest release of Ubuntu ? Thanks

[jmspeex (jean-marc-valin)]

Although it happens less often, it has happened to me with Feisty on my new (x86-64) machine. I was in the middle of an IRC meeting so I couldn't logout. It took maybe 30 minutes to the X server to release the mouse from it's weird state. This behaviour is very annoying. I get the choice between killing all I have on my desktop (and any unsaved work) or wait for ~30 minutes hoping the X server will automatically un-b0rk itself.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Ok, thank you for answering. Can you attach here your /etc/X11/xorg.conf file ? Thanks.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Is this still happening with an updated Feisty ?

[jmspeex (jean-marc-valin)]

Yes. See my above comment. It's not as bad, but it definitely has happened to me with Feisty.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

And still happens ?

[Bryce Harrington (bryce)]

Marking as triaged since user has confirmed it still exists in Feisty. Thanks for reporting this issue.

[Gian Luca Rossetti (glrossetti)]

Same problem for me, I'm running Feisty with Xgl and Compiz. My Xorg.conf on attachment.

[lundse (lundse)]

I have this too. I am using kubuntu feisty with KDE.

But I am not using focus follows pointer, and there is another twist. This has just happened, and keeps happening 3-5 secs after plugging in my usb-wireless mouse. Disconnecting the mouse has my touchpad working normally, after plugging in the mouse both mouse and touchpad start exhibiting the behaviour described above. Restarting everything makes no difference.

[lundse (lundse)]

Quick addition - I just noticed that after plugging in the mouse, it still works normally _but only within the original area_. For instance, I have just connected the mouse and can now select text, click around, etc. within this text box - but all other clicks and mouseover events are ignored (also with mousepad).

And another - this did not follow any update or other system change.

[Martin Harvan (martinhrvn)]

okay I started having the same problems as mentioned here... I noticed that most often it happens when I drag the window icon in workspace switcher, or in windows list... switching between workspaces couple of times seems to recover the mouse...

[Martin Harvan (martinhrvn)]

I have another occurence of this problem. It seems to me as gnome focus problem.

I opened a text file from nautilus in gedit and when I was trying to select a text it dragged a file (that in nautilus window below gedit window) mouse stopped clicking completely (it moved however). I killed gedit first nothing changed mouse still didn't click but after I killed nautilus and switche back to gdm it was working normally...

[lundse (lundse)]

I'm running kubuntu, so it can't be gnome, can it?

On 9/19/07, Martin Harvan <email address hidden> wrote:
>
> I have another occurence of this problem. It seems to me as gnome focus
> problem.
>
> I opened a text file from nautilus in gedit and when I was trying to
> select a text it dragged a file (that in nautilus window below gedit
> window) mouse stopped clicking completely (it moved however). I killed
> gedit first nothing changed mouse still didn't click but after I killed
> nautilus and switche back to gdm it was working normally...
>
> --
> No more mouse events
> https://bugs.launchpad.net/bugs/55739
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Kristian Lund
Phone: [phone]
Primary email: <email address hidden>
Blog: http://kirkeanmeldelser.blogspot.com
Address: Mejlgade 36a, 2 - 8000 Århus C, Denmark

[Martin Harvan (martinhrvn)]

than it has to be something else - X maybe?

[Gomez (pinecone)]

I am getting very similar problems on my new system,
MB: Asus P5k-e
VID: Asus EN7600GS Silent (Nvidia)
MEM: Corsair XMS2 2x2GB DDR2-800
CPU: Intel Core 2 Quad 2.4GHz

except in my case, even the keyboard goes out, forcing me to hard reset. as in the other cases, my mouse still moves, but i cannot click.
it is strange, it is like my keyboard just turns off, because the lights go out on it. unplugging the devices and plugging them back in doesn't work.

I have since replaced both keyboard and mouse, with no luck.

a large thread of people who have a problem, (some only the mouse goes out, others the keyboard too) and a lot of trouble shooting happens in this thread that someone might find of interest:
http://ubuntuforums.org/showthread.php?t=568023

[Timo Aaltonen (tjaalton)]

Try killing the screensaver from a virtual terminal (ctrl-alt-f1 etc). I remember some similar issues with dapper, but never since.

[Gomez (pinecone)]

just happend again, and i was not able to enter that command, or any for that matter, since my keyboard was also out.
I tried disabling the screen saver all together, under system>preferences, with no luck, it still happened.

It seems to happen 80% of the time (i can remember) wile using fore fox.

i will start to take note of running processes while it happens.

[Timo Aaltonen (tjaalton)]

Eh, if your keyboard is not functioning that means that the server is hung. Please look for a dupe on the bug list for your video driver.

[jmspeex (jean-marc-valin)]

When I get hit by that bug, I generally can't type anything because the keyboard focus isn't on any window. However, typing Alt-F2 (or whatever brings up the run dialog) actually works. From there, I can start a terminal that will actually get the focus. This is of course of limited use because the mouse events still don't work and I have no way to change the focus.

[Timo Aaltonen (tjaalton)]

Ok, that sounds like a real issue then. Try running Hardy alpha3 livecd for a while to reproduce the issue.. there has been a lot of input related changes in xserver 1.4

[stanley82 (stanley82)]

I have a similar but different mouse problem. Install gutsy from 32 bit ISO file and no mouse control. It was okay with win98 and Xandros. I repeated with edgy and got edgy up and running did the updates followed by system upgrade to Feisty and bingo no mouse. I'll try alt tab and thanks if that works.

[stanley82 (stanley82)]

If you go to https://wiki.ubuntu.com/DebuggingMouseDetection it asks all sorts of info obtained from the terminal. In Ubuntu how do I open a terminal with a dead mouse?

[Bryce Harrington (bryce)]

stanley82, if your issue is not exactly like the original bug reporter's, it would be helpful if you would file your issue as a new bug report. Please see https://wiki.ubuntu.com/X/Debugging for some tips on what files and info to include.

One way to get to the command line even when the mouse is not working is to switch to the console, by ctrl-alt-f1 or ctrl-alt-f2.

[jmspeex (jean-marc-valin)]

OK, it happened again to me (on Gusty), while I was using Thunderbird and I was able to get more info. First interesting thing was that trying to run "xkill" gave me:
xkill: unable to grab cursor
That was interesting, because it occurred to me that the cursor was indeed grabbed by something else. What's interesting is that all the mouse events were going to the text area of my compose window. I could select text there and use the scrollwheel, but I could not click on anything outside that text area (not even buttons in the same window). Also, the keyboard didn't go there, so I couldn't actually type anything. After I managed to kill thunderbird and open a terminal, I ended up with an "interesting" situation: the keyboard focus was going to that terminal, but the mouse focus was actually going to the pager. For instance, despite having the mouse pointer inside the gnome-terminal window, if I used the scrollwheel, I would change desktop!

At that point, I thought it was a window manager issue, but restarting metacity didn't work. Normally, when the bug happens, I need to log out and log back in again to get things to work. This time, even when I was logging back in, the bug was triggered again very quickly (things worked for a few seconds and then stopped working) and I eventually had to reboot the machine. Note that at no time was I using rdesktop, so I don't think it's an rdesktop problem after all. Looks more and more like an xorg problem.

Hope this helps finally resolve the problem.

[Chase Venters (chase-venters)]

I have the same problem. I'm using Kubuntu 8.04 with KDE 3.5.9. I also had this behavior with older versions of Kubuntu. I do not use rdesktop on my laptop, so I believe that it is unrelated.

When I lose mouse control, I can move the mouse around but can't click anything. Sometimes, I can right click and bring up a context menu which rescues the system. Sometimes it seems that the mouse can only affect some particular window in the system. Sometimes, doing a few VT-switches will recover the pointer, but not always.

[jmspeex (jean-marc-valin)]

It is probably related. It happens to me with other apps than rdesktop. I think the title should be changed.

[Niels Egberts (nielsegberts)]

I think I'm having the same issue in Intrepid Beta 1. It happens a lot if I rapidly drag around with my mouse on my desktop, but sometimes its just random. I am able to use my keyboard and move my mouse, but clicking does not work. I'm not using rdesktop.

[Gregware (gregware)]

Hello, I'm a simple user of ubuntu (graphic designer), I do not know what is rdesktop but this bug affect me and it is randomly.
It is very annoying me, between 30 minutes or 2 hour, I need to disconnect my session with my keyboard to be able to use my mouse again.

I'm using two screen: One CRT 19" Ilyama Vision Master Pro 451 and the other one is the screen of my laptop Acer Aspire 7720. The two screen have differents definitions and sizes.

My version of ubuntu is 8.10 and this was not happening with previous version 8.04 (I did the upgrade by using synaptic).
Every time this occur when i'm using Firefox, gedit, FileZilla, Evolution and Emesene.

Thank you for your help.

[Gregware (gregware)]

Ok I'm confirming I've did a test after reading the previous comments;
This append systematicaly if i move my cursor freneticaly.
Hope it could help you.

[Thomas Leonard (tal-it-innovation)]

I'm having this problem several times a day since upgrading to 8.10 (all previous versions were OK).

I use focus-follows-mouse and two screens. Window manager is Ion 3.

I mainly run Firefox, Evolution, xterm and Vim. The mouse moves and the keyword works fine (including changing focus), but clicking the mouse has no effect and the focus doesn't change as the mouse moves. Looks a lot like as if someone has a pointer grab.

I have tried killing off X clients from an xterm, but nothing seems to help reliably. I can't switch to VT1 with 8.10 (it's just blank). Control usually returns eventually. Restarting the window manager works sometimes but not always. Running xkill (as suggested here) seemed to fix it once (will try again next time it happens to see if it's repeatable).

[jmspeex (jean-marc-valin)]

OK, question to Ubuntu devs. Is there someone actually interested in investigating this? If so, please list anything that would be useful to check when the bug occurs (about once a month for me with 8.10).

Some additional info. The last time this bug (or something very similar -- hard to say) occurred on my machine, even restarting X wouldn't work. Investigating more closely, I realised that the focus was always "stuck" to one one window -- or part of a window. For example, at one point, the focus was on the desktop switcher in the panel. It would respond to clicks and everything, but nothing else would. Then I killed the panel (it auto-respawned) and suddenly, the focus would follow the mouse again (I would see the window title bars change colour). But as soon as I clicked on a certain window, it would grab the focus forever until I killed it. Killing the window manager usually does not help. Restarting X sometimes works, but the last time, it didn't and I actually had to reboot the machine.

[tebeka (miki-tebeka)]

Same problem for me on 8.10.
2 screens with Xinerama , nvidia driver 177.80

Attaching xorg.conf

[Justin Mazzola Paluska (jmp-mit)]

I've been experiencing the same problem (8.10, 3 screens with Xinerama, nvidia 177.80).

I can also confirm that I get the same problem with or without focus-follows-mouse.

Usually I get out of it by logging out (Ctrl-Alt-Del, then Alt-L to log out). I've tried killing naultilus and metacity to no avail.

If anyone thinks they are useful, I have .xsession-errors logs and verbose metacity logs of when the bug happens.

[Gregware (gregware)]

Hello, for me this happend ONLY when my second screen is plugged-on.
With only one screen the bug never appear.
I did install Compiz and compiz do not work when a second screen is plugged-on, I will try to uninstall compiz to see if problem persist or not.

[Bardur Arantsson (bardur-arantsson)]

Yup, I can pretty much just echo what the others are saying. This seems to happen ONLY with Xinerama enabled -- when I don't enable Xinerama it doesn't occur. First I thought this had something to do with mouse grabbing since it only happened (for me) in VirtualBox and KVM, but now it seems that the trigger (at least for my system) is simply high CPU load.

I've tested with KDE4.1.2 and xmonad, both display exactly the same symptoms -- everything runs normally, but X does not receive mouse events (as reported by xev). In the logs, there is no indication that the mouse has disconnected or anything else -- it just quietly stops working.

[Bardur Arantsson (bardur-arantsson)]

Oh, I forgot: I've never had this problem up until the current (or maybe the previous?) X.org version -- all the ones before that have worked flawlessly.

[tebeka (miki-tebeka)]

FWIW switching to XFCE seems to solve the problem (running 2 days now)

[Phil (phil-hopkins)]

I too am having the problem. Running Intrepid Kubuntu (new install), Nvidia 177.something, dual monitors and Xinerama
. System does this 3 or 4 times a day. I tend to have 10 Firefox windows open plus several others.

[Mal (mal-cybersanitarium)]

I'm getting this problem too. Just upgraded to Intrepid. Graphics driver is nVidia 177.80. I'm also running a Xinerama setup with two graphics cards and three monitors.

The problem occurs about 50% of the time when I run a game (Quake 3, etc) after it quits. It's also happening with my own project that uses OIS for input from a joystick, but doesn't initialize any mouse input. It stops happening when I remove the input code from the project entirely.

Worked fine in Hardy. Started having problems when I upgraded to Intrepid.

[Phil (phil-hopkins)]

I solved my problem, disabled xinerama and used Nvidia TwinView. No more
issues. from my perspective this is a problem in the buggy xinerama code.

Phil

On Thu, Nov 20, 2008 at 8:06 PM, Mal <email address hidden> wrote:

> I'm getting this problem too. Just upgraded to Intrepid. Graphics driver
> is nVidia 177.80. I'm also running a Xinerama setup with two graphics
> cards and three monitors.
>
> The problem occurs about 50% of the time when I run a game (Quake 3,
> etc) after it quits. It's also happening with my own project that uses
> OIS for input from a joystick, but doesn't initialize any mouse input.
> It stops happening when I remove the input code from the project
> entirely.
>
> Worked fine in Hardy. Started having problems when I upgraded to
> Intrepid.
>
> --
> No more mouse events after using rdesktop
> https://bugs.launchpad.net/bugs/55739
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "xorg-server" source package in Ubuntu: Incomplete
> Status in "rdesktop" source package in Debian: New
>
> Bug description:
> Binary package hint: xorg
>
> I'm running Ubuntu Dapper and "sometimes" X just stops sending any mouse
> events (or so it seems). This usually seems to be triggered by using
> rdesktop. At some point, my desktop becomes unusable. I can see the mouse
> pointer move, but I can't click on or interact with anything. If I manage to
> get the focus to a window, the keyboard works fine. Restarting metacity,
> gnome-panel, nautilus, ... doesn't seem to change anything. Usually, I end
> up killing X to get things working again. ...except the last time, I was
> able to start a new terminal using the keyboard only and it "unlocked the
> mouse" -- and everything started working fine again.
>
> There is no simple step to reproduce the problem, but rdesktop seems to
> make it happen more often. I have confirmation from another use who observed
> the same kind of behaviour on his machine (also seemed rdesktop-related).
>
> Also happens with Feisty.
>

[tebeka (miki-tebeka)]

Upgrading to the latest driver version (177.82) sees to help a bit (not as much freezing and freezing stops after a while).

My problem is that TwinView do not support the highest resolution of my screens (also couldn't configure it for two *rotated* screens).

[Mal (mal-cybersanitarium)]

I switched from Xinerama to Twinview and the reported issues have gone away. This isn't an ideal situation because I'm down one monitor now, but at least my machine is usable again.

I have (or had) three monitors across two graphics cards, and Twinview only supports two monitors on one card.

[Thomas Leonard (tal-it-innovation)]

Locking the screen with xscreensaver and then immediately unlocking it seems to fix the problem too.

[Brad Clements (bkc)]

I have this same problem, mouse cursor moves but no longer responds to click action.

I was running 7.04 w/ ion3 on this hardware (2 nvidia cards, 4 monitors). yesterday I went through 2 upgrades to get to 8.10, also switched to awesome window manager (both 2.x from repository and now trying 3.x from source).

Attached is my xorg.conf

I have experienced lockups trying to drag vmware workstation from one screen to another, or just dragging firefox or even just fiddling around trying to learn awesome.

to recover I have to login via ssh and restart gdm (ctrl-alt-backspace doesn't seem to work for me anymore)

I'll try xscreensaver next time.

[Brad Clements (bkc)]

doh, just locked up again. I started vmware workstation 6.5.1 and then started a virtual machine. As the virtual machine came up, the mouse "lockup" occured again.

Interestingly, the keyboard is also affected. For example, given screens 1 to 4, vmware is running on screen 4, I have some xterms in screen 3.

the keyboard focus appears to stay on screen 3, where I can use META3 (left alt) + j to toggle between the two visible xterms (using awesome 3), but META3-1 (2 3 4 etc) does not change tag selection, and CTRL-META3-k does not move to the next screen.

strange that some key combinations work, others do not.

As I move the mouse cursor around, when I get to screen 1, the cursor changes from pointer to a text cursor on certain areas of the screen. There seemed to be at least two horizontal rectangles (not full width) on screen 1 where the cursor changed to a text cursor. The shapes of the areas did not look like any other window on any screen.

I was able to use gnome-screensaver-command -l to get all black screens, but I could not use the keyboard to get logged back in. Pressing enter did nothing, pressing escape would beep at me.

I ssh'd in and used gnome-screensaver-command -d to turn off the screensaver, the mouse and keyboard are still messed up.

I was able to shutdown vmware, but the mouse did not return to normal.

I had to restart gdm.

I guess I will try switching to metacity for a while in case it's an awesome thing, though I doubt it is.

btw, starting that vmware instance pegs the cpu % use and cpu load goes up and up, lots of wait state time due to a not-so-fast raid 1 configuration I think. Maybe that is a clue..

I am using a usb logitech mouse and a usb fingerworks igesture pad. Unplugging the igesture pad and replugging did not fix the problem, though the event was noted in xorg.log in real-time.

[Brad Clements (bkc)]

Need to clarify that screen 1 did not have any windows on it, so having the mouse cursor change from pointer to text cursor on that screen is pretty strange.

[Nick2000 (monpetitbeurre)]

I am running 8.10 64bit and am also experiencing this symptom. I am using a default Gnome desktop and visual effects set to NONE.
The lockup usually happens when I lock the screen (System->Lock screen). At this point, it does NOT lock the desktop, the keyboard works but the mouse clicks are ignored. I am not using focus-follow-pointer so it is hard to switch to any other window. Note that I have a rdesktop window opened to a WIndows 2003 server but I was not actively using it.

If the rdesktop window was active, the only way to get back to the desktop using only the keyboard was for me to quit remote desktop then use Ctrl-Alt-Del to bring the lockout/switch user dialog in which I pick "switch". Mouse clicks are restored after I log back in. In short, I can get out of it without restarting X or gdm but it is very annoying.

I do not know if it is related, but the last entries in dmesg are:
[ 162.479858] /dev/vmmon[7673]: PTSC: initialized at 2397592000 Hz using TSC
[ 244.108255] /dev/vmnet: open called by PID 7698 (vmware-vmx)
[ 244.108749] device eth0 entered promiscuous mode
[ 244.108785] bridge-eth0: enabled promiscuous mode
[ 244.108787] /dev/vmnet: port on hub 0 successfully opened
[ 7832.427517] mtrr: no more MTRRs available
[ 7840.554671] mtrr: no MTRR for d0000000,10000000 found
[ 9379.672345] mtrr: no more MTRRs available
[ 9741.731440] mtrr: no MTRR for d0000000,10000000 found
[10040.235696] mtrr: no more MTRRs available
[10401.996401] mtrr: no MTRR for d0000000,10000000 found
[10807.994306] mtrr: no more MTRRs available
[10814.987067] mtrr: no MTRR for d0000000,10000000 found

and it happened 4 times. I cannot see how there could be a link with MTRR but...

Nicolas

[scottyucsd (smarshall-visiontree)]

One way that I've found to regain mouse clicks is to enable "Mouse Keys" and move the cursor with the mouse keys for a second or two. It seems to beat the mouse back into submission for at least a little while. You guys should consider yourselves lucky though. I run synergy on my machine and probably 1 in 3 times that I move between systems I'll lose mouse clicks. It happens at least 50 times a day.

[Benjamin Montgomery (bmonty)]

I can echo most of the experiences that others are voicing above. I'm using the x64 version of Intrepid, I run two NVidia cards with 4 monitors and xinerama enabled. X will randomly stop responding to the mouse though the cursor still moves. THis happens with the mouse connected with both PS/2 and USB connectors. The only way I've found to fix it is to ctrl-alt-backspace the server.

[Tish (tihomir-plachkov)]

I am experiencing the same bug. Shortly Kubuntu 9.04 32b. Dell xps m1530 NVIDIA 8600m GT. Nvidia driver version 180.51. I am not using mouse following focus. Sometimes it happens randomly but I can reproduce the bug on regular basis. When trying to change the screen brightness directly from the power-management tool in my system tray it always messes up my mouse. The mouse can move but the clicks are ignored. The keyboard is active after launching konsole and typing xkill the respond is "....unable to grab the cursor". Soft restarts brings my cursor back.

[Dmitry V Shurupov (shurup)]

Confirming this bug for Jaunty, Xorg 1.6.0, nvidia drivers 180.44, Xfce 4.6.0. However, I was getting it on GNOME since Ubuntu 8.04 (with previous versions of Xorg and nvidia drivers).

Also, I've just noticed this messages in dmesg when the problem had occured:
[ 6922.520740] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 6
[ 6922.524015] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.
[ 6922.525052] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
[ 6922.526124] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
[ 6922.537229] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.

Not sure that's the reason but it seems it can be something relative to the problem. However, it's the first time I've noticed these errors (can't recollect whether I've looked into the dmesg before).

When it happens, xkill is telling me that it's "unable to grab cursor", as it was said above. That's for sure.

It doesn't seem to happen with any specific applications -- however, I have Firefox running almost anytime.

PS: Using Sony Vaio VGN-FE31ZR if it matters.
PS2: My xorg.conf is attached.

[Dmitry V Shurupov (shurup)]

As I have learned, the "GlidePoint lost sync" messages are really connected with this problem. They appear in my dmesg every single time this bug occured.

[Tish (tihomir-plachkov)]

Yes, I confirm Dmitry's post. I also checked my dmesg output. As I said I am reproducing the bug on a regular basis playing with the slider of screen brightness of power management applet in KDE( battery monitor ).

[ 3013.254604] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3013.271121] psmouse.c: GlidePoint at isa0060/serio1/input0 - driver resynched.
[ 3013.272972] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3013.274750] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3013.276648] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3013.802230] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
[ 3014.897010] psmouse.c: resync failed, issuing reconnect request
[ 3015.973623] synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume
[ 3016.738756] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input14
[ 3016.780409] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input15
[ 3018.562720] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3018.564888] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
[ 3018.570117] psmouse.c: GlidePoint at isa0060/serio1/input0 - driver resynched.

[Mike C. (mchasse73)]

I have the same problem I get constant messages in /var/log/messages

Aug 11 07:47:25 cryptonite kernel: [56108.792815] psmouse.c: bad data from KBC - timeout
Aug 11 07:51:51 cryptonite kernel: [56374.595857] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Aug 11 07:51:51 cryptonite kernel: [56374.596956] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Aug 11 07:51:51 cryptonite kernel: [56374.598022] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Aug 11 07:51:51 cryptonite kernel: [56374.599108] psmouse.c: GlidePoint at isa0060/serio1/input0 lost sync at byte 1
Aug 11 07:51:51 cryptonite kernel: [56374.608842] psmouse.c: GlidePoint at isa0060/serio1/input0 - driver resynched.

How I have managed to deal with it is to make sure I open a terminal window on one of my desktops and just unloading and reloading the driver, which get's everything working right again. It's a lot better then reloading X or rebooting. It happens mostly in
Firefox, but I have noticed it in other apps as well. It would be nice if there was an update from ubuntu since there seems to be a lot of people having the same problem.

modprobe -r psmouse
modprobe psmouse

Platform info:

Sony Vaio VGN-SZ340P
Linux cryptonite 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:54:56 UTC 2009 i686 GNU/

[Dmitry V Shurupov (shurup)]

Updated to Kubuntu Karmic. Still getting this problem. That's what I can see in /var/log/messages at such moments (just like it was before):

Nov 30 19:21:30 ubuntop kernel: [41663.207994] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 6
Nov 30 19:21:30 ubuntop kernel: [41663.209067] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
Nov 30 19:21:30 ubuntop kernel: [41663.212334] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.
Nov 30 19:21:30 ubuntop kernel: [41663.213397] psmouse.c: GlidePoint at isa0060/serio4/input0 lost sync at byte 1
Nov 30 19:21:30 ubuntop kernel: [41663.223928] psmouse.c: GlidePoint at isa0060/serio4/input0 - driver resynched.

[penalvch (penalvch)]

jmspeex, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Daniel van Vugt (vanvugt)]

The Debian bug says it was fixed in 1.5.0-3+cvs20071006, maybe slightly earlier.