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.
Workarounds tested so far (all proved insufficient):
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.
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).
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.
Does that machine have a touchscreen?
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)
I'm not sure if it still happens in 6.06LTS and I'm not really willing to try. :D
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.
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/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
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.
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.
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 :-/
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.
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)...
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.
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 01:20 AM.|