Hi,
this patch add support for four functions key on DELL Latitude X200.
--- pc_keyb.c.orig 2002-12-07 18:03:00.000000000 +0100
+++ pc_keyb.c 2002-12-07 18:37:04.000000000 +0100
@@ -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)
In article <[email protected]> you wrote:
> this patch add support for four functions key on DELL Latitude X200.
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
>
> In article <[email protected]> you wrote:
> > this patch add support for four functions key on DELL Latitude X200.
>
> 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?
>
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!
> > In article <[email protected]> you wrote:
> > > this patch add support for four functions key on DELL Latitude X200.
> >
> > 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?
> >
>
> 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
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?
On Tue, Dec 10, 2002 at 10:34:44PM +0100, Pavel Machek wrote:
> > 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
>
> Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> prefix, too. I think there are really *weird* keyboards out there.
>
> Pavel
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.
On Tue, Dec 10, 2002 at 10:34:44PM +0100, Pavel Machek wrote:
> > > In article <[email protected]> you wrote:
> > > > this patch add support for four functions key on DELL Latitude X200.
> > >
> > > 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?
> >
> > 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
>
> Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> prefix, too.
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 ...
> I think there are really *weird* keyboards out there.
There are, but fortunately not that much weird.
--
Vojtech Pavlik
SuSE Labs
>>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
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
On Thu, Dec 12, 2002 at 06:48:04AM -0500, James H. Cloos Jr. wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
>
> 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?
Do they by any chance produce a kernel warning when pressed?
--
Vojtech Pavlik
SuSE Labs
On Thu, Dec 12, 2002 at 07:17:22AM -0500, James H. Cloos Jr. wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
>
> 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.
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.
> Incidently, the FORWARD key is giving the same keycode as the main
> kb's Pause key.
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
>>>>> "Vojtech" == Vojtech Pavlik <[email protected]> writes:
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
Pavel Machek wrote:
>
> Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> prefix, too. I think there are really *weird* keyboards out there.
>
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]>:
> Pavel Machek wrote:
> >
> > Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> > prefix, too. I think there are really *weird* keyboards out there.
> >
>
> True enough, although very few things are going to recognize them at all.
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/