mouse keys too easy to accidently turn on

I've been having this problem too on 7.10. If there is a short-cut key to turn this on and off, it should be documented and have the option to disable it.

In "Keyboard Accessibility Preferences", I have the "Enable keyboard accessibility preferences" unchecked. The "Enable Mouse Keys" checkbox is usually unchecked and inactive. However, whenever mouse keys turns itself on, the "Enable Mouse Keys" checkbox becomes checked and inactive even though the "Enable keyboard accessibility preferences" checkbox remains unchecked.

Apparently, mouse keys does not respect the state of the "Enable keyboard accessibility preferences" checkbox. It will become enabled even though I've in spite of my preferences.

To disable mouse keys I have to check "Enable keyboard accessibility preferences" (to make "Enable Mouse Keys" active) , uncheck "Enable Mouse Keys" and then uncheck "Enable keyboard accessibility preferences".

Too many steps to disable a feature that shouldn't be enabled in the first place.

I think you can consider this bug confirmed, since two people have the same bug. I'm going to try to forward it upstream.

Added to the bugtracker of GNOME.

The shortcut is Alt + LShift + NumLock
The people at GNOME think that it's an error in the XServer. GNOME uses the flag XkbAccessKeys to enable or disable the keyboard accessible functions, but the Mouse key shortcut don't respect this. Thus it's an error in the XKB specification.
The only bug in GNOME is that the Keyboard Accessible functions box isn't selected, so the Mouse keys box looks grey.

upstream thinks it's a X issue, re assigning, thanks.

@William Woelke: did you also have this issue in gutsy, like John?

@John: Did this start happening when you shifted to gutsy, or did it occur before that?

I'm going to forward this bug to the bug tracker of X, but in order to fix this bug the developers will need some more information. Please attach the following files and command:
/etc/X11/xorg.conf
/var/log/Xorg.0.log
gconftool-2 -R /desktop/gnome/peripherals
Please also verify this issue is still present with the latest option and post the version of xkb-data.

I first noticed the issue in Gutsy, but not immediately.

On Wed, Mar 19, 2008 at 12:30 PM, Bryce Harrington
<email address hidden> wrote:
> @William Woelke: did you also have this issue in gutsy, like John?
>
> @John: Did this start happening when you shifted to gutsy, or did it
> occur before that?
>
>
>
> --
> mouse keys turns on randomly
> https://bugs.launchpad.net/bugs/192508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I didn't notice this issue before Gutsy, though I can't confirm that
this didn't happen before Gutsy. If it did, I didn't pay any
attention to it.

I have version 0.9-4ubuntu3 of xkb-data installed. I'm not sure what
you mean by 'latest option'. I am still running Gutsy and it is fully
updated and the issue is still present.

Thank you for looking into this!

Output of gconftool-2 -R /desktop/gnome/peripherals

I meant version I think. ;) Thank you for the files I'll report them to X.

I can also confirm this behavior with 7.10. It's a fresh install on a laptop (Toshiba Satellite P100 - full keyboard, so I use the number pad a lot). The duration between Mouse Keys turning on seems to be random - very hard to anticipate when it'll happen. I haven't had it switch while I'm actually in the middle of actually using my number pad though.

One thing that might be worth noting is that I frequently have remote sessions to other machines (both Windows and Linux) and I'm not sure if this might contribute to enabling the functionality or not. I've seen odd behavior with keys like Caps Lock and Num Lock while switching between Term Server or VNC, so I wanted to mention it.

I'm able to provide any attachments as well if they're needed.

Thanks for confirming! It would be great if you'd give your /etc/X11/xorg.conf and /var/log/Xorg.0.log too, so the devs can compare two different setups with each other.

/etc/X11/xorg.conf

/var/log/Xorg.0.log

I think I may have isolated the issue on my end - it seems that Shift+Num Lock turns on the Mouse Keys feature.

It seems to be pretty easy to hit this key combo on my laptop since I'm always turning Num Lock on and off pending what I'm doing at the time and holding the Shift key

