You are not logged in.
Pages: 1
Any Linux computer (well, that are about 3 very regular and a few of other people) I've ever used, has had this same problem:
In a text mode terminal, or in a graphical desktop, often the num lock light of the keyboard does not correctly represent the state of the num lock keys.
Often the light is on but the keys are arrows/ins/etc... instead of numbers
Pressing num lock twice in a row usually fixes this.
This is very confusing and annoying.
And *everything* has got it. Gnome has got it. KDE has got it. Text-mode terminal windows have got it. Pressing "CTRL+ALT+F6" to go to a different virtual terminal has got it. Config files for graphical desktops to boot up with num lock on have got it. Archlinux has got it. Ubuntu has got it. Old kernels have got it. The newest kernels have got it. Eight year old computers with Linux have got it. Brand new computers with Linux have got it. It can happen after standby. After bootup.
This bug is omnipresent in Linux.
It's as if Linux isn't able to correctly synchronize the num lock light with the way it interprets the numpad keys. To be honest, before being a Linux user I thought the keyboard hardware controlled this light, but the Linux bug (and config options to have it on or off at bootup) shows it's the OS that does it.
This bug is so obvious (and frigging annoying) that I wonder: WHY? Why was this issue never fixed?
P.S. I'm not even talking about the default or preferred state the num lock key should have. I'm simply talking about the fact that the light is on but the keys act as if it's off, or vice-versa.
Last edited by aardwolf (2010-03-01 13:24:20)
Offline
I have 7 computers running Linux, and I have never encountered such bug...
what goes up must come down
Offline
Perhaps http://www.archlinux.org/packages/extra/i686/numlockx/ would help with X.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
One might use setleds in /etc/rc to define the initial and default state of NumLock, e.g. by
INITTY=/dev/tty[1-8]
for tty in $INITTY; do
setleds -D +num < $tty
done
have you tried this method in /etc/rc.local?
my thinking is this:
that setting in rc.local will set your numlock ON in tty (and turn the light on). whereas numlockx (or some variant, presumably used by GNOME, KDE, etc) will set your numlock ON in X but the light may still be driven by your OFF setting in tty1 or 6? then, pressing numlock twice gets it all back in sync.
i dunno, worth a try. i use both (rc.local and numlockx) but i don't have a light indicator on my keyboard so i have no idea.
//github/
Offline
man setleds wrote:One might use setleds in /etc/rc to define the initial and default state of NumLock, e.g. by
INITTY=/dev/tty[1-8]
for tty in $INITTY; do
setleds -D +num < $tty
donehave you tried this method in /etc/rc.local?
my thinking is this:
that setting in rc.local will set your numlock ON in tty (and turn the light on). whereas numlockx (or some variant, presumably used by GNOME, KDE, etc) will set your numlock ON in X but the light may still be driven by your OFF setting in tty1 or 6? then, pressing numlock twice gets it all back in sync.
i dunno, worth a try. i use both (rc.local and numlockx) but i don't have a light indicator on my keyboard so i have no idea.
The ring of truth! Excellent reasoning, I think.
Offline
I have checked how my num lock led behaves right now.
I use the tty stuff brisbin33 posted in my rc.local and have numlockx & just before starting openbox.
with this setup the led is default off when I start up and even if I turn the led on in tty, start and stop x it just turn off, though num lock is still on.
TBH I don't really mind this bug. I always have num lock turned on, so I never have to check if its on or not.
Offline
Default state of leds really hasn't got that much to do with this problem. What is a default state of the led worth if the LED is on while they keys behave ar arrows or vice versa.
This are so many incarnations of this bug, it's uncountable.
For example I'm working on KDE 4 here, and when leaving the computer on for a night so it goes to standby, then the next day, the num lock is inversed. Num lock on, arrow keys, num lock off, number keys. And this time pressing num lock twice doesn't do anything, it's really reversed.
You may call this a KDE 4 bug, but as I said, text mode terminals and Gnome also have various num lock problems. If it'd be a KDE 4 bug, then that would mean developers of a graphical user desktop would actually have to care about the num lock state, which is already strange on its own imho (and clearly causes LOTS of bugs in ANY graphical desktop).
Offline
Did some simple experimenting with two separate instances of X running. I start them both with Num Lock off (behaves off, LED's off). If I turn it on in one X, it isn't turned on in the other; when I switch to that other X the Nul Lock LED is out of sync (LED on but Num Lock is off): I have to press it once to update the state of X while the LED's state doesn't change.
It seems each X session keeps track of its own Num Lock state but the Num Lock LED is only updated when Num Lock is toggled (switching between instances of X that have a different Num Lock state will not toggle the LED; in one of the Xs the LED will be wrong). Pressing the Num Lock key toggles the state of Num Lock in the current X instance and sets the LED to the proper state.
However when I switch between X and a linux virtual terminal the state of Num Lock and the LED are updated/synced properly.
But I swear sometimes out of the corner of my eye I can see that Num Lock light toggle without me having pressed anything. Am I crazy?
P.S. I don't have numlockx and my /etc/rc.local is empty.
Offline
I only ever use the numpad for the forward slash and asterisk (because they're otherwise shifted characters on the german keyboard), and those work regardless of numlock status.
Last edited by Krause (2010-05-20 15:01:54)
Offline
That's really funny. My LED works perfectly fine. Don't think it's related to DE or WM. Personally I'm running awesome. But I've got a few machines at work, running Gnome, KDE, LXDE, and xfce. As far as I'm aware, none of them have this 'magically' switching num lock LED light.
But then ... maybe it's only switching when I'm not looking.
Offline
Kind of related to what brisbin33 said:
I think the problem has something to do with hand-off of keyboard control from X11 to tty and vice verse, if I vt switch between tty[1-6] things will behave right (that is, if I set numlock on in tty5 then switch to tty6 the numlock light turns off, then back on when I switch back to tty5), but if I vt switch from tty6 where numlock is off, to X11 on tty7, then the numlock LED doesn't toggle. And vice-versa.
Both X11 and the console seem to deal with numlock properly on their own, they just don't update the LED when you switch between the two. I suspect that this must be difficult to fix because I can't imagine any other reason why nobody has. (Or perhaps the fixing must be done in Xorg and can't be done in a cross-platform way ... hence nobody will fix it?)
Offline
My Num Lock LED turns off when I change my keyboard layout with setxkbmap... but the Num Lock status doesn't change. I think I'ma file a bug for this one.
Offline
Pages: 1