NumLock turned off on layout switch

It seems the bug lies somewhere deeper under, probably in xorg.

Turn on NumLock. Switch layout either using the indicator, or by executing "setxkbmap us" or something alike. Try the numpad keys: they work as expected (they insert digits). Press and release any of the modifier keys. Try the numpad keys again: they are in this inconsistent state where 5 is a digits, the rest are cursor keys.

So, a layout switch followed by a modifier press/release leads to this faulty state.

As a special case, if a layout switch is performed by a shortcut key, the modifier press/release happens as part of this key sequence, so NumLock becomes inconsistent immediately.

@Sebastian:

I firmly disagree with setting "Importance: Low".

Sure you might say that geez if pressing a key did something else, you can just undo that action, press some magic sequence of keys, and you're okay. No security problem, no data loss (actually I'm not even sure about these)...

But for me, this is a bug that's causing a constant high amount of stress. I mean, I hit this once a couple of minutes, each time adding a little bit of frustration for not being able to use the most basic input device that I'm using all the time.

Heck, ever since I started using computers, which was the ZX Spectrum almost 30 years ago, through DOS and Windows 95 and other Windowses, and my first Slackware Linux with kernel 2.0 in 1996, sometimes using other non-Linux Unices too, now for the first time ever we've reached a point where certain keys on the keyboard, under certain circumstances, fail to do the only thing that they need to do: emit the correct symbol.

If pressing 'A' would, 1 out of 100 times, insert a 'B' instead of 'A', would you say it's "low" because you can backspace and type it again? I'd say it's critical.

I've learned touch typing a long time ago, I'm often looking at a piece of paper of something like that when typing, knowing that the computer does what I'm telling it to do. It's unacceptable if, for the first time ever after using computers for 30 years, I need to verify on the screen that each keypress does indeed what it needs to do.

I'd say if, with the NumLock turned on, trying to insert a digit '7' moves the cursor Home instead, it's CRITICAL. It's the very essential of every computer that the keys need to do what they are intended to do, no exceptions, no excuses!

Status changed to 'Confirmed' because the bug affects multiple users.

Anything we could do to help the developers solved this bug and hopefully bump it into a higher priority than low? This is freaking annoying!

@Felipe: thanks for asking, some things that would be useful:
- describing exact steps to trigger the issue reliably
- testing if that happens without indicator-keyboard running
- testing if that happens without gnome-settings-daemon running
- debugging the code and sending a patch fixing the issue ;-)

@Sebastien: Are the steps described in the original report, as well as comment 2 not exact enough to trigger the bug reliably? It is buggy for me all the time, and so far nobody said he couldn't reproduce.

The bug is also observable under IceWM, when manually executing "setxkbmap us". So it's unrelated to Gnome, is probably a bug in X.Org/Xkb.

@Egmont: thanks, that's an useful information, it would be useful to have some confirmation if others get the issue without gnome-settings-daemon as well

I also experienced this weird NumLock state described by Egmont (5 is a digit, the rest are cursor keys).

I only use one keyboard layout (Hungarian) and don't want to switch it to any other, thus I deleted the English one in the System Settings / Text Entry.
But after startup my keyboard layout is mostly set to English (which is also described by others, e.g. http://askubuntu.com/questions/362973/keyboard-layout-switches-to-english-each-time-i-reboot).

Setxkbmap shows the following:
    $ setxkbmap -query
    rules: evdev
    model: pc105
    layout: us

So I have to manually switch to Hungarian either by
1.) clicking on the only Hungarian item in the keyboard indicator,
(Setxkbmap shows:
    rules: evdev
    model: pc105
    layout: hu,us
    variant: , )

2.) or entering setxkbmap hu in the terminal.
(Setxkbmap shows:
    rules: evdev
    model: pc105
    layout: hu )

But after this and using any modifier key (e.g. switching tasks with Alt+Tab or switching desktops with Ctrl+Alt+cursors) I face the mentioned inconsistent numpad state.
BTW numlockx says:
    $ numlockx status
    Numlock is on

