The PC BIOS does provide a NUMLOCK flag containing the desired state of this
LED. Use it.
Signed-off-by: Bodo Eggert <[email protected]>
---
char/keyboard.c | 17 +++++++++++++++--
input/keyboard/Kconfig | 11 +++++++++++
2 files changed, 26 insertions(+), 2 deletions(-)
diff -pruNXdontdiff linux-2.6.27.softpanic/drivers/char/keyboard.c linux-2.6.27.2-numlock/drivers/char/keyboard.c
--- linux-2.6.27.softpanic/drivers/char/keyboard.c 2008-10-10 13:18:18.000000000 +0200
+++ linux-2.6.27.2-numlock/drivers/char/keyboard.c 2008-10-10 20:34:44.000000000 +0200
@@ -24,6 +24,7 @@
* 21-08-02: Converted to input API, major cleanup. (Vojtech Pavlik)
*/
+#include <asm/io.h>
#include <linux/consolemap.h>
#include <linux/module.h>
#include <linux/sched.h>
@@ -61,7 +62,10 @@ extern void ctrl_alt_del(void);
* to be used for numbers.
*/
-#if defined(CONFIG_PARISC) && (defined(CONFIG_KEYBOARD_HIL) || defined(CONFIG_KEYBOARD_HIL_OLD))
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+/* KBD_DEFLEDS is a variable */
+#undef KBD_DEFLEDS
+#elif defined(CONFIG_PARISC) && (defined(CONFIG_KEYBOARD_HIL) || defined(CONFIG_KEYBOARD_HIL_OLD))
#define KBD_DEFLEDS (1 << VC_NUMLOCK)
#else
#define KBD_DEFLEDS 0
@@ -1406,8 +1410,17 @@ int __init kbd_init(void)
{
int i;
int error;
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+ int KBD_DEFLEDS = 0;
+ /* address 0x40:0x17 */
+ char * bios_kbd_status=xlate_dev_mem_ptr(0x417);
+
+ /* Numlock status bit set? */
+ if (*bios_kbd_status & 0x20)
+ KBD_DEFLEDS = 1 << VC_NUMLOCK;
+#endif
- for (i = 0; i < MAX_NR_CONSOLES; i++) {
+ for (i = 0; i < MAX_NR_CONSOLES; i++) {
kbd_table[i].ledflagstate = KBD_DEFLEDS;
kbd_table[i].default_ledflagstate = KBD_DEFLEDS;
kbd_table[i].ledmode = LED_SHOW_FLAGS;
diff -pruNXdontdiff linux-2.6.27.softpanic/drivers/input/keyboard/Kconfig linux-2.6.27.2-numlock/drivers/input/keyboard/Kconfig
--- linux-2.6.27.softpanic/drivers/input/keyboard/Kconfig 2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.27.2-numlock/drivers/input/keyboard/Kconfig 2008-10-10 20:33:52.000000000 +0200
@@ -12,6 +12,17 @@ menuconfig INPUT_KEYBOARD
if INPUT_KEYBOARD
+config KBD_DEFLEDS_PCBIOS
+ bool "Enable Num-Lock based on BIOS settings"
+ depends on X86_PC && EXPERIMENTAL
+ help
+ Turns on Numlock depending on the BIOS settings.
+ This works by reading the BIOS data area as defined for IBM PCs (1981).
+
+ If you have an alternative firmware like OpenFirmware or LinuxBios,
+ this flag might not be set correctly, which results in a random state
+ of the Numlock key.
+
config KEYBOARD_ATKBD
tristate "AT keyboard" if EMBEDDED || !X86_PC
default y
--
"Oh Guru, what is the secret of Life?"
"Enjoy the journey, because the destination sucks."
-- Gandalf Parker
Hello,
Bodo Eggert, le Thu 16 Oct 2008 13:59:49 +0200, a ?crit :
> + If you have an alternative firmware like OpenFirmware or LinuxBios,
> + this flag might not be set correctly, which results in a random state
> + of the Numlock key.
That's an issue. That means that distributions will just not enable,
and thus the flag is not really useful, since people who would
compile their own kernel would very likely have already setup their
initialization scripts into calling setleds +num (or just set LEDS=+num
in /etc/console-tools/config on a debian machine).
Samuel
On Thu, 16 Oct 2008, Samuel Thibault wrote:
> Bodo Eggert, le Thu 16 Oct 2008 13:59:49 +0200, a ?crit :
> > + If you have an alternative firmware like OpenFirmware or LinuxBios,
> > + this flag might not be set correctly, which results in a random state
> > + of the Numlock key.
>
> That's an issue. That means that distributions will just not enable,
> and thus the flag is not really useful, since people who would
> compile their own kernel would very likely have already setup their
> initialization scripts into calling setleds +num (or just set LEDS=+num
> in /etc/console-tools/config on a debian machine).
I hope somebody will pop up and say "Hey, those will create an IBM PC data
area, because they run DOS" ...
--
"Try to look unimportant; they may be low on ammo."
-Infantry Journal
Bodo Eggert, le Thu 16 Oct 2008 20:00:31 +0200, a ?crit :
> On Thu, 16 Oct 2008, Samuel Thibault wrote:
> > Bodo Eggert, le Thu 16 Oct 2008 13:59:49 +0200, a ?crit :
>
> > > + If you have an alternative firmware like OpenFirmware or LinuxBios,
> > > + this flag might not be set correctly, which results in a random state
> > > + of the Numlock key.
> >
> > That's an issue. That means that distributions will just not enable,
> > and thus the flag is not really useful, since people who would
> > compile their own kernel would very likely have already setup their
> > initialization scripts into calling setleds +num (or just set LEDS=+num
> > in /etc/console-tools/config on a debian machine).
>
> I hope somebody will pop up and say "Hey, those will create an IBM PC data
> area, because they run DOS" ...
Mmm, or rather "hey, here are the patches to fix those BIOSes" :)
Samuel
On Thu 2008-10-16 21:11:06, Samuel Thibault wrote:
> Bodo Eggert, le Thu 16 Oct 2008 20:00:31 +0200, a ?crit :
> > On Thu, 16 Oct 2008, Samuel Thibault wrote:
> > > Bodo Eggert, le Thu 16 Oct 2008 13:59:49 +0200, a ?crit :
> >
> > > > + If you have an alternative firmware like OpenFirmware or LinuxBios,
> > > > + this flag might not be set correctly, which results in a random state
> > > > + of the Numlock key.
> > >
> > > That's an issue. That means that distributions will just not enable,
> > > and thus the flag is not really useful, since people who would
> > > compile their own kernel would very likely have already setup their
> > > initialization scripts into calling setleds +num (or just set LEDS=+num
> > > in /etc/console-tools/config on a debian machine).
> >
> > I hope somebody will pop up and say "Hey, those will create an IBM PC data
> > area, because they run DOS" ...
>
> Mmm, or rather "hey, here are the patches to fix those BIOSes" :)
Broken bioses being around should not penalize working bioses. Patch
looks good to me. Yes, I consider LinuxBios broken in this regard.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html