Luckily, it's a toggle, so you can hit it again and disable it again. I'm going to poke around to see if I can disable this key combo completely, but knowing that it's a toggle will save A LOT of hassle.

I can confirm this and will report it upstream. Thank you very much for your work!

Just to confirm it affects 8.04, fresh install. Nice to know that this bug that affected a copy of Gnome I crowbarred onto slackware 9.1 5 years ago still has no fix.. gaaarrgghh.. I don't often use the keypad, but about 1 in 5 times mouse keys will be turned on AGAIN. I wish there was an un-install all accessibility features (mental note to check if there is) harsh though it sounds for those who might need it, having things random turn on and off is a pain.

Does it help to gksu gconf-editor then set the enable-mouse-keys or off and mandatory? I know this means every local user will be affected, but every local user is currently me, and I don't mind too much!

Nice to know this bug has been confirmed though.. 5 years ago I gave up looking for answers as I was too pushed for time.

Mouse keys seem to turn on in relation to using remote desktop, but I am unable to reproduce the problem willingly.

I can confirm this from 7.10 to 8.04, and since both "[ ] Enable assistive technologies" and "[ ] Allow to turn accessibility features on and off from the keyboard" options are disabled (unchecked), hotkeys combos should not turn this feature on at all.

Moreover, I can confirm what WIlliam Woelke says, that through remote desktop (I've installed vino default server, but using different clients) the (dis-)function seems to turn on with no apparent relation to pressed keys (that is, it can be happen that I press unwillingly the hotkey combo, but not so often as the problem occurs to me... at least, that's my impression)

I also have mouse keys turn on when logging in via VNC.
This also causes issues in Mathematica over VNC, wherein mathematica detects unusual characters from the shift key, I don't know if they are related in your scope, but they always seem to occur together.

I have often encountered the evil twin of this bug. Mouse keys will switch off for no apparent reason. I certainly sympathize with the posters above. But I would add that, for those of us who use mouse keys, it is equally unpleasant to have it suddenly _stop_ working. (Many thanks to Mike who posted the Shift+Num Lock shortcut!)

I encountered this often in Feisty and Gutsy. It seems to happen less often in Hardy, though I just recently upgraded and haven't spent much time with Hardy yet. There is one difference though; in 7.04 and 7.10 when mouse keys switched off the "enable mouse keys" check box would become unchecked. But in 8.04 mouse keys will stop working while the check box remains checked.

I am not using a laptop keyboard and it seems very unlikely that I'm frequently hitting shift+num lock by accident. I am not logging in via remote desktop; remote desktop is not enabled on my machine.

Ok, this may not be a high priority bug, but after 10 months, the bug is still there?

FWIW, I also use tsclient (so as client, to connect to a windows machine) and it may be related to the mouse keys switching on, but its hard to find a pattern, and it occurs even when tsclient is not running. But without having run tsclient during a session, I have not yet encountered it afaict.

Once you know what is happening, and you know shift+numlock disables it again, it is no drama. But most users will not read this and think ubuntu can not even drive a keyboard without errors. In that light, its a bit disappointing this still isn't fixed. If nothing else, I think a notification should be given when mousekeys are turned on (with or without this bug), so at least people might realize whats going on. Just a little balloon stating "mouse keys turned on. Press shift+numlock to turn off again".

I like the balloon idea. But there is an existing applet which is almost as good.

The accessx-status panel applet will tell you whether mouse keys is on or off. First make sure the gnome-applets package is loaded. Then right-click on the gnome panel, usually at the top and/or bottom of your screen. Select "Add To Panel", then scroll down and select "Keyboard Accessibility Status". Click Add. This will add an icon to your panel: with mouse keys off it looks like a wheelchair symbol, with mouse keys on it looks like a 3-button mouse.

I've experienced this bug using TightVNC and Vinegre as VNC clients and when using Vino (GNOME's built-in VNC server) as the server. P4man said he was using tsclient.

Is anyone experiencing this bug with other VNC clients or servers? I'm inclined to believe this is a bug in Vino, unless someone reports using a different server. Any KDE users with this problem? Any comments?

