Date: Mon, 20 Feb 2006 21:24:41 +0100
From: Vojtech Pavlik <vojtech@suse.cz>
To: Nick Warne <nick@linicks.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: i386 AT keyboard LED question.
Message-ID: <20060220202441.GB31272@suse.cz>
References: <200602202003.26642.nick@linicks.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200602202003.26642.nick@linicks.net>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1419
Lines: 43

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/