After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 74215 - NumLock setting
NumLock setting
Product: gnome-control-center
Classification: Core
Component: Keyboard
Other Linux
: Normal enhancement
: GNOME2.0
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 70362 319520 (view as bug list)
Depends on:
Reported: 2002-03-11 07:56 UTC by Mattias Eriksson
Modified: 2005-11-02 10:46 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

This patch implement this. (20.40 KB, patch)
2002-05-12 15:59 UTC, Pier Luigi Fiorini
none Details | Review
GUI, actual code (2.67 KB, patch)
2003-05-18 12:29 UTC, Sebastian Kapfer
needs-work Details | Review
GConf schema (969 bytes, patch)
2003-05-18 12:30 UTC, Sebastian Kapfer
needs-work Details | Review
Patch implementing this (7.90 KB, patch)
2005-03-20 17:30 UTC, Sebastian Kapfer
none Details | Review
Updated patch (8.14 KB, patch)
2005-09-27 21:55 UTC, Jürg Billeter
committed Details | Review

Description Mattias Eriksson 2002-03-11 07:56:13 UTC
It would be nice to be able to set the state of NumLock in the keyboard 
Comment 1 Mattias Eriksson 2002-03-19 12:41:07 UTC
A small program to control numlock in X is found at:
Comment 2 Luis Villa 2002-04-10 02:51:48 UTC
Updating all cc bugs that have the GNOME2 keyword set to the GNOME2.0 milestone,
to help jrb triage/prioritize cc bugs. Filter on 'luis doing GNOME2 work' to
ignore this spam.
Comment 3 Pier Luigi Fiorini 2002-05-12 15:59:13 UTC
Created attachment 8406 [details] [review]
This patch implement this.
Comment 4 Luis Villa 2002-05-12 23:29:19 UTC
No idea if this is useful/desired or not... Rachel?
Comment 5 Luis Villa 2002-05-12 23:29:43 UTC
*** Bug 70362 has been marked as a duplicate of this bug. ***
Comment 6 Chema Celorio 2002-06-20 06:42:26 UTC
I think it would be useless. Why would you want to do this for? 
Comment 7 Mattias Eriksson 2002-06-20 08:26:08 UTC
When I start my linux box and login to my gnome environment the
numlock setting is off by default. 
This is highly anoying since I only use the numrical keyboard to type
But since old window managers (fvwm) used to have trouble handling the
numlock setting it is traditionally turned off by default in unix
It makes no sence for a user like me to have the numlock setting off
since I only use it to type numbers, but since it's off by default I
guess alot of people are doing other stuff like navigating on it.

So I guess just turning the numlock setting on would do it for me, but
I think it should be optional.
Comment 8 Luis Villa 2002-11-07 14:36:54 UTC
SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch
these all and delete them. :) 
Comment 9 Andrew Sobala 2002-11-08 18:55:20 UTC
-maint, what do you think of this rationale/patch?
Comment 10 Kjartan Maraas 2003-04-29 22:39:41 UTC
Can we decide either for or against this once and for all?
Comment 11 Sebastian Kapfer 2003-05-18 12:29:47 UTC
Created attachment 16603 [details] [review]
GUI, actual code
Comment 12 Sebastian Kapfer 2003-05-18 12:30:15 UTC
Created attachment 16604 [details] [review]
GConf schema
Comment 13 Sebastian Kapfer 2003-05-18 12:32:17 UTC
Hmm. This is funny indeed. Yesterday I created my own patch which
implements this. Should have checked Bugzilla. Anyway...

Of course, I did a few things differently. My code defaults to "don't
touch anything" which is IMHO a reasonable feature. Pier Luigi Fiorini
seems to have an icon for this thing, I can contribute a GConf schema.
Other than that, we seem to do roughly the same thing.

Sorry for the spam, BTW.
Comment 14 Owen Taylor 2003-10-01 21:00:09 UTC
Wouldn't it be better if GNOME just remembered this automatically
and NumLock at the begin of the session just had the same value
as when you logged out?