Paul: Thanks for the applet tip. Too bad we have to clog up the panel to get some indication for something we don't want.

Found these links:

http://ubuntuforums.org/showthread.php?t=921322
http://brainstorm.ubuntu.com/idea/9035/

Having a notification is not a solution. Its a useful idea for people who
actually want to use mousekey, but I bet the large majority doesn't and just
wants to see this bug fixed.

Its interesting almost everyone reporting this bug uses VNC or similar, so I
concur the bug seems to be related to it. Are you guys using a US qwerty
keyboard layout? I had to define my (belgian) keyboard in tsclient, Im
wondering if that plays a role or not, because until I defined the keyboard
layout as "fr-be", I didnt have a numeric keypad on the the remote client.
Exactly the same keys that act up with the mousekey thing. Coincidence?

On Wed, Nov 5, 2008 at 5:51 PM, John <email address hidden> wrote:

> Found these links:
>
> http://ubuntuforums.org/showthread.php?t=921322
> http://brainstorm.ubuntu.com/idea/9035/
>
> --
> mouse keys turns on randomly
> https://bugs.launchpad.net/bugs/192508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm using a US-qwerty layout on all my machines, both clients and servers.

P4man: What VNC server are you using?

On Wed, Nov 5, 2008 at 11:41 AM, P4man <email address hidden> wrote:

> Having a notification is not a solution. Its a useful idea for people who
> actually want to use mousekey, but I bet the large majority doesn't and
> just
> wants to see this bug fixed.
>
> Its interesting almost everyone reporting this bug uses VNC or similar, so
> I
> concur the bug seems to be related to it. Are you guys using a US qwerty
> keyboard layout? I had to define my (belgian) keyboard in tsclient, Im
> wondering if that plays a role or not, because until I defined the keyboard
> layout as "fr-be", I didnt have a numeric keypad on the the remote client.
> Exactly the same keys that act up with the mousekey thing. Coincidence?
>
> On Wed, Nov 5, 2008 at 5:51 PM, John <email address hidden> wrote:
>
> > Found these links:
> >
> > http://ubuntuforums.org/showthread.php?t=921322
> > http://brainstorm.ubuntu.com/idea/9035/
> >
> > --
> > mouse keys turns on randomly
> > https://bugs.launchpad.net/bugs/192508
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> mouse keys turns on randomly
> https://bugs.launchpad.net/bugs/192508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

US-querty - yes. Is it backsliding if I use a Microsoft Eronomic Keyboard 4000 on my Linux machine? ;-)

VNC - no. I have remote access disabled.

>P4man: What VNC server are you using?

My "server" is a windows XP box, that runs microsofts Remote desktop, which
I usually use (its faster) through tsclient.
But I also have a RealVNC 4.1.2 server for windows on it, always running,
but I rarely use the VNC protocol from ubuntu, so I doubt that matters.

I use Dvorak layout for the record. Not sure if that is a factor or not.

I just found out what probably causes it for me. This is silly. and slightly
embarassing.

