LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Linus' laptop and Num lock status
@ 2007-02-14 18:56 Dax Kelson
  2007-02-14 19:12 ` Linus Torvalds
  0 siblings, 1 reply; 19+ messages in thread
From: Dax Kelson @ 2007-02-14 18:56 UTC (permalink / raw)
  To: linux-kernel; +Cc: Linus Torvalds, Jean Delvare

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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 18:56 Linus' laptop and Num lock status Dax Kelson
@ 2007-02-14 19:12 ` Linus Torvalds
  2007-02-14 19:19   ` Dax Kelson
                     ` (3 more replies)
  0 siblings, 4 replies; 19+ messages in thread
From: Linus Torvalds @ 2007-02-14 19:12 UTC (permalink / raw)
  To: Dax Kelson; +Cc: linux-kernel, Jean Delvare



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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:12 ` Linus Torvalds
@ 2007-02-14 19:19   ` Dax Kelson
  2007-02-14 19:21   ` Jean Delvare
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 19+ messages in thread
From: Dax Kelson @ 2007-02-14 19:19 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, 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.
> 
> 		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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:12 ` Linus Torvalds
  2007-02-14 19:19   ` Dax Kelson
@ 2007-02-14 19:21   ` Jean Delvare
  2007-02-14 19:32     ` Linus Torvalds
  2007-02-15 14:34     ` H. Peter Anvin
  2007-02-14 19:26   ` Arjan van de Ven
  2007-02-15 14:25   ` H. Peter Anvin
  3 siblings, 2 replies; 19+ messages in thread
From: Jean Delvare @ 2007-02-14 19:21 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Dax Kelson, linux-kernel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:12 ` Linus Torvalds
  2007-02-14 19:19   ` Dax Kelson
  2007-02-14 19:21   ` Jean Delvare
@ 2007-02-14 19:26   ` Arjan van de Ven
  2007-02-15 14:25   ` H. Peter Anvin
  3 siblings, 0 replies; 19+ messages in thread
From: Arjan van de Ven @ 2007-02-14 19:26 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Dax Kelson, linux-kernel, 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? ;)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:21   ` Jean Delvare
@ 2007-02-14 19:32     ` Linus Torvalds
  2007-02-14 21:34       ` Dax Kelson
  2007-02-18 16:19       ` Jean Delvare
  2007-02-15 14:34     ` H. Peter Anvin
  1 sibling, 2 replies; 19+ messages in thread
From: Linus Torvalds @ 2007-02-14 19:32 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Dax Kelson, linux-kernel



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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:32     ` Linus Torvalds
@ 2007-02-14 21:34       ` Dax Kelson
  2007-02-14 21:58         ` Jan Engelhardt
  2007-02-18 16:19       ` Jean Delvare
  1 sibling, 1 reply; 19+ messages in thread
From: Dax Kelson @ 2007-02-14 21:34 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jean Delvare, linux-kernel

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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 21:34       ` Dax Kelson
@ 2007-02-14 21:58         ` Jan Engelhardt
  2007-02-15  0:06           ` Krzysztof Halasa
  2007-02-15  0:31           ` Alan
  0 siblings, 2 replies; 19+ messages in thread
From: Jan Engelhardt @ 2007-02-14 21:58 UTC (permalink / raw)
  To: Dax Kelson; +Cc: Linus Torvalds, Jean Delvare, linux-kernel

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/

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 21:58         ` Jan Engelhardt
@ 2007-02-15  0:06           ` Krzysztof Halasa
  2007-02-20 13:57             ` Helge Hafting
  2007-02-15  0:31           ` Alan
  1 sibling, 1 reply; 19+ messages in thread
From: Krzysztof Halasa @ 2007-02-15  0:06 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Dax Kelson, Linus Torvalds, Jean Delvare, linux-kernel

Jan Engelhardt <jengelh@linux01.gwdg.de> 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 21:58         ` Jan Engelhardt
  2007-02-15  0:06           ` Krzysztof Halasa
@ 2007-02-15  0:31           ` Alan
  1 sibling, 0 replies; 19+ messages in thread
From: Alan @ 2007-02-15  0:31 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Dax Kelson, Linus Torvalds, Jean Delvare, linux-kernel

On Wed, 14 Feb 2007 22:58:42 +0100 (MET)
Jan Engelhardt <jengelh@linux01.gwdg.de> 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:12 ` Linus Torvalds
                     ` (2 preceding siblings ...)
  2007-02-14 19:26   ` Arjan van de Ven