I don't really see a point in the GUI. If you care about the
setting of NumLock, then you already understand the UI of:

 - The NumLock light on your keyboard
 - The NumLock key

Implementation should be straightforward -- the current state
can be tracked the XKB, and gnome-settings-daemon already 
watches XKB events. So, what you want to do is:

 - When gnome-settings-daemon starts, retrieve the value from
   GConf and set the X server to match
 - When the X server value changes, write it to GConf

I don't think you want to propagate gconf changes => keyboard 
while gnome-settings-daemon is running because of the 
possibility of loops like:

 - User turns NumLock on
 - g-s-d writes to GCOnf
 - User turns NumLock off
 - g-s-d writes to GConf
 - Notification from GConf of NumLock on
 - g-s-d turns NumLock on

Also, it would be weird if you were logged in on several machines,
and toggling NumLock on one toggled it on all.
Comment 15 Jonathan Blandford 2003-10-01 22:36:26 UTC
I like Owen's approach.  Lets remember Caps-lock and (somewhat more
dubiously) Scroll-lock too.
Comment 16 pantz 2003-10-01 22:41:53 UTC
i agree 100% with Owen's idea - remember it from the last login. If
you like it on - turn it on once - and its on until the next time you
touch that numlock key (probably never for me!)

This is something that bugs many new linux users (and me too) and it
would be cool to see it implemented soon.
Comment 17 Sebastian Kapfer 2003-11-01 22:09:01 UTC
Fundamentally, it sounds like a good idea -- GNOME adapting itself
automatically. I don't agree with Owen's exact scheme. IMHO gconfd
should act only at login and logout time. There's no real point in
saving the NumLock's state N times during a session (even if N is
small) when the gconf key isn't read before the next login anyway :-)

I'm a bit more reserved about CapsLock and ScrollLock. Nobody (at
least that's what I imagine) works with the CapsLock on all the time,
and expects it to be active at login time. The precise effects of
ScrollLock under X11 are a mystery to many, including me, so I can't
comment on that one.

Nevertheless, I'd like to introduce another slight twist into the
discussion. I recently purchased a laptop computer, which of course
doesn't have a separate numeric keypad. Instead, the NumLock toggles a
certain block of alphanumerics to become a pseudo-keypad.

Now things are getting funny -- because the NumLock key on the
keyboard doesn't work with the default X keymap! I.e. when something,
be it the GNOME settings daemon or numlockx turns the NumLock on, I'm
having a broken keyboard (without the keys uiojkl and the
point/fullstop) AND NO EASY WAY TO TURN NUMLOCK OFF. You basically
have to copy & paste single letters to form a command line which turns
the NumLock off.

In short, it is actually dangerous to save the NumLock state between
different machines. Maybe one could tie the setting to a certain
hostname, so that machines "laptop" and "desktop" can have distinct
NumLock states in the gconf database?
Comment 18 Luis Villa 2004-04-28 04:41:38 UTC
Comment on attachment 8406 [details] [review]
This patch implement this.

Marking obsolete; this was against cc 1.4.
Comment 19 Luis Villa 2004-04-28 04:42:37 UTC
Comment on attachment 16603 [details] [review]
GUI, actual code

Given comments below, marking needs-work.
Comment 20 Marius Andreiana 2004-10-13 09:24:48 UTC
Owen's proposal is great. Ok to implement like this and mark previos patches as
deprecated, update version, target milestone and remove PATCH keyword?
Comment 21 Jody Goldberg 2004-10-19 18:08:43 UTC
IMO this is rather questionable.
For us to remember the state of some keyboard latch keys and not others seems odd.
If you want this off by default I'd bet there is a bios setting.  Why do we need
this ?
Comment 22 Mattias Eriksson 2004-10-20 07:48:14 UTC
The thing is that the numpad is used by some as arrow-keys (those people like
numlock to be off by default) and as a numpad by others (they want it on by
default). I'm not sure I have a bios-setting for this, but that is not a good
solution since it only works in a one user - one computer environment. For a
multiuser environment things should be handled by the session. 
And just remembering the state of NumLock (or why not all latch keys) would
"Just Work". Ok I can agree that this is not the most important issue in the
world (I currently just include numlockx in my gnome-session), but I think it
would be nice to have.
Comment 23 Sebastian Kapfer 2004-10-20 14:40:27 UTC
The BIOS setting doesn't help anything since both Linux and X reset the numlock
state when they start.
Comment 24 Jody Goldberg 2004-10-20 15:37:33 UTC
sebastian : The bios setting has always worked for me.
mattias : Rembering the latch keys seems a bit odd
    - A user walks up the a terminal to login via gdm and the numlock/capslock