Since I have to do the layout switching only once after startup I overcame this faulty behavior with a script starting automatically after login, as follows:

#!/bin/sh
setxkbmap hu
numlockx off
numlockx on

Guys, honestly I can't believe no one's paying attention to this bug.

I mean... it's the most basic input device and it's been working correctly for decades, and now it can't emit the freaking desired symbol?!? I find no words to describe how much frustration this bug keeps causing to me even after months of trying to get used to it: it occurs dozens of times daily that I try to type a number but instead it moves the cursor around, so I have to undo the cursor movement, press numlock twice and then retype the digits. Complete disaster!! You spend tremendous effort in coming up with the perfect desktop system including Unity and whatnot eye candy, but you ignore the very essentials like a working keyboard?? I swear twm with a properly functioning numlock would be more user-friendly.

This bug is a deal breaker for me. It's been three months since I reported it, and no action yet. I'll wait patiently for another two months trying hard not to jump out of the window from the anger this problem causes me, and then upgrade to the very first stable release of 14.04. If it's still not fixed there I'm sorry but I'm going to immediately switch to another distribution. (Not that you care too much about it apparently :( )

I have this issue on a clean install of Ubuntu 14.04 LTS.

I also experience this issue after a clean 14.04 installation. Layout keeps switching all the time. It's incredibly annoying and infuriating.

My preferred keyboard layout is "US International with dead keys" (or something like that, my environment is currently set to Spanish).

I need this keyboard layout for many reasons, the first and most obvious being that my laptop came with a English layout keyboard, not Spanish. Second is that I often need to type áéíóúñõãũ etcetera. Third, I don't want to switch layouts all the time, so "US International with dead keys" is a perfect fit for me.

The problem is that I find myself frequently (read: many times a day) messing around with keyboard layout settings because the system keeps forgetting and instead changes to plain English layout and for some very stupid reason, disabling num lock. Also, when this obnoxious unsolicited gratuitous layout switch happens, I no longer can type some characters (quotation marks ("), apostrophes ('), accents ('`)) in applications written in Java/Swing.

I can say for sure, but I think one of the things that triggers the switching is suspend/resume cycles.

I know this doesn't add anything to the report but I need to mention that I HATE THIS BUG WITH INTENSE, FERVOROUS PASSION.

Felipe, Csaba, Cvetan, Diego:

I made some findings upstream at https://bugs.freedesktop.org/show_bug.cgi?id=78012. Looks it's somehow related to the hardware incorrectly changing the keycode on its own when numlock is switched on.

Could you please reveal what hardware you have? At this point I wouldn't be surprised if Samsung laptops were the culprit.

I have this issue on a desktop PC.

ASUS P8B75-V with Intel B75 chipset.
Intel core-i5 2320.
RAM 8GB
ASUS EAH6450 1GB(Radeon HD6450)

Thanks. Could you please tell us the exact brand/model of your keyboard?

Do you have another keyboard somewhere that you could try?

It sounds strange I know, but apparently on a few computers the numpad keys start producing different keycodes when numlock is off (namely the keycodes of the standalone cursor keys). I have no clue yet if it's a problem with the keyboard itself, or the motherboard, bios, what else tries to be more clever than it should...

Make sure NumLock is off. From a terminal start "xev", and press numpad 1. A few friends confirmed to me that they see "keycode 87, keysym KP_End" which is I think the expected result. On the other hand, I see "keycode 115, keysym End" which apparently somehow leads to the broken behavior, I guess you also see this latter.

(Just for reference: https://bugzilla.gnome.org/show_bug.cgi?id=600659#c63 is a totally different bug apparently caused by the same underlying weird keycode change.)

The keyboard is Genius Slimstar 110. I will try to find another one, to try, but this is completely same configuration that i used on Ubuntu 12.04 untill i installed 14.04, couple days ago.

On 12.04 i didn't have the problem.

Ubuntu 12.04 is irrelevant here. A lot of changes with keyboard layout change went into 13.10 (see bug 1218322) which is the source of many problems. Prior to 13.10 kbd changes were handled differently and it didn't trigger this problem.

I attach a patch to xorg-server which seems to fix it for me. Side effects are yet to be discovered :)

Rebuild xorg-server with the following series of commands (might not be the best way, but that's what I found, I'm not yet familiar with these):

sudo apt-get install build-essential fakeroot dpkg-dev
mkdir build
cd build
apt-get source xorg-server
sudo apt-get build-dep xorg-server
cd xorg-server-1.15.1
cp ~/Downloads/xorg-server-xkb-numlock.patch debian/patches/ # replace Downloads appropriately
echo xorg-server-xkb-numlock.patch >> debian/patches/series
dpkg-buildpackage -rfakeroot -b
cd ..
sudo dpkg -i xserver-common_1.15.1-0ubuntu2_all.deb xserver-xorg-core_1.15.1-0ubuntu2_amd64.deb

The attachment "Works for me, probably not the proper solution though" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Egmont Koblinger,
thank you. It's work for me too

I don't have a solution but i have something that turn on the numlock when you change layout (it's stupid, but works for me).
follow the steps below:

1)mkdir ~/keyfix ; cd ~/keyfix

