Red Hat Bugzilla – Bug 483427
numeric keypad doesn't work
Last modified: 2018-04-11 09:02:10 EDT
With everything updated from Rawhide on January 30. With no /etc/X11/xorg.conf file, so I'm using whatever the server auto-detected. My numeric keypad doesn't work properly, i.e., when I type numbers on it, they are not entered as numbers, regardless of whether the Num Lock LED is lit.
I ran both system-config-keyboard and System > Preferences > Hardware > Keyboard and gave appropriate settings for the standard US105 keyboard I have, but that didn't help.
When I run xev and hit keypad keys, it seems to recognize them properly, e.g., the 4 key shows up as KP_4 when Num Lock is on and correctly says that it translates into the string "4".
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachment using the bugzilla file attachment link below.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 330648 [details]
Please do the following
- install xterm (in case you don't have it yet)
- switch to a VT (ctrl+alt+f2)
- run sudo stop prefdm
- run xinit -- /usr/bin/Xorg -noreset -retro
- when the server comes up, test the numlock in the xterm alone.
- Ctrl+Alt+Backspace kills the server (or exit terminal), then sudo start prefdm re-starts GDM.
This way we can make sure whether it's X or GNOME interfering.
If it doesn't work in the plain X session, please attach the output of xev when you hit num lock and a key before and after numlock is set, and also the output of xkbcomp -xkb :0 -. Thanks.
NumLock does the right thing in the test you described above.
Possibly gnome-settings-daemon then. Not sure though.
I had this problem -- numpad worked in the console, but not in X. Trying a suggestion I found in another bug, I pressed Shift-Numlock (also reported was Ctrl-Shift-Numlock, but that didn't work for me.) and now I have a numpad again.
I don't know how I got into mousepad mode, but it persisted over reboots, as does this fix, for me.
Just for what it's worth: I had the same issues on Fedora 10 and Shift+Numlock fixed it for me too.
Same here on Fedora 10 (including all patches), using X (startx) with fvwm2,
gnome-settings-daemon is running in background.
Console works fine, but NumLock doesn't work for X applications like
"xterm" and "gnome-terminal". The work-around with Shift + NumLock fixed
it for me as well, and all running X applications recognize NumLock properly
for now (until next reboot).
Don't know when this first happened because I don't use NumLock very often
(I prefer the numeric keypad to work as numbers but I don't like the
bright LED on the keyboard). I'm wondering that only a few people complained
so far. Looks like almost nobody uses the numeric keypad nowadays. ;-)
*** Bug 495101 has been marked as a duplicate of this bug. ***
Just a bit of light: when numeric keys are not working, they do work - but they move the mouse pointer instead writing the numbers.
Funny thing is: Once I did the trick with Shift + NumLock,
the problem didn't happen again, even after reboots.
Is this a GNOME setting? Does anybody know which one?
Logged in on text console in runlevel 3 (no GNOME daemons, applications
or related stuff running), removed the GNOME stuff from home directory
(~/.gconf*, ~/.gnome*) and then tried again with full X11 login with
default GNOME settings.
NumLock still works perfectly. Must be magic. Well, at least, it doesn't
seem to be a GNOME setting.
Searching the web for that topic isn't easy because of so many problems
people have with NumLock (especially on notebooks; but I'm using a regular
desktop PC). Shift+NumLock is often referred to as "Bare_Num_Lock", and
people use it if their NumLock doesn't work. But in opposite to this bug
report, Shift+NumLock doesn't make plain NumLock work for those people.
Maybe the keyboard controller of some PCs needed some kind of
"re-initialization" after a recent patch (GNOME? Kernel?)
But do regular keyboards "remember" anything? My keyboard doesn't
have programmable macro keys or glows in the dark. Just a plain
old keyboard, nothing special. ;-)
By pressing the Shift+Numlock again I can restore the original "default" behaviour. It's probably a feature that is for some reason On by default, or it comes to default thru some update process.
What's the value of "/desktop/gnome/peripherals/keyboard/remember_numlock_state" in gconf-editor?
Under /desktop/gnome/peripherals/keyboard/host-HOSTNAME/0, does changing numlock_on change the status of NumLock as visible on the keyboard LED?
Shift+NumLock fixes the problem for me as well.
But it still seems like there's a bug here, since I never voluntarily turned on mousepad mode, so it shouldn't have been turned on for me.
remember_numlock_state is checked
There are hosts under keyboard in gconf-editor: host-jik2.kamens.brookline.ma.us, and host-jik2@46@kamens@46@brookline@46@ma@46@us. Checking and clearing numlock_on in the former does *not* affect the LED on my keyboard, but checking and clearing numlock_on in the former *does* cause the LED to go on and off.
Is this key enabled in GConf?
Did you ever enable accessibility features in GDM, or in the GNOME session? (this feature is call mouse keys).
Is there any chance you pressed (at any point in time, probably by accident) the Alt+Shift+NumLock combination?
In which case, we'd need X to be fixed to allow disabling that shortcut:
(In reply to comment #17)
> Is this key enabled in GConf?
> Did you ever enable accessibility features in GDM, or in the GNOME session?
> (this feature is call mouse keys).
> Is there any chance you pressed (at any point in time, probably by accident)
> the Alt+Shift+NumLock combination?
No, but when I am pressing it know, it flips /desktop/gnome/accessibility/keyboard/mousekeys_enable back and forth.
Yes, Shift+NumLock fixes the issue.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I had this also in rawhide, and Shift+NumLock fixed it. Thanks, Bastien.
Strange bug - just had this in F12 again.
This is one of those bugs in Fedora that keeps coming back occasionally.
The people on this bug - the people who will make the noise - know how to work around it - but is there a fix planned?
It's a mouse emulation FEATURE -- *if* it's toggled by Shift-NumLock and off by default. :)
The feature allows one to cope with missing mouse, and served quite a few of us well. I'm afraid bringing this over and over might convince fd.o folks to rip the feature off just as they made Ctrl-Alt-Backspace hardly accessible (though that case has much higher potential price to pay per an accidental use).
Hm- I didn't know about this feature, it seems potentially very useful.
Is the problem then that this feature sometimes ends up turned on when it shouldn't do, or is it that enabling and disabling this mouse feature conveniently resets the numpad?
I also seem to accidentally turn this on regularly. It's very frustrating when all-of-a-sudden your numpad stops working.
While it's possible that I'm accidentally pressing Shift-Numlock (no Alt required to turn this on here), I find it hard to believe that I am doing it that often. If it is just accidental, I'd really like a way to turn that shortcut off.
I think an event is due which could be acted upon by e.g. throwing up an accessibility warning like when holding e.g. Shift in kde3 which is taken as a hint to enable sticky keys which do hurt then if one didn't really want 'em.
Dunno what it's up to in gnome but seems like two feature requests need to be filed instead: one against xorg (maybe xorg-server initially) and another against gnome (no ideas regarding specific target).
Just to add my voice: I am not having the problem that I accidentally activate this, my problem is that at boot numlock completely fails (failed) to work sometimes. Until I use the shift+numlock workaround.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
I'm running F12 (x86_64) and I have the same problem every time I reboot. Until I read this report, I always had to dig around under my desk, unplug the USB keyboard, and then plug it in again. Oddly enough, this restored my keypad to normal.
Just tried shift+numlock after a reboot. That works for me, too. I just wanted to point out that unplugging/replugging seems to work, but if it's a GNOME thing, I'm surprised that it doesn't just end up in the same state as before unplugging.
(In reply to comment #29)
> I'm running F12 (x86_64) and I have the same problem every time I reboot. Until
> I read this report, I always had to dig around under my desk, unplug the USB
> keyboard, and then plug it in again. Oddly enough, this restored my keypad to
This won't work in the future. See:
> Just tried shift+numlock after a reboot. That works for me, too. I just wanted
> to point out that unplugging/replugging seems to work, but if it's a GNOME
> thing, I'm surprised that it doesn't just end up in the same state as before
The numeric keypad doesn't work because somebody enabled "mouse keys". Just disable mouse keys in the keyboard preferences, and it'll work as expected.
We should have a warning that the mouse keys got enabled:
And something about Shift+NumLock not updating the UI:
Death by a thousand paper cuts!
It's broken again, for me on resume from suspend.
OS: Fedora 13