Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 483427 - numeric keypad doesn't work
numeric keypad doesn't work
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
: 495101 (view as bug list)
Depends On:
Blocks: 626594
  Show dependency treegraph
 
Reported: 2009-02-01 01:52 EST by Jonathan Kamens
Modified: 2018-04-11 09:02 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-17 12:24:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg log (89.18 KB, text/plain)
2009-02-02 11:47 EST, Jonathan Kamens
no flags Details

  None (edit)
Description Jonathan Kamens 2009-02-01 01:52:05 EST
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".
Comment 1 Matěj Cepl 2009-02-02 11:23:17 EST
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.
Comment 2 Jonathan Kamens 2009-02-02 11:47:58 EST
Created attachment 330648 [details]
Xorg log
Comment 3 Peter Hutterer 2009-02-08 21:11:55 EST
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.
Comment 4 Jonathan Kamens 2009-02-10 17:44:57 EST
NumLock does the right thing in the test you described above.
Comment 5 Peter Hutterer 2009-02-10 19:09:38 EST
Possibly gnome-settings-daemon then. Not sure though.
Comment 6 David Dillow 2009-03-17 00:08:50 EDT
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.
Comment 7 Felix Schwarz 2009-03-29 09:11:12 EDT
Just for what it's worth: I had the same issues on Fedora 10 and Shift+Numlock fixed it for me too.
Comment 8 Andreas M. Kirchwitz 2009-04-18 17:38:23 EDT
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. ;-)
Comment 9 Need Real Name 2009-04-18 17:51:10 EDT
*** Bug 495101 has been marked as a duplicate of this bug. ***
Comment 10 Adam Pribyl 2009-04-27 16:18:04 EDT
Just a bit of light: when numeric keys are not working, they do work - but they move the mouse pointer instead writing the numbers.
Comment 11 Andreas M. Kirchwitz 2009-04-27 16:46:33 EDT
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?
Comment 12 Need Real Name 2009-04-27 16:51:40 EDT
Me too.
Comment 13 Andreas M. Kirchwitz 2009-04-27 21:53:15 EDT
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.

Guess what?

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. ;-)
Comment 14 Adam Pribyl 2009-04-28 11:13:32 EDT
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.
Comment 15 Bastien Nocera 2009-04-29 14:43:43 EDT
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?
Comment 16 Jonathan Kamens 2009-04-29 17:43:25 EDT
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.
Comment 17 Bastien Nocera 2009-04-30 06:33:14 EDT
Is this key enabled in GConf?
/desktop/gnome/accessibility/keyboard/mousekeys_enable

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:
http://bugzilla.gnome.org/show_bug.cgi?id=519713
Comment 18 Matěj Cepl 2009-04-30 09:16:45 EDT
(In reply to comment #17)
> Is this key enabled in GConf?
> /desktop/gnome/accessibility/keyboard/mousekeys_enable

Is ON

> Did you ever enable accessibility features in GDM, or in the GNOME session?
> (this feature is call mouse keys).

No

> 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.
Comment 19 Bug Zapper 2009-06-09 07:00:58 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Vedran Miletić 2009-11-02 10:53:17 EST
I had this also in rawhide, and Shift+NumLock fixed it. Thanks, Bastien.
Comment 21 Felix Schwarz 2010-01-03 03:49:47 EST
Strange bug - just had this in F12 again.
Comment 22 Need Real Name 2010-01-06 09:54:34 EST
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?
Comment 23 Michael Shigorin 2010-01-06 10:39:40 EST
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).
Comment 24 Need Real Name 2010-01-06 15:56:07 EST
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?
Comment 25 Kieran Clancy 2010-01-13 06:03:22 EST
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.
Comment 26 Michael Shigorin 2010-01-13 06:29:20 EST
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).
Comment 27 Need Real Name 2010-01-13 14:12:53 EST
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.
Comment 28 Bug Zapper 2010-04-27 08:50:28 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Mark Locascio 2010-06-17 10:25:00 EDT
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.

Thanks,
-Mark
Comment 30 Bastien Nocera 2010-06-17 12:24:37 EDT
(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
> normal.

This won't work in the future. See:
https://bugzilla.gnome.org/show_bug.cgi?id=621899

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

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:
https://bugzilla.gnome.org/show_bug.cgi?id=621904

And something about Shift+NumLock not updating the UI:
https://bugs.freedesktop.org/show_bug.cgi?id=28584
Comment 31 Need Real Name 2010-08-14 06:10:31 EDT
Death by a thousand paper cuts!

It's broken again, for me on resume from suspend.

OS: Fedora 13
Comment 32 Need Real Name 2010-08-23 17:39:41 EDT
Hello?

Note You need to log in before you can comment on or make changes to this bug.