2)open a file show_layout.sh and copy and paste this: " setxkbmap -print | grep xkb_symbols | awk '{print $4}' | awk -F"+" '{print $2}' " (without the first and the last ")

3)open a file keyfix.sh and copy and paste this:
s=0
s1=0
while test "1" == "1"
do

s=`$HOME/keyfix/show_layout.sh`

sleep 0.001s

if test "$s" != "$s1"
then

numlockx off
numlockx on

#if test "$s" == "alt_layout"
#then
#xset led named "Scroll Lock"
#else
#xset -led named "Scroll Lock"
#fi

fi

s1=`$HOME/keyfix/show_layout.sh`

if test "$s" != "$s1"
then

numlockx off
numlockx on

#if test "$s" == "alt_layout"
#then
#xset led named "Scroll Lock"
#else
#xset -led named "Scroll Lock"
#fi

fi
sleep 0.01s

done
********************
if you want to turn on scroll lock when you use alternative layout, remove the #'s and change alt_layout to your alternative layout i.e. "gr" or "us"
**************************

3)open a file disown_easy.sh and copy and paste this:
#!/bin/bash
$1 &
P=`which $1`
disown `pidof ${P}`

4)open a file run-keyfix and copy and paste this:
$HOME/keyfix/disown_easy.sh $HOME/keyfix/keyfix.sh

