2.6.0_test6: CONFIG_I8K produces wrong/no keycodes for special buttons

There are 4 special buttons on dell-laptops which you could only get to work using CONFIG_I8K. This worked well in any 2.4-kernel, by pressing these buttons the keycodes 129. 130, 131, 132 get produced. In 2.6.0-test6_mm2 it produces <nothing>, 162, <nothing>, 110. I've digged into the code without any succes for now. Any hints?

Thx,
Jan

PS: Beside that i've also problems to get some of my pcmcia-cards runnig (ISDN and WLAN). May someone point me to any URL getting more information concerning the new ISDN-TTY-Interface in kernel-2.6?

I'm assuming you're talking about the Inspiron line of laptops? The Latitude series doesn't have said 4 buttons (or at least on my Latitude C840, there are no such buttons)

I'm using a Dell Inspiron i8200.

Jan

This is not entirely correct, you don't need the driver for all buttons.

The inspiron 8000 has 4 multimedia buttons, 2 volume buttons and 3 Fn-key combinations. Other Dell laptops have only one or two buttons.

The multimedia buttons generate the following raw scancodes which can be dumped with showkey -s:

    0xe0 0x01	play
    0xe0 0x02	stop
    0xe0 0x03	back
    0xe0 0x04	forward

Since the raw scancodes are generate by the keyboard like any other key they should be handled by the 2.6.0 kernel as in 2.4.x. If this doesn't work it is a bug in the kernel. Did you try showkey -s with 2.6.0?

Under X-window these 4 keys generate the following keycodes which can be mapped to any keysym with xmodmap:

    129  	play
    130  	stop
    131  	back
    132  	forward

These are defined in /etc/X11/xkb/keycodes/xfree86 as <I01>, <I02>, etc.:

    <XFER> =   129;		// Henkan
    <NFER> =   131;		// Muhenkan
    alias <XFER> = <I01>;
    <I02>  =   130;
    alias <NFER> = <I03>;
    <I04>  =   132;

but it is not clear to me where the raw keyboard scancodes are mapped to the xfree86 keys <I01>, <I02>, etc.

For some obscure reason known only to Dell the volume buttons and the Fn- keys are trapped by the SMM BIOS and can be read only by the i8k driver which under kernel 2.4.x can be programmed to generate the original raw scancodes generated by the keyboard:

    0xe0 0x20	fn+vol_mute
    0xe0 0x2e	vol_up, fn+vol_down
    0xe0 0x30	vol_up, Fn+vol_up

(SMM BIOS can be programmed to handle volume buttons as normal keys by disabling the Fn- key but then you don't have the Fn- function, including bios access and suspend)

Unfortunately the keyboard interface has changed in 2.6.0 and it is not possible to generate the 0xe0, 0x0N sequence as in 2.4.x, so this feature has been disabled and you must use i8kbuttons instead. If anybody knows how to generate the corresponding scancodes in kernel 2.6.0 please let me know.

echo 16i[q]sa[ln0=aln56%1F+Pln56/snlbx]sb23C15C85417484EC5E429FD9776Asnlbx|dc;\
echo 16i[APq]sa[ln0=aln5C%1F+Pln5C/snlbx]sb72E28557F7FE184112F53F5FFDsnlbx|dc

This is what i get:
play - <nothing>
Stop -
0xe0 0x22
0xe0 0xa2
back - <nothing>
forward-
0x6a
0xea

These keys seems to work, but don't produce any keycodes. The same happens when pressing the (special) Volume-keys.

Suspend and Bios-Setup will work (when accessing the Bios-Setup there is no way to come back to my system - this worked some time ago).

Is i8kbuttons usable for the play, stop, back and forward-button? This would be new to me, AFAIK you can only map the volume-keys.

toral distfiles # i8kbuttons --help
Usage: i8kbuttons [<option>...]

Options:

       -v|--verbose
       -u|--up <command>
       -d|--down <command>
       -m|--mute <command>
       -r|--repeat <milliseconds>
       -t|--timeout <milliseconds>

Thx, Jan

For the keys that show nothing, if you look at /var/log/messages, I think you'll see something like:

Oct  6 13:39:24 keller kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x176, data 0x1, on isa0060/serio0).
Oct  6 13:39:24 keller kernel: atkbd.c: Unknown key released (translated set 2, code 0x176, data 0x81, on isa0060/serio0).

Oct  6 13:39:29 keller kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x11e, data 0x3, on isa0060/serio0).
Oct  6 13:39:29 keller kernel: atkbd.c: Unknown key released (translated set 2, code 0x11e, data 0x83, on isa0060/serio0).

-g (who's been too lazy to attempt the atkbd.c patchery needed to fix this)

Indeed, this is exactly what i get :-).

So, i assume you will fix this?

Thx,
Jan

Wrong. I know basically nothing about the input/keyboard code. But...

Andries Brouwer posted, in another thread, that one should be able to take the code from the message, and edit the table atkbd_set2_keycode...

Were it that simple (my patch is attached). For the two buttons that yielded the error message, I changed the 0 to the keycode that 2.4 used to provide...

So this makes the messages go away, that's only half the battle. If you run with this patch, you'll notice that the Prev button generates the same X keycode as the End key (which is busted).

I have no earthly idea how the keycodes in atkdb.c map to X keycodes. Maybe somebody can explain it in a simple way...

-g

===== /ws/georgn/bk/keller-kernels/keller-2.6/drivers/input/keyboard/atkbd.c 1.37 vs edited =====

@@ -65,13 +65,13 @@
 	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
 	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,255,
 	  0,  0, 92, 90, 85,  0,137,  0,  0,  0,  0, 91, 89,144,115,  0,
-	217,100,255,  0, 97,165,164,  0,156,  0,  0,140,115,  0,  0,125,
+	217,100,255,  0, 97,165,164,  0,156,  0,  0,140,115,  0,  131,125,
 	173,114,  0,113,152,163,151,126,128,166,  0,140,  0,147,  0,127,
 	159,167,115,160,164,  0,  0,116,158,  0,150,166,  0,  0,  0,142,
 	157,  0,114,166,168,  0,  0,213,155,  0, 98,113,  0,163,  0,138,
 	226,  0,  0,  0,  0,  0,153,140,  0,255, 96,  0,  0,  0,143,  0,
 	133,  0,116,  0,143,  0,174,133,  0,107,  0,105,102,  0,  0,112,
-	110,111,108,112,106,103,  0,119,  0,118,109,  0, 99,104,119
+	110,111,108,112,106,103,  129,119,  0,118,109,  0, 99,104,119
 };
 
 static unsigned char atkbd_set3_keycode[512] = {