On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> >> That being said, one could argue that since this is a BIOS interface it
> >> should be queried via INT 16h, AH=02h and stuffed in the zeropage
> >> structure. This would also solve the issue of it not being supported by
> >> non
Bodo Eggert wrote:
>
>> That being said, one could argue that since this is a BIOS interface it
>> should be queried via INT 16h, AH=02h and stuffed in the zeropage
>> structure. This would also solve the issue of it not being supported by
>> non-BIOS firmware.
>
> This is an interesting option,
On Wed, 11 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > Instead of the byte at 0x497 as suggested in that thread, I'm using the
> > byte at 0x417, which reflects the intended LED state. In order to change
> > the keyboard LED, DOS programs would change this byte and call INT 5
> > (w
Bodo Eggert wrote:
>
> Instead of the byte at 0x497 as suggested in that thread, I'm using the
> byte at 0x417, which reflects the intended LED state. In order to change
> the keyboard LED, DOS programs would change this byte and call INT 5
> (which is the keyboard software interrupt).
>
0x417
As discussed in the thread "Linus' laptop and Num lock status", the
numlock setting may cause some laptop keyboards to turn on the numeric key
part, so cannot be safely enabled on those systems. Unfortunately we can't
tell if the current system is one of these laptops nor can we read the
numloc
5 matches
Mail list logo