@ 2007-02-15 14:25   ` H. Peter Anvin
  3 siblings, 0 replies; 19+ messages in thread
From: H. Peter Anvin @ 2007-02-15 14:25 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Dax Kelson, linux-kernel, Jean Delvare

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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:21   ` Jean Delvare
  2007-02-14 19:32     ` Linus Torvalds
@ 2007-02-15 14:34     ` H. Peter Anvin
  2007-02-18 16:04       ` Jean Delvare
  1 sibling, 1 reply; 19+ messages in thread
From: H. Peter Anvin @ 2007-02-15 14:34 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Linus Torvalds, Dax Kelson, linux-kernel

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




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-15 14:34     ` H. Peter Anvin
@ 2007-02-18 16:04       ` Jean Delvare
  2007-02-18 17:32         ` H. Peter Anvin
  2007-02-18 17:54         ` Randy Dunlap
  0 siblings, 2 replies; 19+ messages in thread
From: Jean Delvare @ 2007-02-18 16:04 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Linus Torvalds, Dax Kelson, linux-kernel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-14 19:32     ` Linus Torvalds
  2007-02-14 21:34       ` Dax Kelson
@ 2007-02-18 16:19       ` Jean Delvare
  1 sibling, 0 replies; 19+ messages in thread
From: Jean Delvare @ 2007-02-18 16:19 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Dax Kelson, linux-kernel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-18 16:04       ` Jean Delvare
@ 2007-02-18 17:32         ` H. Peter Anvin
  2007-02-18 18:06           ` Randy Dunlap
  2007-02-18 17:54         ` Randy Dunlap
  1 sibling, 1 reply; 19+ messages in thread
From: H. Peter Anvin @ 2007-02-18 17:32 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Linus Torvalds, Dax Kelson, linux-kernel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-18 16:04       ` Jean Delvare
  2007-02-18 17:32         ` H. Peter Anvin
@ 2007-02-18 17:54         ` Randy Dunlap
  1 sibling, 0 replies; 19+ messages in thread
From: Randy Dunlap @ 2007-02-18 17:54 UTC (permalink / raw)
  To: Jean Delvare; +Cc: H. Peter Anvin, Linus Torvalds, Dax Kelson, linux-kernel

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 ***

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-18 17:32         ` H. Peter Anvin
@ 2007-02-18 18:06           ` Randy Dunlap
  2007-02-19  0:26             ` H. Peter Anvin
  0 siblings, 1 reply; 19+ messages in thread
From: Randy Dunlap @ 2007-02-18 18:06 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Jean Delvare, Linus Torvalds, Dax Kelson, linux-kernel

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 ***

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-18 18:06           ` Randy Dunlap
@ 2007-02-19  0:26             ` H. Peter Anvin
  0 siblings, 0 replies; 19+ messages in thread
From: H. Peter Anvin @ 2007-02-19  0:26 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Jean Delvare, Linus Torvalds, Dax Kelson, linux-kernel

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Linus' laptop and Num lock status
  2007-02-15  0:06           ` Krzysztof Halasa
@ 2007-02-20 13:57             ` Helge Hafting
  0 siblings, 0 replies; 19+ messages in thread
From: Helge Hafting @ 2007-02-20 13:57 UTC (permalink / raw)
  To: Krzysztof Halasa
  Cc: Jan Engelhardt, Dax Kelson, Linus Torvalds, Jean Delvare, linux-kernel

Krzysztof Halasa wrote:
> Jan Engelhardt <jengelh@linux01.gwdg.de> 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2007-02-20 14:00 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-14 18:56 Linus' laptop and Num lock status Dax Kelson
2007-02-14 19:12 ` Linus Torvalds
2007-02-14 19:19   ` Dax Kelson
2007-02-14 19:21   ` Jean Delvare
2007-02-14 19:32     ` Linus Torvalds
2007-02-14 21:34       ` Dax Kelson
2007-02-14 21:58         ` Jan Engelhardt
2007-02-15  0:06           ` Krzysztof Halasa
2007-02-20 13:57             ` Helge Hafting
2007-02-15  0:31           ` Alan
2007-02-18 16:19       ` Jean Delvare
2007-02-15 14:34     ` H. Peter Anvin
2007-02-18 16:04       ` Jean Delvare
2007-02-18 17:32         ` H. Peter Anvin
2007-02-18 18:06           ` Randy Dunlap
2007-02-19  0:26             ` H. Peter Anvin
2007-02-18 17:54         ` Randy Dunlap
2007-02-14 19:26   ` Arjan van de Ven
2007-02-15 14:25   ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).