According to the lore(1) the reason that the kernel unconditionally
turns off the num lock was so that Linus' laptop came up ready to type.
The issue is that if you force num lock on, then laptop users are messed
up since for most laptops your keyboard changes as follows:
7890 = 789*
uiop = 456-
jkl; = 123+
m./ = 0./
So the only safe choice is "force off" or "Follow BIOS" (preferable).
Are there any technical or political reasons why kernel can't change
from "force off" to "Follow BIOS"?
Some distributions implement "Follow BIOS" in their bootup scripts but
the most just follow the kernel. IMHO, it would be very nice if the
"Follow BIOS" was done by the kernel so this would Just Work(tm)
everywhere in all situations (such as rescue environments where the
normal bootup scripts aren't processed).
Thanks,
Dax Kelson
(1)
http://www.redhat.com/archives/fedora-test-list/2003-September/msg00713.html
On Wed, 14 Feb 2007, Dax Kelson wrote:
>
> Are there any technical or political reasons why kernel can't change
> from "force off" to "Follow BIOS"?
How would you query it? I'm not even 100% sure that you can on all
keyboards. We never query the leds, we always set them. I think. I don't
know of any AT kbd command to read the led state out of the keyboard.
Linus
On Wed, 2007-02-14 at 11:12 -0800, Linus Torvalds wrote:
>
> On Wed, 14 Feb 2007, Dax Kelson wrote:
> >
> > Are there any technical or political reasons why kernel can't change
> > from "force off" to "Follow BIOS"?
>
> How would you query it? I'm not even 100% sure that you can on all
> keyboards. We never query the leds, we always set them. I think. I don't
> know of any AT kbd command to read the led state out of the keyboard.
>
> Linus
The GPL'd "hwinfo" command shipped with SUSE queries the BIOS setting by
reading a single byte from /dev/mem.
In src/hd/bios.c around line 262 it has:
if(hd_data->bios_ram.data) {
bios_ram = hd_data->bios_ram.data;
[snip]
bt->led.scroll_lock = bios_ram[0x97] & 1;
bt->led.num_lock = (bios_ram[0x97] >> 1) & 1;
bt->led.caps_lock = (bios_ram[0x97] >> 2) & 1;
bt->led.ok = 1;
Cut-n-paste commands to get to the source:
cd /tmp
wget http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/hwinfo-13.21-3.src.rpm
rpm2cpio < hwinfo-13.21-3.src.rpm | cpio -id
tar jxf hwinfo-13.21.tar.bz2
cd hwinfo-13.21/src/hd
Dax Kelson
Hi Linus,
On Wed, 14 Feb 2007 11:12:23 -0800 (PST), Linus Torvalds wrote:
> On Wed, 14 Feb 2007, Dax Kelson wrote:
> > Are there any technical or political reasons why kernel can't change
> > from "force off" to "Follow BIOS"?
>
> How would you query it? I'm not even 100% sure that you can on all
> keyboards. We never query the leds, we always set them. I think. I don't
> know of any AT kbd command to read the led state out of the keyboard.
On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
RAM (offset 0x497). This is how Suse's hwinfo does.
But maybe the first question to ask is: why is the BIOS setting lost in
the first place? Why is the kernel resetting the led state?
--
Jean Delvare
On Wed, 2007-02-14 at 11:12 -0800, Linus Torvalds wrote:
>
> On Wed, 14 Feb 2007, Dax Kelson wrote:
> >
> > Are there any technical or political reasons why kernel can't change
> > from "force off" to "Follow BIOS"?
>
> How would you query it? I'm not even 100% sure that you can on all
> keyboards. We never query the leds, we always set them. I think. I don't
> know of any AT kbd command to read the led state out of the keyboard.
and if there was one.. wanne take bets on how well it works with the
various SMM emulated USB keyboards out there? ;)
On Wed, 14 Feb 2007, Jean Delvare wrote:
>
> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> RAM (offset 0x497). This is how Suse's hwinfo does.
Heh. Shows just how much I ever used DOS and BIOS.
> But maybe the first question to ask is: why is the BIOS setting lost in
> the first place? Why is the kernel resetting the led state?
Ehh. Silly question. "Those flags, they do nothing."
The kernel needs to know what they are in order to react correctly to
them. And since you can't read them from hardware, the only way to know
what they are (if you don't know about BIOS magic areas) is to SET THEM.
Which is what the kernel has traditionally always done.
Linus
On Wed, 2007-02-14 at 11:32 -0800, Linus Torvalds wrote:
>
> On Wed, 14 Feb 2007, Jean Delvare wrote:
> >
> > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> > RAM (offset 0x497). This is how Suse's hwinfo does.
>
> Heh. Shows just how much I ever used DOS and BIOS.
>
> > But maybe the first question to ask is: why is the BIOS setting lost in
> > the first place? Why is the kernel resetting the led state?
>
> Ehh. Silly question. "Those flags, they do nothing."
>
> The kernel needs to know what they are in order to react correctly to
> them. And since you can't read them from hardware, the only way to know
> what they are (if you don't know about BIOS magic areas) is to SET THEM.
>
> Which is what the kernel has traditionally always done.
Going forward can the kernel peek at 0x497 and follow the BIOS setting?
I checked, and looking at offset 0x497 seems to work fine on a couple of
systems with USB keyboards.
People have long grumbled and complained about the current kernel
behavior (1).
Dax Kelson
(1)
http://lkml.org/lkml/1999/2/27/6
http://www.google.com/search?q=linux+num+lock
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115909
Hi,
On Feb 14 2007 14:34, Dax Kelson wrote:
>
>I checked, and looking at offset 0x497 seems to work fine on a couple of
>systems with USB keyboards.
Probably just because legacy mode was enabled. Plus I wonder what 0x497 will
return when there is actually more than one USB keyboard connected at boot.
Jan
--
ft: http://freshmeat.net/p/chaostables/
On Wed, 14 Feb 2007 22:58:42 +0100 (MET)
Jan Engelhardt <[email protected]> wrote:
> Probably just because legacy mode was enabled. Plus I wonder what 0x497 will
> return when there is actually more than one USB keyboard connected at boot.
The BIOS initial numlock value which is a singular value.
Alan
Jan Engelhardt <[email protected]> writes:
>>I checked, and looking at offset 0x497 seems to work fine on a couple of
>>systems with USB keyboards.
>
> Probably just because legacy mode was enabled. Plus I wonder what 0x497 will
> return when there is actually more than one USB keyboard connected at boot.
I bet all would share LED states. If you can use multiple keyboards
in legacy mode at all, of course.
--
Krzysztof Halasa
Linus Torvalds wrote:
>
> On Wed, 14 Feb 2007, Dax Kelson wrote:
>> Are there any technical or political reasons why kernel can't change
>> from "force off" to "Follow BIOS"?
>
> How would you query it? I'm not even 100% sure that you can on all
> keyboards. We never query the leds, we always set them. I think. I don't
> know of any AT kbd command to read the led state out of the keyboard.
>
You can query the state of the keyboard according to BIOS by looking in
byte 0x417 absolute, or by issuing int 0x16, ah = 0x02 (or ah = 0x12)
from real mode.
-hpa
Jean Delvare wrote:
>
> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> RAM (offset 0x497). This is how Suse's hwinfo does.
>
Perhaps that's what Suse does, but the proper address is 0x417.
0x497 is the rarely-used LPT2 timeout ocunter.
-hpa
On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
> Jean Delvare wrote:
> > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> > RAM (offset 0x497). This is how Suse's hwinfo does.
>
> Perhaps that's what Suse does, but the proper address is 0x417.
>
> 0x497 is the rarely-used LPT2 timeout counter.
Still, the information printed by hwinfo is correct, I've tested it
myself. Is there some publicly available documentation about the x86
BIOS RAM mapping?
Thanks,
--
Jean Delvare
Hi Linus,
On Wed, 14 Feb 2007 11:32:34 -0800 (PST), Linus Torvalds wrote:
> On Wed, 14 Feb 2007, Jean Delvare wrote:
> > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> > RAM (offset 0x497). This is how Suse's hwinfo does.
>
> Heh. Shows just how much I ever used DOS and BIOS.
Well, I didn't know about it either before I was told about how hwinfo
was able to retrieve the information.
> > But maybe the first question to ask is: why is the BIOS setting lost in
> > the first place? Why is the kernel resetting the led state?
>
> Ehh. Silly question. "Those flags, they do nothing."
>
> The kernel needs to know what they are in order to react correctly to
> them. And since you can't read them from hardware, the only way to know
> what they are (if you don't know about BIOS magic areas) is to SET THEM.
>
> Which is what the kernel has traditionally always done.
OK, it makes sense, thanks for clarifying this point.
Would it be acceptable to add some code in the kernel to read the
settings from the BIOS where possible, and have the kernel write these
settings rather than the default "all LEDs disabled"?
The problem is that I don't know how we can know for sure whether there
is BIOS RAM to read from, or not. Now that some x86-based system use
EFI instead of a traditional BIOS, I guess we can't just assume that
x86 or x86-64 implies there's a BIOS.
--
Jean Delvare
Jean Delvare wrote:
> On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
>> Jean Delvare wrote:
>>> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
>>> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
>>> RAM (offset 0x497). This is how Suse's hwinfo does.
>> Perhaps that's what Suse does, but the proper address is 0x417.
>>
>> 0x497 is the rarely-used LPT2 timeout counter.
>
> Still, the information printed by hwinfo is correct, I've tested it
> myself. Is there some publicly available documentation about the x86
> BIOS RAM mapping?
>
Google for Ralf Brown's Interrupt List.
-hpa
On Sun, 18 Feb 2007 17:04:01 +0100 Jean Delvare wrote:
> On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
> > Jean Delvare wrote:
> > > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> > > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> > > RAM (offset 0x497). This is how Suse's hwinfo does.
> >
> > Perhaps that's what Suse does, but the proper address is 0x417.
> >
> > 0x497 is the rarely-used LPT2 timeout counter.
>
> Still, the information printed by hwinfo is correct, I've tested it
> myself. Is there some publicly available documentation about the x86
> BIOS RAM mapping?
Hilo,
0x40:0x17 is called "keyboard control" and
0x40:0x97 is called "keyboard LED flags" in the IBM Personal
System/2 and Personal Computer BIOS Interface Technical Reference,
Section 3: Data Areas and ROM Tables.
<internet_search> /bios data areas tables/ ::
http://heim.ifi.uio.no/~stanisls/helppc/bios_data_area.html
http://heim.ifi.uio.no/~stanisls/helppc/kb_flags.html
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Sun, 18 Feb 2007 09:32:15 -0800 H. Peter Anvin wrote:
> Jean Delvare wrote:
> > On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
> >> Jean Delvare wrote:
> >>> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> >>> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> >>> RAM (offset 0x497). This is how Suse's hwinfo does.
> >> Perhaps that's what Suse does, but the proper address is 0x417.
> >>
> >> 0x497 is the rarely-used LPT2 timeout counter.
> >
> > Still, the information printed by hwinfo is correct, I've tested it
> > myself. Is there some publicly available documentation about the x86
> > BIOS RAM mapping?
> >
>
> Google for Ralf Brown's Interrupt List.
(Ralph)
I didn't find the BIOS data areas/tables in Ralph's web pages...
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Randy Dunlap wrote:
> On Sun, 18 Feb 2007 09:32:15 -0800 H. Peter Anvin wrote:
>
>> Jean Delvare wrote:
>>> On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
>>>> Jean Delvare wrote:
>>>>> On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
>>>>> BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
>>>>> RAM (offset 0x497). This is how Suse's hwinfo does.
>>>> Perhaps that's what Suse does, but the proper address is 0x417.
>>>>
>>>> 0x497 is the rarely-used LPT2 timeout counter.
>>> Still, the information printed by hwinfo is correct, I've tested it
>>> myself. Is there some publicly available documentation about the x86
>>> BIOS RAM mapping?
>>>
>> Google for Ralf Brown's Interrupt List.
>
> (Ralph)
>
> I didn't find the BIOS data areas/tables in Ralph's web pages...
>
It's called memory.lst in the Interrupt List.
-hpa
Krzysztof Halasa wrote:
> Jan Engelhardt <[email protected]> writes:
>
>
>>> I checked, and looking at offset 0x497 seems to work fine on a couple of
>>> systems with USB keyboards.
>>>
>> Probably just because legacy mode was enabled. Plus I wonder what 0x497 will
>> return when there is actually more than one USB keyboard connected at boot.
>>
>
> I bet all would share LED states. If you can use multiple keyboards
> in legacy mode at all, of course.
>
I have used multiple keyboards, for a 2-user machine.
The bios interact with only one of the keyboards, and track LED state on
that.
Other keyboard(s) become useful once the linux comes up with
its event interface. You then have one set of LEDS per keyboard.
Helge Hafting