-   Linux - Hardware (
-   -   How to smartly reinitialize pointer device in X ? (

devdol 01-11-2007 10:01 AM

How to smartly reinitialize pointer device in X ?
Problem description: Sometimes (from hours to days) the mouse pointer freezes.

Current desktop environment: KDE 3.5.5 on debian/testing, Kernel 2.6.17.

  • The local desktop can then further be used via keyboard only, however some tasks get from awkward to impossible to do (pulling scrollbars, moving windows...).
  • Pointer arrow stays visible where it left off, just won't move any longer.
  • Interesting detail: when starting new applications, their "busy animation logo" can be moved by the mouse - hence, it's no hardware failure, and the "only" things missing are the connection between mouse movement and pointing arrow (movement) and click/wheel-events.
  • Keyboard continues to work, but often behaves strangely then (e.g. randomly shiftes letters unsoliticedly), in some cases after some minutes it fails too.
  • Remotely, the computer works faultlessly, remote vnc sessions get their pointer, too.
  • Possible problem context: locking and then unocking the screen seems to promote the risk of this failure (However, the desktop does not necessarily have to be idle to get the mouse frozen!)
  • As there are many similar reports in the usenet [Linux reinitialize mouse, resume i8042, ... ], and as I have been constantly experiencing this phenomenon for several months in spite of numerous daily package updates (it's a debian/testing box) I don't suppose this to be a matter of library or kernel versions or package incompatibilities (BTW I have both experienced it on xfree86 as xorg) nor windowmanager releases.
  • Of course you can restart the machine or kill X (by ctrl&alt&backspace), however this wastes a lot of time and you are likely to suffer from data loss.

Workarounds tested so far (all proved insufficient):
  • remove and replug USB mouse: does NOT help
  • plug in a second USB mouse: doesn't help (normally several mouse device will work as you might expect, adding up their input)
  • 'rmmod psmouse ; modprobe psmouse' (works, but does't reanimate the pointer)
  • change mouse and keyboard settings in kcontrol and apply changes: doesn't help either
  • change mouse hardware and port (PS/2 vs. USB): useless, too
  • change to a text terminal (ctrl&alt&fn[1..6]): may help, but only in few cases
  • just wait (half an hour or so): sometimes pointer reanimates spontaneously, but of course meanwhile you could have rebooted some times
  • "restart gpm": not applicable, as I don't have gpm installed

  • a decent method to reinitialize mouse and keyboard on demand without having to leave the current x session
  • sensible [non-voodoo] troubleshooting approach to enlighten what exactly is going wrong in those moments (have been looking beneath /var/log/* but didn't find anything flashy)
  • at least there also might be a chance to reduce those freeze events by changed system configuration - but what to try?

stan.distortion 01-11-2007 12:16 PM

I recently had trouble with keypresses missed or sticking, tried a lot of suggested changes with no change, they where all kernel related so I changed the kernel and that cured it. That was with a generic ubuntu 2.6.15-26-i386 kernel and changed to a 2.6.15-27-i686 ubuntu kernel. Doesnt sound like the same problem, trying a different kernel would at least make sure all is OK with it.
Could you give some more info i.e. Distro, kernel, hardware. Did something trigger this, an update or new hardware.
Can you also post back the 'InputDevice' or 'mouse' section from '/etc/X11/xorg.conf' and anything from the output of 'dmesg' to do with the mouse.
If you can find the device node for the mouse, usualy something like '/dev/input/mouse0' ('lsusb' should give you some info), you can try to read the raw output with something like 'cat /dev/input/mouse0' to see if the input side of things is working.


devdol 01-11-2007 02:28 PM

  • Distro: debian/testing (APT Default-Release "testing"; fairly using 'unstable' sources)
  • Kernel: currently 2.6.17 (compiled with CONFIG_INOTIFY=y, CONFIG_EXT2_FS_XATTR=y,CONFIG_EXT3_FS_XATTR=y, CONFIG_REISERFS_FS_XATTR=y, CONFIG_CIFS_XATTR=y, CONFIG_RTC=y), there has been 2.6.15 and 2.6.16 before, and I also tried debian's current default 2.6.18 kernel - with no notable difference.
  • Hardware: Fujitsu-SIEMENS ESPRIMO P
  • Did something trigger this, an update or new hardware: No. And changing mice didn't cure.
  • from '/etc/X11/xorg.conf' (which is all correct as far as I can see):
    Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "keyboard"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "de"
    Option "XkbVariant" "nodeadkeys"

    Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ImPS/2"
    Option "Emulate3Buttons" "true"
    Option "ZAxisMapping" "4 5"
  • dmesg | grep -i mouse
    input: ImPS/2 Logitech Wheel Mouse as /class/input/input3
    input: ImPS/2 Logitech Wheel Mouse as /class/input/input4
  • dmesg | grep -i -U4 -A4 mouse
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    input: ImPS/2 Logitech Wheel Mouse as /class/input/input3
    input: ImPS/2 Logitech Wheel Mouse as /class/input/input4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
    usb 5-5.4: reset high speed USB device using ehci_hcd and address 4
  • ll /dev/input/mous*
    3033511 0 crw-rw---- 1 root root 13, 32 2007-01-11 18:03 /dev/input/mouse
    Today it happened two times, each time the pointer reappeared within approx. 20 minutes.
    Strange, but 18:03 might be the timestamp of the second "reanimation".
    As those (slow) spontaneous recoveries may indicate that there is already something inside that cares for the reinitialization, the only thing missing is a mean to trigger it manually, having to wait just t << 20 min ,-)
  • #cat /dev/input/mouse0
    ▒�((▒▒▒8888(((((((((((((((((((((( ((((((((((8(8(88((((((((((((▒▒▒▒▒▒▒▒▒▒▒((((((((((((▒▒▒▒▒▒▒▒
    ((((((((((((((((((((((▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒
    Funny ;-) If I got you right I will try right that next time the arrow freezes.
    However, as I am able to move the "application start animation icon" with the mouse, I expect everything up to this level works fine.
    - Thanks so far!

devdol 01-18-2007 07:24 AM

The mouse has had left again -
#cat /dev/input/mouse0 behaved as above (i.e. no difference to normal operation; so the problem must be on a rather high level).

stan.distortion 01-18-2007 08:36 AM

Sorry for the late reply, the email notification doesn't always work for me.
The thread on the first link sounds like the same problem, unfortunately it means patching the kernel. From what i read in the thread it seems like an unusual signal from the mouse kills things for a while. It seems strange that you are having the same trouble with 3 different kernels though.
The patch wont be difficult to apply, getting all the dependencies for kernel-package will probably be the hardest part.
If you don't want the hassle it could be worth using alien on a redhat kernel package to see if that makes a difference, you will need to edit /boot/grub/menu.1st by hand after installing the generated package.
good luck with it.

stan.distortion 02-10-2007 03:06 PM

Does that machine have a touchscreen?

hacker supreme 02-11-2007 12:47 PM

I kept losing my mouse pointer every time it locked the screen to enforce a typing break. The only way I could get it back was by manually cycling the power. (No, I would definitely not recommend that)

(Ubuntu 5.10)

I'm not sure if it still happens in 6.06LTS and I'm not really willing to try. :D

devdol 02-12-2007 09:05 AM

Thanks to you all, some additional bits of information:
* No, I don't use a touchscreen.
Hardware is a Fujitsu-SIEMENS Esprimo P5905 with Intel945G chipset,
and the mouse supplied with it (an FSC branded Logitech M SFB-96), attached to PS/2;
tried already some instances of them (so no hardware defect is to be suspected).
Some hours before I changed to a new Logitech Cordless Mouse, attached to USB tentatively.
* The situation after screenlock is notably more common to lose the pointer for me, too!
* When the pointer is lost, starting a VNC session from another machine seems to accelerate
pointer's comeback, which would otherwise take about half an hour.
* When the pointer is lost, if Ctrl+Alt+Del is pressed, the "end session"-Dialog gets stuck
and screen stayes grayed whatever you do (this is strange, because *normally*
you can move between the buttons by TAB and use SPACE instead of a mouse click!).
It's extremely unhappy, as it blocks the only way for a neat reboot
without destroying the session. To make it even stranger, in spite of that blockade
you can fetch the Taskswitch window as normally by using ALT+TAB, however, you can't get
through to any window.

stan.distortion 02-12-2007 09:49 AM

Thanks for the reply, it relates to another problem, not the answer I was looking for though :)
Sorry to keep saying the same thing but it still seems to relate to the kernel, more accurately the integration of the mouse drivers into the kernel.
Try whichever of these you have in /dev next time it locks up:
od /dev/input/mice
od /dev/input/mouse* (0,1,2 etc)
od /dev/psaux (or /dev/input/psaux)
od /dev/input/event* (0,1,2 etc)

/dev/input/mice would be the important one as that is what is in xorg.conf.
As you already tested the output of /dev/input/mouse0 it could be a good idea to replace /dev/input/mice in xorg.conf with this node, it would be better to test each first though.
There is a usefull howto here:
It may be more usefull to you, especially the section on setting up xorg.conf


devdol 07-11-2007 06:39 AM

Dear Stan, yesterday it happened again. After the mouse locked up, al of the 'od $DEVICE' calls mentioned worked, i.e. they lively produced output when I moved the pointing device (while the mouse arrow was frozen). Especially /dev/input/mice did so.
Unfortunately I did not redirect it info files, and few minutes later the keyboard was dead, too - even "numlock", "capslock" etc. became unresponsive. Hence I lost the details, but meanwhile I'd also feel both pointing to xorg.conf.

To change only one single item after another, I hopefully want to update my kernel first today. If the phenomenon persists, I will post here again.

Kahless 07-12-2007 12:58 AM

You might try using gdm..... if nothing else, it gives you another troubleshooting step to try... flipping over to a virtual terminal to see if the mouse is working there.

devdol 07-13-2007 04:37 AM

Friday 13, mouse frozen again.

I'll reboot soon, because I have found that some minutes later keyboard tends to freeze, too (as it did few days ago).

But before, according to Kahless, I started gdm (as root) and, after choosing display # 1 instead of 0, I got a perfectly working gdm login followed by another KDE session on Terminal 8 (while the first one continues to live on Terminal 7).
The mouse is working without any problems on Display 1, while it does not on Display 0. Here the arrow is shown, but does not move.

Flipping between the displays (and the text terminals) doesn't change anything.

We already know that it is NO HARDWARE PROBLEM, in accordance with
1) 'od /dev/input/mice', 'od /dev/input/mouse', 'od /dev/psaux (or /dev/input/psaux)' and 'od /dev/input/event* (0,1,2 etc)' giving normal output
2) starting an application brings up it's icon, which can be moved by mouse movement just as normal

It's just the "software mouse pointer" (whatever this may be in detail), which someway suddenly stops to track the devices output. Locking the screen and unlocking it seems to favor this phenomenon, but it is no neccessary precodition. The freeze may also happen like a bolt from the blue.

So the only question unanswered is the very first I posted here:
"How to smartly reinitialize pointer device in X ?"

As stated above, in some cases the pointer restores in a self-acting way (i.e. without any user interaction), but this takes quite a long time - half an hour or longer. Whatever is happening there should be able to be triggered manually to get back a working desktop if necessary.

By the way: playing around with mouse and keyboard settings in kcontrol does NOT restore the pointer, as one might suspect :-/

devdol 07-18-2007 09:21 AM

Addendum: Running Kernel from linux-source-2.6.21 did not change the phenomenon.
After few hours the mouse pointer disapeared again (and restored some half an hour later).
So far concerning the 'kernel-related' assumption. Don't know what to try else.

devdol 08-30-2007 06:07 AM

Running Kernel 2.6.22 and using "LeadTek GeForce 6200 LE", Driver Modules: "nvidia", XFree86 v4 Server Module: nv
now - mouse cursor froze again (and restored somewhat 10 minutes later)...

fpflug 09-17-2007 10:56 PM


I'm having the same problem with a logitech cordless trackball.
It freezes really frequently and the only solution is un- and re-plug.

I'm running openSuse 10.2 x86_64 (i didn't have this problem with X86 32 bit, same mouse).
KDE 3.5.5 "release 45.4"

I have tried different setups for the mouse, even "generic". Result is the same.


Section "InputDevice"
Driver "mouse"
Identifier "Mouse[1]"
Option "Buttons" "4"
Option "Device" "/dev/input/mice"
Option "EmulateWheel" "on"
Option "EmulateWheelButton" "4"
Option "Name" "Cordless Trackman FX"
Option "Protocol" "ExplorerPS/2"
Option "Vendor" "Logitech"
Option "ZAxisMapping" "4 5"

ASUS P5 N32 SLI Premium
Pentium Quad 6600
HD Sata2 500gb
ATI x1550 512MB 3D active
Belinea 22" - 2225S1W

All times are GMT -5. The time now is 03:30 PM.