5) open a terminal and type:
 chmod +x ~/keyfix/* ; sudo cp ~/keyfix/run-keyfix /usr/bin/

6)make the script run-keyfix to run on startup! (go to startup applications and add it)

THIS IS NOT A SOLUTION! THIS IS A STUPID FIX!

*don't use these scripts to make weapons!

This solution
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1247668/comments/22

also fix this problem ( Can't set keyboard layout change to alt+shift, ctrl+shift, etc. )
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1218322

@Egmont Koblinger (egmont-gmail), great thanks! You path is works for me) Now the NumLock not turned off on layout switched.

this bug ever fix this?

This bug is still present in Vivid (15.04).

+1
developers you simply freaks. Such bugs shouldn't be
It simply enrages. It is impossible to work normally at ubuntu 14.04
I hope you someone will punish for that that you such

+1 Please fix this super annoying bug. Work experience in Ubuntu is going very down with this.

(GOOGLE TRANSLATE)

create the account to pay for this error. Who is responsible can create an account to which the volunteers will translate money to solve this particular bug. Attach the news to zagalovku bug "who will correct the error receive a cash consideration of ..." he can not do so because they do not know this, who will be able to organize? And we, who are dealing with this bug

+1
Could you please take a look into it and prepare an update that would fix this issue? Current behaviour is very user unfriendly. Thanks in advance!

would regress commit

commit c7634498d4cd42c8571805122224dc2d0e44a585
Author: Daniel Stone <email address hidden>
Date: Tue May 3 02:59:53 2011 +0100

    XKB: Remove duplicate keymap-copying loop

    Previously we had:
        foreach (device + slaves of device) {
            XkbCopyDeviceKeymap(i, device);
            [...]
        }
        if (device was last slave of its MD) {
            XkbCopyDeviceKeymap(master, device);
        }
    and now:
        foreach (device + slaves of device + MD if device was last slave) {
            XkbCopyDeviceKeymap(i, device);
            [...]
        }

    As an extra bonus, when changing the keymap on a slave device, we now
    ensure the LED info on the master is kept in sync.

    Signed-off-by: Daniel Stone <email address hidden>
    Reviewed-by: Peter Hutterer <email address hidden>

so, say you have another keyboard attached (laptop docked, etc), numlock status is synced with both

I'm facing this bug every single day for 10 months and I just can't get used to it. It's devastating. =/

Just installed Ubuntu GNOME 15.10 and the bug is still here. =(

I wish I could help here, but I'm just reporting.

Come on its two years in the future still not fixed this bug... i'm so pissed off

ubuntu 15.10 unity !! I have this bug

I am running 14.04 LTS , using a Logitech K200 keyboard

numlockx has been added to /usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf
greeter-setup-script=/usr/bin/numlockx on

I added to /etc/profile, /etc/bash.bashrc, ~/.profile, ~/.bashrc, ...
/usr/bin/logger -i -t PRIVATE -- "~/.profile user `/usr/bin/numlockx status`"

Numlock is on at login
Numlock is on when executing /etc/profile
Numlock is on when executing ~/.profile
Numlock is on when executing ~/.bashrc
When GUI is available, numlock is off. I seems that somewhere after processing login, numlock gets switch off.

Workaround found on https://sites.google.com/site/easylinuxtipsproject/first "10 things to do first in Ubuntu 14.04 LTS"
I added it to /etc/profile (sudo vi /etc/profile)
[ -x /usr/bin/numlockx ] && ( sleep 20 ; /usr/bin/numlockx on ) &
Works fine for me.

+1

On Ubuntu 16.04 LTS with only Norwegian keyboard layout (no switching), I get the num lock problem after login. The num lock LED is on, pressing e.g. Ctrl turns it off, but the num lock function is still on, pressing num lock turns the num lock function off, pressing num lock again turns on both the LED and the function.

The "Works for me, probably not the proper solution though" patch worked for me.

Thought I saw the num lock LED flicker a bit when it was on. Don't know if that's connected to this bug. The patch might have stopped the flickering, but it's hard to say.

I have a Key Tronic Ergoforce KT2001 PS/2 keyboard.

Try to disable XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll" in /etc/default/keyboard

I have XKBOPTIONS="" in that file.

Note that I'm using Gnome (Unity) which infamously handles the layout switch itself nowadays rather than letting X do so (see e.g. https://bugs.launchpad.net/gnome-settings-daemon/+bug/1244090). I guess the contents of /etc/default/keyboard are completely overridden by Gnome.

If still this bug effect you , I patch it with a simple script :
https://github.com/mostafaasadi/num

My old laptop (a Samsung NP300E5Z, originally with Precise and upgraded all the way up to Yakkety) died a few days ago. I cannot tell for 100% but I'm like 99% sure that this bug still existed there in Yakkety, otherwise I pretty sure would have noticed being releived by the pain being gone while using Yakkety for about 1.5 months (since around its final beta freeze).

My new laptop (a Dell Inspiron 5559 210771, with a brand new Yakkety installation, same plain pretty much default Unity7, same two keyboard layouts and same Alt+Shift toggle configured) does not suffer from this bug. I enable NumLock, it looks like it stays enabled all the time.

In the mean time, changing the layout still switches off Caps Lock, including its feedback LED. Luckily I don't care about this too much.

At this point I have no clue whether:
- it was some system-wide leftover from the upgrade processes,
- it was some leftover in my home directory (I did not [yet] bring over my settings),
- or the behavior is somehow hardware related.

It is 2018 year. A ridiculous bug with NumLock is still present in a fresh installation of 14.04 LTS.
4 years no one can fix the bug, is it for real?