NumLock turned off on layout switch

Bug #1247668 reported by Egmont Koblinger on 2013-11-03
344
This bug affects 77 people
Affects Status Importance Assigned to Milestone
X.Org X server
Confirmed
Medium
xorg-server (Ubuntu)
High
Unassigned

Bug Description

Extracting from bug 1218322, confirmed there by multiple users:

When switching the keyboard layout using a shortcut (such as Alt+Shift), NumLock functionality is (mostly) turned off. More precisely: it goes into an inconsistent state where pressing numpad 5 inserts the digit 5, but the other numpad keys move the cursor. Pressing the NumLock key turns it off completely (pressing numpad 5 no longer does anything), and pressing once again turns it on.

This means that if someone prefers to have the NumLock functionality switched on all the time, they have to press the NumLock key twice after each layout change. I find this a huge usability problem.

(I don't have a LED, so I cannot tell how that one is lit.)

The bug is not present when changing the layout via the indicator applet.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-settings-daemon 3.8.5-0ubuntu11.1
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Sun Nov 3 21:54:37 2013
InstallationDate: Installed on 2012-05-30 (522 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MarkForUpload: True
SourcePackage: gnome-settings-daemon
UpgradeStatus: Upgraded to saucy on 2013-10-12 (21 days ago)

Egmont Koblinger (egmont-gmail) wrote :
Egmont Koblinger (egmont-gmail) wrote :

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.

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
Egmont Koblinger (egmont-gmail) wrote :

@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!

Launchpad Janitor (janitor) wrote :

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

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Felipe Castillo (fcastillo.ec) wrote :

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!

Sebastien Bacher (seb128) wrote :

@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 ;-)

Egmont Koblinger (egmont-gmail) wrote :

@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.

Egmont Koblinger (egmont-gmail) wrote :

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.

Sebastien Bacher (seb128) wrote :

@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

Changed in gnome-settings-daemon (Ubuntu):
importance: Low → High
Sümegi Csaba (sumegics) wrote :

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 :( )

Norbert (nrbrtx) on 2014-04-21
tags: added: keyboard-layout-switching-related
Cvetan Simsic (cvetan-simsic) wrote :

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

Diego Schulz (dschulzg) wrote :

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.

Diego Schulz (dschulzg) wrote :

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

Turn on NumLock, verify the behavior by pressing the numpad digits.

Change layout by executing a "setxkbmap us" or similar command. Verify that numpad digits still work as expected.

Press and release any of the modifiers, e.g. left shift.

Press the numpad keys and figure out that they're in a broken inconsistent state that should never occur. Numpad 5 inserts a literal 5 into applications, whereas the rest work as if NumLock had been turned off. numlockx reports it is switched on. Press the NumLock key and it's turned off, press again and it's turned on correctly.

Expected behavior: changing layout should of course not effect numlock's state.

Originally reported at https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1247668.

affects: gnome-settings-daemon → xorg-server

When NumLock is off, my numpad keys report keycodes 110-119 (with the exception of '5' which still has the keycode 84). E.g. in "xev", numpad '1' reports 115 End, instead of the expected 87 KP_End. (With NumLock on, it is 87 KP_1, as expected.)

Speaking in terms of "xmodmap -pke" format, apparently the correct column is looked up (depending on NumLock's status), but in the wrong row for some reason (the row also depends on NumLock's status, though it shouldn't).

Holding down the Fn key toggles the keycodes, i.e. with NumLock off it becomes 87 KP_End, and with NumLock on it becomes 115 End.

The very same behavior is observable with "showkey" on the text console (with an offset of 8 in the key codes, and NumLock can't be toggled while showkey is running).

Apparently, this laptop works differently than most laptops, and probably the hardware does some magic that it really shouldn't do.

The commands "numlockx on" / "numlockx off" work as expected, they apparently somehow tell the hardware whether to alter the keycodes consistently with X's belief. Using "xmodmap -pke"'s terminology, the row and the column are switched together, and I haven't found a way to get to the other two row/column combos. This suggests that theoretically there should exist a workaround. Whenever X's belief of the NumLock state changes, it should do whatever "numlockx off" does to lie to the hardware so that it doesn't modify the keycodes.

This is a Samsung NP300E5Z laptop. (By the way, it doesn't have a NumLock LED.)

Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

Cvetan Simsic (cvetan-simsic) wrote :

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.)

A few people confirmed that their system always sends keycode 87 for keypad 1/End, independently of NumLock's state. They don't face this bug.

I've connected an external keyboard to my laptop and that one also always sends 87, as opposed to the built-in one.

Really looks like we're facing some broken keyboards.

Anyway, X's behavior is still not reasonable. When NumLock is on, changing the layout and then pressing a modifier shouldn't trigger the keyboard's brain-damaged "geez, NumLock went off, let me alter the keycodes" mode, since NumLock didn't turn off at all.

Cvetan Simsic (cvetan-simsic) wrote :

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

affects: gnome-settings-daemon (Ubuntu) → xorg-server (Ubuntu)

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.]

tags: added: patch

Created attachment 98637
Works for me, probably not the proper solution though

Here's a workaround patch that I've been using successfully for a while.

Upon loading a new keymap, Xkb does something with the locks. I'm not sure what it is and why it would do so. I just commented out that part and it works great for me. There might be side effects unbeknownst to me.

Apparently various manufacturers create keyboards that change the keycode of the numpad keys to their non-numpad equivalents when NumLock is off. Crazy, I know. This is an issue Xkb developers should be aware of.

The current behavior on layout change is still not reasonable at all, it's a bug somewhere in Xkb, triggered by such keyboards. Nevertheless, this bug should be fixed.

JavaFox (javapaulfox) wrote :

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

dimitronic (dimitronic) wrote :

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!

The-mob (xarilaos-com) wrote :

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

Sorbing (svbutsenko) wrote :

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

AnMo (therealanmo) wrote :

this bug ever fix this?

tags: added: keyboard-layout-switching-hotkeys
removed: keyboard-layout-switching-related
Thanos Kyritsis (djart) wrote :

This bug is still present in Vivid (15.04).

sergey (zwezda-11) wrote :

+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

Tomas Kral (kralutomas) wrote :

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

Tomas Kral (kralutomas) on 2015-09-07
tags: added: trusty
AnMo (therealanmo) wrote :

(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

Matěj Chlumský (mateschlum) wrote :

+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!

Timo Aaltonen (tjaalton) wrote :

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.

Martinsh (371tish) wrote :

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

mostafa asadi (mostafaasadi73) wrote :

ubuntu 15.10 unity !! I have this bug

Jean Sand (jean-sand) wrote :

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.

Jean Sand (jean-sand) wrote :

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.

公输目 (yue937) wrote :

+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.

mostafa asadi (mostafaasadi73) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.