I experienced a few times that the mouse curser starts to move downwards on its own (i.e. without the mouse being moved). When it reaches the bottom of the screen it stops there but if I want to use the mouse to move it upwards it returns to the bottom again. It makes it impossible to hit any buttom. In particular I cannot shutdown the system so I am forced to do a hard reset. Supposedly this happens after I hit a certain shortcut unintentionally (maybe simmilar to Ctrl+Alt+V which I use for klipper frequently). Does anybody know the shortcut and how can I deactivate it?.

How fast is this downward movement?
Assuming the keyboard is still fully workable, does using Alt + F2 to open a terminal work?

If so, try running the following:

Code: Select all

kquitapp kwin

This will cause KWin to exit. If your mouse returns to normal, then KWin is the cause of the issue, if it does not return to normal, then another application (possibly X) may be causing this. You can run the following command to start KWin again:

Code: Select all

kwin --replace &

The speed of the cursor is maybe (2 seconds)/(screen height). Unfortunately the system does not seem to respond to any keyboard input (including Alt+F2 and Ctrl+Alt+F*; otherwise I could at least still use the shortcuts for reboot). Also it does not seem to help to reconnect mouse/keyboard or to use the second keyboard of the notebook. I should maybe mention that so far it only happend to me in a dual screen setup with external mouse and keyboard connected. I can in principle still use the mouse to click buttons etc. But I need to move it fast upwards in order to compensate the movement downwards. This makes it practically impossible to hit the right buttons. Its a really silly thing.

I also activated the (numpad-)keyboard mouse in the settings and it might be related though the cursor does not seem to care about the numpad anymore once I am in this state.

The lack of keyboard shortcuts is very concerning...
After the force reboot (but before you login) can you check /var/log/Xorg.0.log to see if anything relevant is present? I am suspecting the involvement of X in this issue.

Also, if you wait a period (about 60 seconds or so should be long enough) after pressing the power button, the system should halt gracefully (for the most part anyway). This may not be visible on the screen however (disk activity will indicate if it is happening).

The numpad fake mouse thing has been removed from kwin - don't ask me when. It should be provided by some accessibility module now?

Ctrl+Alt+F<n> is a feature between the X11 server and the kernel - if that usually works (one can disable it by configuration) but no longer while this happens, there's sth. really screwed on either HW layer or input drivers (evdev? supposingly keyboard AND mouse?)

-> You could configure X to use the "kbd" and "mouse" driver and see whether this still occurs - nevertheless i'd also disable the numpad pointer (to be sure)
-> If you can ssh into the machine, you can use xev/xprop on the root window and cat /dev/input/event* to inspect what's going on there.
-> If you've a real HW mouse, try to just unplug it and see what happens.

I tried to deactivate the kde keyboard mouse and found that the problem didn't show up. After enabeling it again I had it again today. This time the cursor moving to the lower left corner. I therefore suspect that it is related to kde.
Unpluging the mouse does not help.
I can try cat /dev/input/event* next time this is possible.
It came to my mind that the Record extension of Xorg is disabled on my system as it can lead to fatal errors with synaptics touchpads. Not sure if it is related, but there should be a reason why only I see this bug. My hardware is pretty much standard. Thinkpad T61.

Which keypad cursor is that and what KDE version do you use?
The kwin one has as mentioned been kicked because there's afaik a better one in kaccessibility (but don't ask me were - i've never used that feature)

Sorry for the confusion. The one I am talking about is activated in my kde 4.8.1 (Ubuntu Precise packages) in the systemsettings dialog under Hardware->Input Devices->Mouse, Mousenavigation tab. Its controled using the Numpad of the keyboard. I cannot realy distinguish if it is a kwin feature or not.

In this case it is likely a KDE session which has the effect of configuring X to allow the keyboard number pad to act in this manner. Therefore, you are likely the victim of a X bug. This would explain why both the keyboard and mouse appear to be blocked when this occurs.

I know now that the mouse navigation we are talking about is indeed a Xorg feature which can be toggled by Shift+Num-Lock if this shortcut is activated by
setxkbmap -option keypad:pointerkeys
See my other topic: viewtopic.php?f=216&t=106658&p=247295#p247295
I will try to work with keyboard mouse only if I need it and to switch it off otherwise but the problem persists. It seems that it occurs sometimes if I press the (normal) cursor keys together with (at least) Ctrl (which I often do in order tho select text).

It took a while until I forgot to disable the numpad mouse (despite a really silly messagebox I have I script display on login). But today I can report that the moving mouse cursor bug is still present in Ubuntu 12.10, even with kernel 3.7.0-7-generic and xOrg drivers from xorg-edgers ppa. This time I have been able to perform an ssh login on my notebook and found that "sudo cat /dev/input/event*" does not produce any output, even if I move the mouse or type a key.

Unfortunate. Has the X bug been reported upstream to the X developers so they can investigate and attempt to rectify the issue?

Just to prevent misunderstandings: this exact command

Code: Select all

sudo cat /dev/input/*

is not gonna work!

You have to cat each device individually and check for output for input device action.