In keyboard preferences > layouts > kb layout options > caps lock key
behaviour
I had caps lock behavior set to "caps lock toggles Shift so all keys are
affected".
This is not the default setting (although I can't remember changing it).
As a result pressing the numlock key while caps lock was enabled in effect
triggers a shift+numlock which enables mousekeys.
Setting the caps lock key behaviour back to default ensures that numlock
only enables/disables numlock even with capslock enabled (as you'd expect).
This almost certainly solved it for me.

The link with VNC/RDP here -for me at least, is probably just the fact that
I use capslock on the remote machine.

On Wed, Nov 5, 2008 at 9:19 PM, John <email address hidden> wrote:

> ** Bug watch added: GNOME Bug Tracker #530993
> http://bugzilla.gnome.org/show_bug.cgi?id=530993
>
> ** Also affects: vino via
> http://bugzilla.gnome.org/show_bug.cgi?id=530993
> Importance: Unknown
> Status: Unknown
>
> --
> mouse keys turns on randomly
> https://bugs.launchpad.net/bugs/192508
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I do not use the CapsLock key and my CapsLock key behavior is set to Default.

When I am connected to a machine with the accessibility applet in the
panel via VNC, the applet status does not show that mouse keys are
active. So having the applet in the panel doesn't help here, even as
a notifier.

Is there at least some package I can purge to permanently destroy all support for this feature? Maybe an unofficial patch I can apply, even at the cost of extreme instability?

I decided to try to run some tests, to better understand the situation in which the bug would occur, and I just discovered that right now (I'm logged via remote desktop) the keypad keys seem to work as intended only when Num Lock is turned off, i.e. acting as the arrow keys (plus page up/down etc.) but if I enable Num Lock they just do... nothing. They not even seem to work as mouse keys. It doesn't matter the function status, I tried to enable/disable it manually in the control panel (since the keyboard shortcut doesn't work via remote desktop) but nothing changes. Which conclusion would you draw from this? IMHO, that the bug just involves the remote desktop server (I tried two different clients) that is, in my case, the embedded vino.
Of course it would be nice to see how would the keys behave right now "locally", but I won't have access to this pc until monday morning, so this test can't be run. I hope this little "do-it-yourself" analysis can help in some way... if you need any details feel free to ask, I'm constantly monitoring this discussion.

Ok, since this bug is really annoying to me (and I can't help trying to understand/solve all the small problems I stumble over), I ran some other test. I hope some skilled programmer would like to investigate further and fix this.

While I was trying to fix a completely different problem related to the keyboard layout, I discovered "xev" and now I just tried it to see what happens when I press keypad numbers on the vnc client...

the result is that when NumLock is disabled, the "arrows" keys are generated (working as intended), but when NumLock is enabled (and numbers should result) NO EVENT is generated. It doesn't matter if mouse keys are turned on or off, no key press is detected. Not even the NumLock pressure is detected, and obviously the Shift+NumLock shortcut neither.

Locally, it all works as expected, and the shortcut is also recognized as Pointer_EnableKeys. So I'm even more sure than before that the bug lies in the vnc server code, since I tried two clients (RealVNC and TightVNC) and it'd sound strange to me if they both had the same bug. My vnc server is vino, that comes pre-installed.

Can anyone confirm? Maybe some good soul manages to work this out. Thanks.

Good idea to use xev to determine what X is seeing.

I have two machines with full-size US keyboards, including the keypad. Both
are running Ubuntu 8.10 and Gnome 2.24 with the latest packs installed.
Both have vino enabled and I am using vinagre to connect to the remote
server.

I used the command "xev | grep KeyPress -A 2 -B 2" to filter out
keypresses. I pressed the keypad 4, keypad 6, and NumLock key sequential on
both computers. The results are below, one line for each key and if
multiple KeyPress events were generated for a key, they are seperated by a
semicolon ";". Only keys on the local computer are actually being pressed.

Local computer only: NumLock ON
4: 0xffb4, KP_4
6: 0xffb6, KP_6
NL: 0xff7f, Num_Lock

Local computer only: NumLock OFF
4: 0xff96, KP_Left
6: 0xff98, KP_Right
NL: 0xff7f, Num_Lock

Local: Numlock ON, Remote: NumLock ON
4: 0xff7f, Num_Lock; 0xff96, KP_Left; 0xff7f, Num_Lock
6: 0xff7f, Num_Lock; 0xff98, KP_Right; 0xff7f, Num_Lock
NL:

Local: Numlock ON, Remote: NumLock OFF
4: 0xff96, KP_Left
6: 0xff98, KP_Right
NL:

Local: Numlock OFF, Remote: NumLock ON
4: 0xff7f, Num_Lock; 0xff96, KP_Left; 0xff7f, Num_Lock
6: 0xff7f, Num_Lock; 0xff98, KP_Right; 0xff7f, Num_Lock
NL:

Local: Numlock OFF, Remote: NumLock OFF
4: 0xff96, KP_Left
6: 0xff98, KP_Right
NL:

So from this it looks like the Local NumLock state is being ignored and that
some part of the VNC is trying very hard to ensure that the Remote X server
is seeing keypresses as if NumLock were off.

Incidentally, this is the same setup that was seeing Mouse Keys being
enabled when using VNC, though I did not experience it when I did these
test.

I can confirm the random activation of num pad as mouse keys via VNC. In my case the other end is usually Chicken of the VNC on OSX - so it's something in the VNC/Gnome end of things.

Nice to know I'm not the only one who's had this happen!

I've had this issue for a while too. Indeed, pressing shift-numlock enables/disables the feature. I don't intentionally press that, and the only time I hit numlock is when the pad is not in number-mode.

I do however use NXclient continuously -- not VNC, but a different kind of terminal server client.

And, interestingly enough: when I have the mousekeys enabled on my desktop and disabled in the terminal-client, I get both behaviours: a moving mouse and key input. (And the keyboard numlock light can get out of sync with the terminal-client, but that could very well be an unrelated issue.)

At least the shift-numlock shortcut is good to know. That shall save me some time.

Ok, this bug may still have a low priority but it's still annoying me and I can't help reporting about it. Right now I'm experimenting something I couldn't test before (because I didn't have the chance to physically access the machine when it occurred):
I was logged remotely on the Ubuntu box (running at the moment "2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux", with embedded vino remote desktop server) from a Windows machine (does this matter?) via TightVNC client.
[The two pcs are now in the same room. I'm using vnc to get advantage of the shared clipboard feature for some work I'm doing.]
Anyway, I was trying to input some numbers with the numpad, in the vnc window, but with no luck. I tried the shortcut (always in the vnc window), even knowing it never worked before and wouldn't now. I tried the same, and of course there was no surprise. So I reached the server keyboard and pressed shift+numlock to regain functionality. The strange behavior is that the numkeys are now perfectly working locally... but still don't work via VNC... *in the exact same moment* (of course I did not ended the active session). BUT if I keep the shift key pressed while using the numpad from vnc, it works as intended, that is, the arrow keys, home, del and so on. Also, there seem to be no way to make numpad work via vnc again: I tried, in order, starting a new vnc session, closing the old, starting a few new ones and closing them all (first included), disabling and re-enabling remote desktop access and then just disabling and enabling control... nothing. The last resource seems to be the reboot.

Is there any way (for me, since no one does) to debug the vnc server and try to see where does it fail to catch/decode the numerical keys sent? Any help is greatly appreciated...

And, this has already been asked but "repetita iuvant", is there a way to completely remove this feature from the face of the kernel? Or should I just give in and move on, perhaps installing a vnc server different from the "officially" suggested one hoping the problem is just related to vino? Thanks again.

To disable mouse keys, you can try running gconf-editor and disabling this key:
/apps/gnome_settings_daemon/plugins/a11y-keyboard/active

May require you to log out before it has any effect.

setting /apps/gnome_settings_daemon/plugins/a11y-keyboard/active to false does not seem to affect the shift+numlock hotkey for mouse keys in any way, even after logging out and logging back in. prior discussion indicates that this is part of the X server and cannot be disabled.

@Duvel
I already tried that, with no chance; moreover, if I enable the mousekeys by
activating the shortcut,
the option box (that is still unselected) seems to have no effect at all,
even enabling and then disabling it
and also closing any window trying to enforce the new setting. Thanks anyway
for the effort :)

On Tue, May 19, 2009 at 08:27, Duvel <email address hidden> wrote:

> Marius,
>
> While I cant offer a good solution, at least you should be able to
> avoid rebooting to get the numpad working again. If keyboard shortcuts
> do not work over VNC, then just go to the menu. Assuming you use
> gnome, go system > preferences > keyboard > mousekeys. Disable the
> option there (on client or server depending where the problem occurs),
> and you numeric keyboard should work again.
>
> If you're using a GUI-less server, then I dont know :)
>
> Cheers,
>
> Duvel.
>

@P4man
Nice hint, but it looks like it's another ignored setting. The mouse keys
can still be turned on,
and the shortcut is also working as before. Of course, this doesn't avoid my
problem to occur...
Nonetheless, thanks for trying to help me :)

On Tue, May 19, 2009 at 08:39, P4man <email address hidden> wrote:

> To disable mouse keys, you can try running gconf-editor and disabling this
> key:
> /apps/gnome_settings_daemon/plugins/a11y-keyboard/active
>
> May require you to log out before it has any effect.
>
>

This was very annoying for me until someone mentioned replacing Vino with x11vnc:

http://ubuntuforums.org/showthread.php?t=45565

I haven't had a single issue after making the switch.

What was happening before the switch:

Mouse keys turns on randomly when using VNC from Windows clients to connect to Vino on Ubuntu 8.04 Hardy Heron.
 -and-
Periodically, my NumLock would turn off on Ubuntu and I had to physically turn it back on with the keyboard on the box (VNC never would allow NumLock to turn back on).

Again, x11vnc fixed it completely.

I can confirm this bug with the host running jaunty and vino .

same. this has been annoying me for the past year. (8.04.x hardy)

Over here, with jaunty on the desktop and jaunty on the NX server, this issue hasn't occurred anymore. Unsubscribing.

i can confirm this still affects me in Karmic.

Can we raise the priority? This bug has been around for almost two years, and is very annoying. (Confirmed that it is still present in Karmic.)

> Bug description:
> I am using Hardy Heron and several times now I have tried to use my number pad only to discover that they now move the mouse. I don't know if there is a short cut key I am hitting on accident, but it is rather annoying. Then sometimes when I disable mouse keys, the numlock becomes switched so that the system thinks numlock is on when the light is off and vice-versa.

For the record -
 /usr/bin/gconftool-2 --type bool --set
/desktop/gnome/accessibility/keyboard/mousekeys_enable false
turns mousekeys off again. It's instant, no need to logout or
whatever. I suppose if I knew how to make that a mandatory setting it
would qualify as a work around until this gets fixed....

Hello fellow earthlings daily beaten by this bug.

I used this workaround to permanently disable mousekeys shortcut shift+num-lock, alt+shift+num-lock etc...

gksudo gedit /usr/share/X11/xkb/compat/complete
-or-
sudo nano /usr/share/X11/xkb/compat/complete

and comment out lines for mousekeys and accesx(full) (for full keyboard accessibility purge)

resulting file /usr/share/X11/xkb/compat/complete:
// $XKeyboardConfig$
// $Xorg: complete,v 1.3 2000/08/17 19:54:34 cpqbld Exp $
default xkb_compatibility "complete" {
    include "basic"
    augment "iso9995"
    //augment "mousekeys"
    //augment "accessx(full)"
    augment "misc"
    augment "xfree86"
    augment "level5"
};

Wish you a lot happy days without moving mouse by keypad ;)
Greets Ondrej

Im still effected by this bug happens often, however Im not sure if this is a separate bug....... It also happens to me when my screen locks that the (annoying) feature becomes enabled...

This still happens in lucid.

[This is an automatic notification.]

Hi William,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 192508

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 192508 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/192508

I tried running apport, to no avail. This is still a bug, and occurs fairly frequently (every couple of days). There seems to be a hotkey on the numpad which turns it on.

I confirm that this still occurs in Lucid :(

This was driving me nuts until I found out about this 'mousekeys' thing
How do I disable it permanently?

+1 for Lucid.

I just ran into this bug.

Also confirm bug still present in Lucid.
Phez: Workaround in my comment #52 still works.

I'm having this same problem.

I've been helped by the great people in the Ubuntu forums:
http://ubuntuforums.org/showthread.php?t=1516470

If this problem is fixed, will everyone using Linux (not just the Ubuntu variety) benefit by having it available to download and install by the Update Manager?

Ah, a comment in that thread is the key to this, I think - shift numlock is the hotkey that turns the "feature" on and off. I bet that I've been hitting that shortcut accidentally. Since it's such a "destructive" shortcut (i.e. it wrecks the number pad's function) could this bug be resolved by popping up an obvious-but-automatically-disappearing alert when the shortcut is selected?

And, could we have an option in the settings dialog for mousekeys to permanently disable the shortcut? I bet the combination of both of those would solve this issue for most people.

@Reuben Firmin I agree with your comment.

What do others think?

No, shift-numlock is NOT how most of us are having this happen.

Are you typing anywhere near the numpad when it turns on?

The notification that it is turning on would at least rule out your assertion.

I've not had time to read the 65 posts above, but I've experienced this same problem.

I hope someone can fix it for all Ubuntu/Linux users. It seems weird that numlock sometimes moves the mouse instead of being a number pad. I've not knowingly pressed SHIFT and num lock at the same time neither have I changed the keyboard settings to affect this.

Turbolad : Please read https://bugs.launchpad.net/ubuntu/+bug/192508/comments/52 - It could help.

The biggest issue I've noticed is that this happens with Remote Desktop enabled. Can anyone else confirm this?

I have a fresh install of 10.04 and had bug 549727 and this bug.

Thanks,

Nick

I am definitely not having this happen by pressing shift-numlock, but I connect to this computer (Ubuntu 10.04) with VNC (Remote Desktop) every day, so it seems likely that is triggering it somehow. Comment #52 contains a workaround, but that definitely isn't a bug fix.

confirming for Ubuntu 10.04.1 LTS 2.6.32-24-generic #42-Ubuntu SMP x86_64 with latest updates.

mousekeys is enabled on EVERY reboot, despite having the accessibility options set to the contrary.

The only time Ive ever pressed the shift-Numlock combination is to disable mousekeys once I figured out why my numpad wasn't working.

Of note is that this bug was not on the original install of this machine (built in march from the 9.x series,) but manifested only about 2 weeks ago when I rebooted to finish a minor update cycle. (~Aug 23 iirc) I wish I had known this was a bug then, as I would have been able to identify the exact packages that had been updated.

Still appearing sometimes across several Ubuntu releases, including Maverick 10.10, without Remote Desktop enabled.

i can confirm this still happens on maverick. i havent been using vnc, remote desktop or anything like that.

I can confirm the same, I have the same problem using maverick, and I'm almost sure the issue started when vnc got upgraded.

I can confirm the same issue in Ubuntu 10.10 64-bit. I have Remote Desktop enabled.

Same problem here. Ubuntu 10.10 64-bit. The workaround is to hold SHIFT and press Num lock.

Man, this is annoying, surely a candidate for Papercuts?

I'm facing the same issue with the following configuration:
- ubuntu 10.04.1 32bit, with remote desktop enabled (vino version 2.28.2-0ubuntu2)
- ubuntu 10.04.1 64bit, connecting to the above computer with vinagre (version 2.30.2-0ubuntu1)
The mouse keys activate on the first computer (the VNC server)

Based on the above comments and my personal experience, I don't think it could simply be some accidental Shift-NumLock

Also seeing this bug, though I don't use any form of remote desktop(the default one is installed, but never used)
10.10 on an HP ProBook 6555b
Started less than a month ago

The bug is still unsolved in 2012.

It happened two times to beginners that belong to my LUG.
In 2010: http://listengine.tuxfamily.org/linuxarverne.org/discussions/2010/04/msg00024.html
And recently: http://listengine.tuxfamily.org/linuxarverne.org/discussions/2012/01/msg00000.html

Fortunately they are using libre software for a long time now and are convinced by free software philosophy, but I can imagine what could happen to other beginners facing this problem.

They both use Ubuntu 10.04 but I used an up-to-date debian sid with gnome shell 3.2, and the Shift+NumLock still activates the option (whose is now in the universal access menu and not in the keyboard menu).

When will this "feature" be disabled? If not, is it possible to change the combination to a more-difficult-to-accidentaly-strike-it one, such as Ctrl+Alt+NumLock?

I can confirm this bug with latest Ubuntu Lucid 10.04.4. During vino sessions, mouse keys are activated when pressing numlock. This error is tricky because it doesn't happen every time, but we have definitely reproduced it several times.

In saucy the combination is Alt + LShift + NumLock. The problem is that it is not listed in Settings > Keyboard > Shortcuts > Universal Access.
It's also difficult to find Settings > Universal Access > Pointing and Clicking > Mouse Keys (Control the pointer using the keypad) to go back to normal behavior after using the combination by mistake.
In fact it was easier for me to find org/gnome/desktop/a11y/keyboard/mousekeys-enable=true using dconf dump / (this is a paradox about accessibility! )

WIlliam Woelke, 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 xorg-server REPLACE-WITH-BUG-NUMBER

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: None
CurrentDesktop: GNOME
DistUpgraded: Fresh install
DistroCodename: trusty
DistroRelease: Ubuntu 14.04
DistroVariant: ubuntu
GraphicsCard:
 NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:847f]
InstallationDate: Installed on 2014-07-16 (1 days ago)
InstallationMedia: Ubuntu-GNOME 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
MachineType: FUJITSU SIEMENS DP965LT
Package: xorg-server (not installed)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-32-generic root=/dev/mapper/vgubuntu-trusty ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4
Tags: trusty ubuntu
Uname: Linux 3.13.0-32-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/26/2007
dmi.bios.vendor: Intel Corp.
dmi.bios.version: MQ96510J.86A.1679.2007.0426.2359
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DP965LT
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD41694-209
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrMQ96510J.86A.1679.2007.0426.2359:bd04/26/2007:svnFUJITSUSIEMENS:pnDP965LT:pvr:rvnIntelCorporation:rnDP965LT:rvrAAD41694-209:cvn:ct3:cvr:
dmi.product.name: DP965LT
dmi.sys.vendor: FUJITSU SIEMENS
version.compiz: compiz N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.3-0ubuntu0.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.3-0ubuntu0.1
version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.910-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2
xserver.bootTime: Thu Jul 17 00:38:59 2014
xserver.configfile: default
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.15.1-0ubuntu2
xserver.video_driver: nouveau

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

CoudCoud, please do not apport-collect to another person's report. Instead, so your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Just wanted to add further confirmation that this particular keyboard shortcut is 'too easy' to activate. One of the babies in the house, each barely over one year old, reached up and randomly pressed buttons on my keyboard, turning on the 'mouse keys' function and disabling the numpad. I've been perplexed by this for a couple of months at least.

The suggestions I've seen to 'fix' the problem don't work for me on Ubuntu 14.04 LTS 64-bit. The system completely ignores the Settings|Universal Access|Pointing and Clicking|Mouse Keys setting. Using ALT+L-SHIFT+NUMLOCK, or SHIFT+NUMLOCK does the exact same thing as simply pressing NUMLOCK alone.

I believe that shortly after building this PC I had set the BIOS on my computer to automatically turn ON the numpad. I think that may be part of this insidious problem. Because now, when the light is ON for the NUMLOCK key, I am in Mouse Keys mode. And, when the NUMLOCK key is switched OFF, the numpad works normally.

Is there a way to permanently disable Mouse Keys, and get my keyboard to operate the way it used to?

This bug report obviously refers to changing a setting in the version of GNOME in use at the time this bug report was raised.

In a much more up-to-date version of gnome-control-center I see a switch that has to be moved in 'Settings | Accessibility | Pointing and Clicking' in order to enable 'Mouse Keys'. So not an easy option to turn on.

Does this bug report have any relevance in any currently supported release of Ubuntu bearing in mind that over 13 years have elapsed since it was raised?

There seems to be something missing from my edit of comment #111 so ....

Although the shortcut of Shift+NumLock still exists in the current development release (impish) there has been no comment from anyone affected by this issue in the last eight days since my comment #111.

Also, as there has been no discussion regarding this issue for over seven years now I'm closing this bug report with a status of "Opinion" as it is not something that seems to have affected any users in that time.