i386 AT keyboard LED question.

i386 AT keyboard LED question.

[Nick Warne]

Hi Vojtech,

I wondered why numlock LED goes off during boot process, even though I ask 
BIOS to turn on;

atkbd.c

/*
 * If the get ID command failed, we check if we can at least set the LEDs on
 * the keyboard. This should work on every keyboard out there. It also turns
 * the LEDs off, which we want anyway.
 */
                param[0] = 0;
                if (ps2_command(ps2dev, param, ATKBD_CMD_SETLEDS))
                        return -1;


What is the rationale *why* we want LEDS off anyway?

Thanks,

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb

Re: i386 AT keyboard LED question.

[Vojtech Pavlik]

On Mon, Feb 20, 2006 at 08:03:26PM +0000, Nick Warne wrote:

> Hi Vojtech,
> 
> I wondered why numlock LED goes off during boot process, even though I ask 
> BIOS to turn on;
> 
> atkbd.c
> 
> /*
>  * If the get ID command failed, we check if we can at least set the LEDs on
>  * the keyboard. This should work on every keyboard out there. It also turns
>  * the LEDs off, which we want anyway.
>  */
>                 param[0] = 0;
>                 if (ps2_command(ps2dev, param, ATKBD_CMD_SETLEDS))
>                         return -1;
> 
> 
> What is the rationale *why* we want LEDS off anyway?
 
Some old notebooks forget them on, which makes the keyboard unusable -
you get '4' instead of 'u', etc.

We can't read the LED state anyway (except for going to the BIOS data
structures, which isn't reasonable from the atkbd driver), and we need
to initialize it, so off is the safer default.

Further, this has been the behavior of Linux since it was first
implemented, and thus, in my rewrite of the keyboard handling, I didn't
change it.

It's trivial to change the default lock state in init scripts / xdm
config / X config, too.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: i386 AT keyboard LED question.

[Nick Warne]

On Monday 20 February 2006 20:24, Vojtech Pavlik wrote:
> On Mon, Feb 20, 2006 at 08:03:26PM +0000, Nick Warne wrote:
> > Hi Vojtech,
> >
> > I wondered why numlock LED goes off during boot process, even though I
> > ask BIOS to turn on;

~snip~

> Some old notebooks forget them on, which makes the keyboard unusable -
> you get '4' instead of 'u', etc.

Understand.  I never thought of that!

>
> We can't read the LED state anyway (except for going to the BIOS data
> structures, which isn't reasonable from the atkbd driver), and we need
> to initialize it, so off is the safer default.
>
> Further, this has been the behavior of Linux since it was first
> implemented, and thus, in my rewrite of the keyboard handling, I didn't
> change it.

Thanks for detailed reply - I see now, and didn't know any of this.

> It's trivial to change the default lock state in init scripts / xdm
> config / X config, too.

I boot into init 3, so as I don't reboot much, I always forget to turn numlock 
back on when logging in [failed] - hence the question.

I will look at a local fix rather than a patch for kernel.

Thanks again,

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb

Re: i386 AT keyboard LED question.

[Vojtech Pavlik]

On Mon, Feb 20, 2006 at 08:51:51PM +0000, Nick Warne wrote:
> On Monday 20 February 2006 20:24, Vojtech Pavlik wrote:
> > On Mon, Feb 20, 2006 at 08:03:26PM +0000, Nick Warne wrote:
> > > Hi Vojtech,
> > >
> > > I wondered why numlock LED goes off during boot process, even though I
> > > ask BIOS to turn on;
> 
> ~snip~
> 
> > Some old notebooks forget them on, which makes the keyboard unusable -
> > you get '4' instead of 'u', etc.
> 
> Understand.  I never thought of that!
> 
> >
> > We can't read the LED state anyway (except for going to the BIOS data
> > structures, which isn't reasonable from the atkbd driver), and we need
> > to initialize it, so off is the safer default.
> >
> > Further, this has been the behavior of Linux since it was first
> > implemented, and thus, in my rewrite of the keyboard handling, I didn't
> > change it.
> 
> Thanks for detailed reply - I see now, and didn't know any of this.
> 
> > It's trivial to change the default lock state in init scripts / xdm
> > config / X config, too.
> 
> I boot into init 3, so as I don't reboot much, I always forget to turn numlock 
> back on when logging in [failed] - hence the question.
> 
> I will look at a local fix rather than a patch for kernel.
 
The 'setleds' command in boot.local might be the fix you're looking for.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: i386 AT keyboard LED question.

[linux-os (Dick Johnson)]

On Mon, 20 Feb 2006, Nick Warne wrote:

> On Monday 20 February 2006 20:24, Vojtech Pavlik wrote:
>> On Mon, Feb 20, 2006 at 08:03:26PM +0000, Nick Warne wrote:
>>> Hi Vojtech,
>>>
>>> I wondered why numlock LED goes off during boot process, even though I
>>> ask BIOS to turn on;
>
> ~snip~
>
>> Some old notebooks forget them on, which makes the keyboard unusable -
>> you get '4' instead of 'u', etc.
>
> Understand.  I never thought of that!
>
>>
>> We can't read the LED state anyway (except for going to the BIOS data
>> structures, which isn't reasonable from the atkbd driver), and we need
>> to initialize it, so off is the safer default.
>>
>> Further, this has been the behavior of Linux since it was first
>> implemented, and thus, in my rewrite of the keyboard handling, I didn't
>> change it.
>
> Thanks for detailed reply - I see now, and didn't know any of this.
>
>> It's trivial to change the default lock state in init scripts / xdm
>> config / X config, too.
>
> I boot into init 3, so as I don't reboot much, I always forget to turn numlock
> back on when logging in [failed] - hence the question.
>
> I will look at a local fix rather than a patch for kernel.
>
> Thanks again,
>
> Nick

In .. /etc/rc.d/rc.local
 	/usr/bin/setleds -num /dev/tty0 (or whatever)



Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.49 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: i386 AT keyboard LED question.

[Nick Warne]

On Monday 20 February 2006 20:57, Vojtech Pavlik wrote:

> The 'setleds' command in boot.local might be the fix you're looking for.

On Monday 20 February 2006 21:12, linux-os (Dick Johnson) wrote:
>
> In .. /etc/rc.d/rc.local
>  	/usr/bin/setleds -num /dev/tty0 (or whatever)

I must have made the dork post of the month - sorry for the noise.

setleds +num

is indeed what I needed in rc.local.

Still, at least I learnt a lot about initialising keyboard by reading the 
code.

Thank you!

Nick
-- 
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb

Re: i386 AT keyboard LED question.

[Jan Engelhardt]

> 
>Some old notebooks forget them on, which makes the keyboard unusable -
>you get '4' instead of 'u', etc.
>
Not only old notebooks, but all 84-key keyboards with Num 
functionality are affected AFAICS.


Jan Engelhardt
-- 

Re: i386 AT keyboard LED question.

[Vojtech Pavlik]

On Fri, Feb 24, 2006 at 08:17:19AM +0100, Jan Engelhardt wrote:
> > 
> >Some old notebooks forget them on, which makes the keyboard unusable -
> >you get '4' instead of 'u', etc.
> >
> Not only old notebooks, but all 84-key keyboards with Num 
> functionality are affected AFAICS.
 
If we forced the LED to ON everytime, they would be. If we used the BIOS
setting (by peeking into the BIOS area), then only a few machines would
have a problem - the BIOS defaults are often either correct or
correctable by the user.

-- 
Vojtech Pavlik
Director SuSE Labs