A small program to control numlock in X is found at:

http://dforce.sh.cvut.cz/~seli/en/khotkeys/numlock.php3

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.

Created attachment 8406 [details] [review]
This patch implement this.

No idea if this is useful/desired or not... Rachel?

*** Bug 70362 has been marked as a duplicate of this bug. ***

I think it would be useless. Why would you want to do this for? 

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
numbers. 
But since old window managers (fvwm) used to have trouble handling the
numlock setting it is traditionally turned off by default in unix
environment.
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.

SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch
these all and delete them. :) 

-maint, what do you think of this rationale/patch?

Can we decide either for or against this once and for all?

Created attachment 16603 [details] [review]
GUI, actual code

Created attachment 16604 [details] [review]
GConf schema

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.

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.

I like Owen's approach.  Lets remember Caps-lock and (somewhat more
dubiously) Scroll-lock too.

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.

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 on attachment 8406 [details] [review]
This patch implement this.

Marking obsolete; this was against cc 1.4.

Comment on attachment 16603 [details] [review]
GUI, actual code

Given comments below, marking needs-work.

Owen's proposal is great. Ok to implement like this and mark previos patches as
deprecated, update version, target milestone and remove PATCH keyword?

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 ?

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.

The BIOS setting doesn't help anything since both Linux and X reset the numlock
state when they start.

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.

ping.. 


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.

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.

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

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.

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

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.

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.

I like Sebastian's suggestion - automatically turning it on sounds even better.

OK, unless someone comes up with the patch - I'll try to address it during 2.12
development cycle...

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.

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
nothing)
- on logout, get current NumLock value and save it
(not on every change)

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

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 )

Thanks

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

Created attachment 52752 [details] [review]
Updated patch

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

Jody, jrb, any comments on this patch? Ok to commit after branching for
gnome-2-12?

For me it looks ok.

Committed to HEAD.

Hurray!

This schemas is shipped by libgnome, you created a conflict with it:  bug
#319788, could you fix ti?

*** Bug 319520 has been marked as a duplicate of this bug. ***