Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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. /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 *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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? ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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? ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