is off.
    - They login and the latches turn on

The user must have known the state of caps lock before logging in orthings would
fail.  Having that state suddenly change seems counter-intuitive to me.
Comment 25 Benjamin LeMasurier 2005-03-14 00:41:46 UTC

I think this got a little blown up. Can we make this simple like it started and 
just say. If I want the numlock key on when I log into gnome, then have it be 
on. Once logged in, we can ignore whether the status of numlock changes. This 
is the default in many operating systems and it is expected by many users. 
Users that are new to Linux get very frustrated about this. It's a simple 
concept with a simple fix.
Comment 26 Sebastian Kapfer 2005-03-14 11:24:46 UTC
The simple fix also has the potential of locking out laptop users.  Unless we
have some way to automatically detect reduced-size laptop keyboards, I really
don't think this is a good idea.
Comment 27 Sergey V. Udaltsov 2005-03-14 11:34:26 UTC
Sebastian: there is real no problem to determine whether particular keyboard has
numlock or not - if we hardcode the indicator name in the code - and assuming
that user using PROPER xkb keyboard model setting (not just "generic pc105" or
Comment 28 Sebastian Kapfer 2005-03-14 13:18:58 UTC
If there was a proper keyboard layout for the laptop in question and that map
was indeed loaded, we'd have no problem at all. Then the user could simply turn
NumLock off by himself (at least users with a clue could -- NumLock probably
isn't part of Granny's computer skills).  The sad thing is, we can assume
neither of those things.

Maybe making it a per-machine and automatically remembered preference would be a
good compromise.  If the user managed to turn NumLock on by himself on a machine
(using whatever methods) he/she could be assumed to be able to turn it off. As
an added benefit, we don't need configuration GUI for it.  It just works, users
won't even notice it.
Comment 29 Sergey V. Udaltsov 2005-03-14 13:48:46 UTC
If user does not load proper keyboard model - we cannot trust XKB on dealing
with NumLock. Any requests of that kind IMVHO should be based on the assumption
that keyboard is properly configured - otherwise no XKB activity can be
considered as "sane" and "helpful".
Comment 30 Sebastian Kapfer 2005-03-14 18:43:49 UTC
What are you proposing to do?  Produce hundreds of almost identical keyboard
mappings for each laptop model?  That would be the right way to proceed, but I
think it's just not feasable. Each laptop keyboard I've seen behaves quite
sanely when used with a standard 10x-keys PC-style layout. That's why no-one
bothers with writing mappings for all of them.  (Besides the fact that
user-readable docs for XKB just don't exist.)

I don't want this to escalate into a flamewar, so please, let's return to the
bug at hand.  Specifically, what makes you unhappy about my suggestion?  It's
not even a hack, it just happens to sidestep a problem in the X configuration
which GNOME cannot reasonably fix.
Comment 31 Sergey V. Udaltsov 2005-03-14 21:05:37 UTC
If 1001 types of laptops are covered by pc105 layout - I am 101% happy. But if
my particular type of laptop has some multimedia keys which are not covered by
pc105 - I either have to find(create) proper XKB configuration (like I did for
my Acer Travelmate) - or file report in xorg bugzilla regarding missing
configuration element(s) - or not complain and shutup (and none of these
variants are related to the GNOME bugzilla). Same about missing NumLock. As a
person, involved in some XKB-related activity, I believe in two things: 1.
Supporting misconfigured keyboards is a waste of time 2. People should have
rights (obligations?:) to complain about X servers not being able to configure
they keyboards properly. That is why I think we can ignore the situation
"locking out laptop users" - well, you can raise separate bug in xorg (Project
Utopia) bugzilla regarding keyboard autodetection, this really makes sense.

Regarding the bug. The solution sounds reasonable.
Comment 32 Benjamin LeMasurier 2005-03-19 18:35:26 UTC
I like Sebastian's suggestion - automatically turning it on sounds even better.
Comment 33 Sergey V. Udaltsov 2005-03-19 23:47:38 UTC
OK, unless someone comes up with the patch - I'll try to address it during 2.12
development cycle...
Comment 34 Sebastian Kapfer 2005-03-20 13:11:13 UTC
I'm working on something, but progress is slow...  I have yet to figure out how
to be notified when NumLock is toggled.  Polling is not an option.
Comment 35 Marius Andreiana 2005-03-20 16:48:23 UTC
Hi. I assume the solution proposed by Owen in #14 will be implemented. 
Why do you need to be notified when NumLock is toggled? Isn't is possible just
to read current value and implement like this:
- on user login, see saved value and set NumLock accordingly (if none set, do
- on logout, get current NumLock value and save it
(not on every change)
Comment 36 Sebastian Kapfer 2005-03-20 17:30:48 UTC
Created attachment 38966 [details] [review]
Patch implementing this

The patch automatically remembers NumLock state between sessions.

* The state is saved per hostname.

* It does only NumLock, no other lock keys (don't make sense IMHO).

* Remembering the lock state can be turned off in GConf, although I don't know
why one should do so.

* Contrary to Owen's advice, my code syncs both ways.  I.e. XKB changes get
written to GConf, GConf changes are applied to the keyboard.  I don't think
there is a reasonably probability of a race condition.

* I didn't turn on NumLock by default because of the Laptop case i sketched
above.	Users will have to press NumLock one time by themselves.

* No GUI is necessary.

* Sorry, the patch is against a 2.8 version, but g-s-d doesn't change that much
Comment 37 Marius Andreiana 2005-03-21 06:08:11 UTC
Hi Sebastian

I have two questions:
1. Why won't this work for localhost?
numlock: Numlock remembering disabled because your hostname is set to \"localhost\".

2. Why don't you check the state of numlock on logout, and instead you check on
every key press:
+static GdkFilterReturn
+numlock_xkb_callback (GdkXEvent *xev_, GdkEvent *gdkev_, gpointer xkb_event_code)

This will eat CPU (in an insignificant way, but I'd disable it rather than
having it check for numlock on every key press, it's not acceptable )


Comment 38 Sebastian Kapfer 2005-03-21 10:24:29 UTC
@1: It just makes no sense to remember NumLock for multiple hosts which all
share the name "localhost".  I don't consider this a practical problem because
machines running with hostname "localhost" are a setup error.  I copied this
behaviour from the XRANDR applet.

@2: The X event I'm using is only triggered at state change of any lock key. 
I.e. in practice, it occurs when the user presses NumLock, Caps, or ScrollLock.
Comment 39 Jürg Billeter 2005-09-27 21:55:06 UTC
Created attachment 52752 [details] [review]
Updated patch

I've updated Sebastian's patch to apply cleanly against HEAD and to add the
necessary change. It seems to work fine here, thanks for the patch,

Jody, jrb, any comments on this patch? Ok to commit after branching for
Comment 40 Sergey V. Udaltsov 2005-09-27 22:39:03 UTC
For me it looks ok.
Comment 41 Jürg Billeter 2005-10-10 19:38:43 UTC
Committed to HEAD.
Comment 42 Marius Andreiana 2005-10-11 06:38:29 UTC
Comment 43 Sebastien Bacher 2005-10-25 20:44:38 UTC
This schemas is shipped by libgnome, you created a conflict with it:  bug
#319788, could you fix ti?
Comment 44 Marius Andreiana 2005-11-02 10:46:11 UTC
*** Bug 319520 has been marked as a duplicate of this bug. ***