PATCH: Four function buttons on DELL Latitude X200

Hi,

this patch add support for four functions key on DELL Latitude X200.

@@ -214,6 +214,23 @@
 #define E0_DO      116
 #define E0_F17     117
 #define E0_KPMINPLUS 118
+
+/*
+ * DELL Latitude X200
+ *
+ * The keyboard of DELL Latitude has one special key - `i' button and
+ * three Function keys: End, Page Up and Page Down.
+ *
+ */
+
+/* The `i' button in the top-right corner */
+#define E0_I      120
+
+/* Function key + {End, Page Up, Page Down} */
+#define E0_FN_END    121
+#define E0_FN_PGUP   122
+#define E0_FN_PGDOWN 123
+
 /*
  * My OmniKey generates e0 4c for  the "OMNI" key and the
  * right alt key does nada. [[email protected]]

@@ -230,13 +247,13 @@
 #define E0_MSTM	127
 
 static unsigned char e0_keys[128] = {
-  0, 0, 0, 0, 0, 0, 0, 0,			      /* 0x00-0x07 */
+  0, E0_I, 0, 0, 0, 0, 0, 0,			      /* 0x00-0x07 */
   0, 0, 0, 0, 0, 0, 0, 0,			      /* 0x08-0x0f */
   0, 0, 0, 0, 0, 0, 0, 0,			      /* 0x10-0x17 */
   0, 0, 0, 0, E0_KPENTER, E0_RCTRL, 0, 0,	      /* 0x18-0x1f */
-  0, 0, 0, 0, 0, 0, 0, 0,			      /* 0x20-0x27 */
-  0, 0, 0, 0, 0, 0, 0, 0,			      /* 0x28-0x2f */
-  0, 0, 0, 0, 0, E0_KPSLASH, 0, E0_PRSCR,	      /* 0x30-0x37 */
+  E0_FN_END, 0, 0, 0, 0, 0, 0, 0,			      /* 0x20-0x27 */
+  0, 0, 0, 0, 0, 0, E0_FN_PGDOWN, 0,			      /* 0x28-0x2f */
+  E0_FN_PGUP, 0, 0, 0, 0, E0_KPSLASH, 0, E0_PRSCR,	      /* 0x30-0x37 */
   E0_RALT, 0, 0, 0, 0, E0_F13, E0_F14, E0_HELP,	      /* 0x38-0x3f */
   E0_DO, E0_F17, 0, 0, 0, 0, E0_BREAK, E0_HOME,	      /* 0x40-0x47 */
   E0_UP, E0_PGUP, 0, E0_LEFT, E0_OK, E0_RIGHT, E0_KPMINPLUS, E0_END,/* 0x48-0x4f */

If you want to use it, loadkeys something like this:

#
# This is the supplemental keymap for DELL Latitude X200 keyboard. #

# (c) 2002, Pavel Janík <[email protected]>

#
# Dell Latitude X200 has four additional keys with the following scancodes:
#
# - e0 01: `i' button in the top-right corner
# - e0 20: Fn + End
# - e0 30: Fn + Page Up
# - e0 2e: Fn + Page Down
#

keycode 120 = F120
keycode 121 = F121
keycode 122 = F122
keycode 123 = F123

string F120 = "#Dell `i' button pressed - please edit dell_latitude_X200.map\n" string F121 = "#Dell Fn+End pressed - please edit dell_latitude_X200.map\n" string F122 = "#Dell Fn+Page Up pressed - please edit dell_latitude_X200.map\n" string F123 = "#Dell Fn+Page Down pressed - please edit dell_latitude_X200.map\n"

Pavel Janík

Document your data layouts.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

we need a more generic appoach to handle those key codes for various extensions. I think a pure software reconfiguration of the keymaps or a daemon trakcing the raw codes is fine. Perhaps we can make something like a hook into the kernel where all untrapped function keys are send to in raw format?

Greetings
Bernd

eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Followup to:  <[email protected]>
By author:    Bernd Eckenfels <[email protected]>
In newsgroup: linux.dev.kernel

The PC only has so many possible keycodes (with E0 and E1 it's still in the sub-300 range.) It won't fit within 128, but I would really like an algorithmic mapping from scancodes to keycodes so we don't continue to have this problem.

For example, using a 16-bit keycode model:

	Scancode		Keycode (binary)
	mxxxxxxx	 	m0000000 0xxxxxxx
	E0 mxxxxxxx		m0000000 1xxxxxxx
	E1 mxxxxxxx yyyyyyyy	mxxxxxxx yyyyyyyy

m = make/break bit

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

Hi!

Well, nothing prevents keyboard manufacturers from using 0xe2 as a prefix, too. I think there are really *weird* keyboards out there.

Pavel

Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Indeed. See, for example,

	http://www.win.tue.nl/~aeb/linux/kbd/scancodes-2.html#ss2.18

for a keyboard that uses 0x80 as a prefix.

Except that it would pretty much confuse any existing OS. The only key prefix is E0, because E1 is only used for a single key, and that's fake right shift, which should be discarded anyway even before a keycode is generated.

Anyway, we definitely don't want scancode dependent keycodes. Keycodes should be the same for all types of keyboards (Be it PS/2, USB, or ADB), so that you can have a single set of N keymaps (us, gb, french, czech, whatever), and not N*M keymaps for different languages and keyboard types.

This simplifies things both in the kernel (a bit), and userspace (a lot).

Now, speaking about a fixed scancode->something mapping, atkbd.c in 2.5 uses this encoding:

	   xxxxxxxx -> 0 xxxxxxxx	
	E0 xxxxxxxx -> 1 xxxxxxxx

Note that no make/break bit is used, as the keyboard is operated in "Set 2" of scancodes, where release is signalled by the F0 prefix, and not by the highest bit. And since the keycode is passed on as an input event, we don't need to encode make/break into the keycode on the output either.

The real question is, when we have these 16-bit (or more bit) keycodes, how do we export them to the userspace? In cooked mode, there is no problem, we can extend the keymaps. But both medium raw and raw modes are pretty much limited in the number of keys they can carry. See 2.5 keyboard.c for the current imperfect solution.

IMHO applications which now use raw mode should instead switch to using the event devices in /dev/input ...

There are, but fortunately not that much weird.

Vojtech Pavlik
SuSE Labs

Vojtech> The real question is, when we have these 16-bit (or more bit) Vojtech> keycodes, how do we export them to the userspace? In cooked Vojtech> mode, there is no problem, we can extend the keymaps. But Vojtech> both medium raw and raw modes are pretty much limited in the Vojtech> number of keys they can carry. See 2.5 keyboard.c for the Vojtech> current imperfect solution.

Vojtech> IMHO applications which now use raw mode should instead Vojtech> switch to using the event devices in /dev/input ...

In reference to this, until X is updated to do so, I'm curious about the changes in the multi-media keys on this i8100 between 2.4 and 2.5.

In 2.4, X sees these as the keycodes (in Xmodmap syntax):

! the four keys at the top
keycode 129 = XF86AudioPlay XF86AudioPause
keycode 130 = XF86AudioStop
keycode 131 = XF86AudioPrev
keycode 132 = XF86AudioNext

! the volume and mute keys;
! order is unknown because in 2.4 the smm system
! catches the keys before X or the kernel can.
keycode 137 = F27
keycode 138 = F28
keycode 139 = F29

! this happens when three keys are hit together ! it was causing my wm to open its menu, so I ! added the below line to force 135 to be ignored. keycode 135 = XF86Launch0

In 2.5, those (as warned) change radically:

! the four keys at the top
keycode NONE = XF86AudioPlay XF86AudioPause
keycode 162 = XF86AudioStop
keycode NONE = XF86AudioPrev
keycode 114 = XF86AudioNext
! the volume and mute keys;
keycode 160 = XF86AudioMute
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume

It is cool that the volume keys become accessible, and no longer need to be run through the i8k kernel module. But the loss of the play and prev buttons is curious. Is there a way around that?

-JimC

Do they by any chance produce a kernel warning when pressed?

Vojtech Pavlik
SuSE Labs

Vojtech> Do they by any chance produce a kernel warning when pressed?

Yes, the two keys that do not generate an event in X syslog these errors:

atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) pressed. atkbd.c: Unknown key (set 2, scancode 0x176, on isa0060/serio0) released. atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) pressed. atkbd.c: Unknown key (set 2, scancode 0x11e, on isa0060/serio0) released.

where 0x176 is the PLAY key and 0x11e is the PREV key.

Incidently, the FORWARD key is giving the same keycode as the main kb's Pause key.

-JimC

You can edit atkbd.c, and at the beginning there is a big table, add some reasonable keycodes (KEY_PLAY, KEY_PREV), to entries 0x11e and 0x176 in the table.

Should be possible to fix at the same place.

(You can try to use 'setkeycode' for the same purpose in 2.5, but it might and might not work.)

Vojtech Pavlik
SuSE Labs

True enough, although very few things are going to recognize them at all.

-hpa

On Wed, 2002-12-11 14:41:20 -0800, H. Peter Anvin <[email protected]> wrote in message <[email protected]>:

A co-worker of me once developed some patch to handle some weired Point of Sale keyboards (with magnetic stripe reader and some lock and so on). He did it by allowing additional modules to parse everything what is coming from keyboard controller (through additionally hooked modules) before sending "normal" keycaps events to userspace. An application willing to get the extra data could fetch that from some /dev/ice node. This could be generalized to send input API events. I'll CC him to allow him to speak up.

MfG, JBG

   Jan-Benedict Glaw       [email protected]    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/