[patch commit request] kdrive xserver: support for key codes 128-255

[patch commit request] kdrive xserver: support for key codes 128-255

[Stanislav Brabec]

Hallo.

Would be anybody with commit privileges to OE mtn so kind and review and
commit attached fixes regarding keycodes 128-255 in kdrive xserver.

It is required for input devices generating these key codes (e. g. Sharp
CE-RH2 on Zaurus Spitz/Akita).

This patch works perfectly for me for more than half year.

Patch is not device specific and should work for all input devices. It
was reviewed by the Linux Extended MEDIUMRAW mode author.

Attached mtn patch fixes
http://bugs.openembedded.org/show_bug.cgi?id=2637
[Bug 2637] fixes to make Sharp CE-RH2 remote working in X

This bug remains for more than half year without any response.

This bug is also pending in upstream as
http://bugs.freedesktop.org/show_bug.cgi?id=11545
[Bug 11545] patch to support Linux Extended MEDIUMRAW keyboard mode


#
# old_revision [54d430eac081b6372e156d9c6d7b9a44d9c9422f]
#
# add_file "packages/xorg-xserver/xserver-kdrive-1.3.0.0/linux-keyboard-mediumraw.patch"
#  content [e5ade42dad2df4fd8a283ea21343e22ea1b5b5d6]
# 
# add_file "packages/xorg-xserver/xserver-kdrive-1.4/linux-keyboard-mediumraw.patch"
#  content [faca4d8feba0272517c84f11ac61a39c0b055556]
# 
# patch "packages/xorg-xserver/xserver-kdrive_1.3.0.0.bb"
#  from [c8df66fc28ad69123340b7acdf08b827bc631c09]
#    to [41e45777f92b716da705a52140e3ce499b8f2d36]
# 
# patch "packages/xorg-xserver/xserver-kdrive_1.4.bb"
#  from [fc1b8a97acf55bb4abc9d1d2ad120b71d1d4f15a]
#    to [a78356c698a321739be60a164cee8f7a77c158fa]
#
============================================================
--- packages/xorg-xserver/xserver-kdrive-1.3.0.0/linux-keyboard-mediumraw.patch	e5ade42dad2df4fd8a283ea21343e22ea1b5b5d6
+++ packages/xorg-xserver/xserver-kdrive-1.3.0.0/linux-keyboard-mediumraw.patch	e5ade42dad2df4fd8a283ea21343e22ea1b5b5d6
@@ -0,0 +1,83 @@
+Index: xorg-server-1.3.0.0/hw/kdrive/linux/keyboard.c
+===================================================================
+--- xorg-server-1.3.0.0.orig/hw/kdrive/linux/keyboard.c	2006-11-16 18:01:23.000000000 +0000
++++ xorg-server-1.3.0.0/hw/kdrive/linux/keyboard.c	2007-08-12 12:14:29.000000000 +0000
+@@ -384,14 +384,35 @@
+ LinuxKeyboardRead (int fd, void *closure)
+ {
+     unsigned char   buf[256], *b;
+-    int		    n;
++    int		    n, mediumraw_data, mediumraw_event;
++    static enum { LOWKEY, BYTE1, BYTE2 } mediumraw_state = LOWKEY;
+ 
+     while ((n = read (fd, buf, sizeof (buf))) > 0)
+     {
+ 	b = buf;
+ 	while (n--)
+ 	{
+-	    KdEnqueueKeyboardEvent (b[0] & 0x7f, b[0] & 0x80);
++	    switch (mediumraw_state)
++	    {
++	    case LOWKEY:
++		if ( (b[0] & 0x7f) == 0)
++		{
++		    mediumraw_state = BYTE1;
++		    mediumraw_event = b[0] & 0x80;
++		}
++		else
++		    KdEnqueueKeyboardEvent (b[0] & 0x7f, b[0] & 0x80);
++		break;
++	    case BYTE1:
++		mediumraw_data = (b[0] & 0x7f) << 7;
++		mediumraw_state = BYTE2;
++		break;
++	    case BYTE2:
++		/* FIXME: KdEnqueueKeyboardEvent should accept word size */
++		KdEnqueueKeyboardEvent ( mediumraw_data | (b[0] & 0x7f), mediumraw_event);
++		mediumraw_state = LOWKEY;
++		break;
++	    }
+ 	    b++;
+ 	}
+     }
+Index: xorg-server-1.3.0.0/hw/xfree86/os-support/linux/lnx_kbd.c
+===================================================================
+--- xorg-server-1.3.0.0.orig/hw/xfree86/os-support/linux/lnx_kbd.c	2006-11-16 18:01:25.000000000 +0000
++++ xorg-server-1.3.0.0/hw/xfree86/os-support/linux/lnx_kbd.c	2007-08-12 12:14:29.000000000 +0000
+@@ -430,12 +430,32 @@
+ {
+     KbdDevPtr pKbd = (KbdDevPtr) pInfo->private;
+     unsigned char rBuf[64];
+-    int nBytes, i;
++    int nBytes, i, mediumraw_data, mediumraw_event;
++    static enum { LOWKEY, BYTE1, BYTE2 } mediumraw_state = LOWKEY;
+     if ((nBytes = read( pInfo->fd, (char *)rBuf, sizeof(rBuf))) > 0) {
+-       for (i = 0; i < nBytes; i++)
+-           pKbd->PostEvent(pInfo, rBuf[i] & 0x7f,
+-                           rBuf[i] & 0x80 ? FALSE : TRUE);
++       for (i = 0; i < nBytes; i++) {
++           switch (mediumraw_state) {
++           case LOWKEY:
++               if ( (rBuf[i] & 0x7f) == 0) {
++                   mediumraw_state = BYTE1;
++                   mediumraw_event = rBuf[i] & 0x80;
++               }
++               else
++                   pKbd->PostEvent(pInfo, rBuf[i] & 0x7f,
++                                   rBuf[i] & 0x80 ? FALSE : TRUE);
++               break;
++           case BYTE1:
++               mediumraw_data = (rBuf[i] & 0x7f) << 7;
++               mediumraw_state = BYTE2;
++               break;
++           case BYTE2:
++               pKbd->PostEvent(pInfo, mediumraw_data | (rBuf[i] & 0x7f),
++                               mediumraw_event ? FALSE : TRUE);
++               mediumraw_state = LOWKEY;
++               break;
++           }
+        }
++    }
+ }
+ 
+ static Bool
============================================================
--- packages/xorg-xserver/xserver-kdrive-1.4/linux-keyboard-mediumraw.patch	faca4d8feba0272517c84f11ac61a39c0b055556
+++ packages/xorg-xserver/xserver-kdrive-1.4/linux-keyboard-mediumraw.patch	faca4d8feba0272517c84f11ac61a39c0b055556
@@ -0,0 +1,44 @@
+Index: git/hw/kdrive/linux/keyboard.c
+===================================================================
+--- git.orig/hw/kdrive/linux/keyboard.c	2007-11-14 21:30:45.000000000 +0000
++++ git/hw/kdrive/linux/keyboard.c	2007-11-15 12:00:11.000000000 +0000
+@@ -42,6 +42,8 @@
+ #include <sys/ioctl.h>
+ 
+ extern int LinuxConsoleFd;
++static unsigned char mediumraw_data, mediumraw_up;
++static enum { DEFAULT, EXTBYTE1, EXTBYTE2 } mediumraw_state = DEFAULT;
+ 
+ static const KeySym linux_to_x[256] = {
+ 	NoSymbol,	NoSymbol,	NoSymbol,	NoSymbol,
+@@ -701,7 +703,29 @@
+             else
+ #endif
+                 scancode = b[0] & 0x7f;
+-	    KdEnqueueKeyboardEvent (closure, scancode, b[0] & 0x80);
++	    /* This is extended medium raw mode interpreter
++	       see linux/drivers/keyboard.c (kbd->kbdmode == VC_MEDIUMRAW) */
++	    switch (mediumraw_state)
++	    {
++	    case DEFAULT:
++		if (scancode == 0)
++		{
++		    mediumraw_state = EXTBYTE1;
++		    mediumraw_up = b[0] & 0x80;
++		}
++		else
++		    KdEnqueueKeyboardEvent (closure, scancode, b[0] & 0x80);
++		break;
++	    case EXTBYTE1:
++		mediumraw_data = scancode;
++		mediumraw_state = EXTBYTE2;
++		break;
++	    case EXTBYTE2:
++		/* Note: Only codes < 256 will pass correctly through KdEnqueueKeyboardEvent() */
++	      KdEnqueueKeyboardEvent (closure, (int)mediumraw_data << 7 | scancode, mediumraw_up);
++		mediumraw_state = DEFAULT;
++		break;
++	    }
+ 	    b++;
+ 	}
+     }
============================================================
--- packages/xorg-xserver/xserver-kdrive_1.3.0.0.bb	c8df66fc28ad69123340b7acdf08b827bc631c09
+++ packages/xorg-xserver/xserver-kdrive_1.3.0.0.bb	41e45777f92b716da705a52140e3ce499b8f2d36
@@ -20,6 +20,7 @@ SRC_URI = "${XORG_MIRROR}/individual/xse
 	file://w100-autofoo.patch;patch=1 \
 	file://w100-fix-offscreen-bmp.patch;patch=1 \
         file://kdrive-1.3-18bpp.patch;patch=1 \
+        file://linux-keyboard-mediumraw.patch;patch=1 \
         file://gumstix-kmode.patch;patch=1 \
         file://smedia-glamo.patch;patch=1 \
         file://build-glamo.patch;patch=1 \
============================================================
--- packages/xorg-xserver/xserver-kdrive_1.4.bb	fc1b8a97acf55bb4abc9d1d2ad120b71d1d4f15a
+++ packages/xorg-xserver/xserver-kdrive_1.4.bb	a78356c698a321739be60a164cee8f7a77c158fa
@@ -16,6 +16,7 @@ SRC_URI = "${XORG_MIRROR}/individual/xse
 	file://w100-autofoo.patch;patch=1 \
 	file://w100-fix-offscreen-bmp.patch;patch=1 \
 	file://w100-new-input-world-order.patch;patch=1 \
+	file://linux-keyboard-mediumraw.patch;patch=1 \
 	file://xcalibrate-new-input-world-order.patch;patch=1 \
 	file://tslib-default-device.patch;patch=1 \
 	file://fbdev-evdev.patch;patch=1 \

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Junqian Gordon Xu]

On 01/28/2008 12:19 PM, Stanislav Brabec wrote:
> Would be anybody with commit privileges to OE mtn so kind and review and
> commit attached fixes regarding keycodes 128-255 in kdrive xserver.

If nobody's responding, I will committ this tomorrow, although I'm not 
good at kernel stuff (let alone reviewing).

Regards
Gordon

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Paul Sokolovsky]

Hello,

On Mon, 28 Jan 2008 19:19:04 +0100
Stanislav Brabec <utx@penguin.cz> wrote:

> Hallo.
> 
> Would be anybody with commit privileges to OE mtn so kind and review
> and commit attached fixes regarding keycodes 128-255 in kdrive
> xserver.
> 
> It is required for input devices generating these key codes (e. g.
> Sharp CE-RH2 on Zaurus Spitz/Akita).
> 
> This patch works perfectly for me for more than half year.
> 
> Patch is not device specific and should work for all input devices. It
> was reviewed by the Linux Extended MEDIUMRAW mode author.
> 
> Attached mtn patch fixes
> http://bugs.openembedded.org/show_bug.cgi?id=2637
> [Bug 2637] fixes to make Sharp CE-RH2 remote working in X
> 
> This bug remains for more than half year without any response.
> 
> This bug is also pending in upstream as
> http://bugs.freedesktop.org/show_bug.cgi?id=11545
> [Bug 11545] patch to support Linux Extended MEDIUMRAW keyboard mode

Can you please elaborate what the application of this patch would mean
for OE (besides fixing support for one specific obscure peripheral)? 

Based on this comment: "Note: Extended MEDIUMRAW mode and evdev mode
should provide the same keycodes" in
http://bugs.freedesktop.org/show_bug.cgi?id=11545 , I would think that
it would bring us interface-stable workaround until X.org and we fully
convert to evdev? Is that how you perceive it? Should we declare the
problem of 8-bit keycodes solved right now, and stop recommending
kernel developers to fit their keys into 7 bits? Is this patch suitable
for merging to stable branch?


Thanks,
Paul

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Stanislav Brabec]

Paul Sokolovsky wrote:
> On Mon, 28 Jan 2008 19:19:04 +0100
> Stanislav Brabec <utx@penguin.cz> wrote:

> Can you please elaborate what the application of this patch would mean
> for OE (besides fixing support for one specific obscure peripheral)? 

Support of key codes 128-255 from the /usr/include/linux/input.h in
kdrive.

> Based on this comment: "Note: Extended MEDIUMRAW mode and evdev mode
> should provide the same keycodes" in
> http://bugs.freedesktop.org/show_bug.cgi?id=11545 , I would think that
> it would bring us interface-stable workaround until X.org and we fully
> convert to evdev?

Yes. Extended MEDIUMRAW mode and evdev are using different interfaces,
but they are intended to return the same key codes.

My patch extends keycode support from 0-127 to 0-255.

> Is that how you perceive it? Should we declare the
> problem of 8-bit keycodes solved right now, and stop recommending
> kernel developers to fit their keys into 7 bits? Is this patch
> suitable
> for merging to stable branch?

Short description:

Yes. Current kernel already sends Extended MEDIUMRAW codes for
keys > 127, but xserver is not able to interpret them.


Long description:

Here is a description what X does:

xserver-kdrive:
- If XKB is disabled, MEDIUMRAW mode is used.
- If XKB is enabled, AT keyboard scancode interface is used.

xorg-xserver:
- AT keyboard scancode interface is used by default.
- If you have PPC linux with a very very old kernel with
  MAC_ADBKEYCODES support, MEDIUMRAW mode is used.
- evdev driver exists, but its configuration files are not yet working
  properly.


Here is a description what kernel can do:

1. Native RAW mode (AT keyboards only, default in kernel 2.4, can be
   turned on in 2.6 by softraw=0 kernel arg to atkbd).
   X gets exact AT scancodes what from the keyboard.
2. SOFTRAW mode (default in kernel 2.6). Kernel interprets the scancodes
   from keyboard or similar codes from other input devices. Then it
   emulates scancodes of Microsoft Multimedia AT keyboard and sends them
   to the user space.
3. MEDIUMRAW mode (obsolete). Kernel interprets keys presses and sends
   keycodes to the user space using the old-style scancode interface.
   Only key codes < 128 can be transferred.
4. Extended MEDIUMRAW mode (switched in kernel using ioctl()). Kernel
   interprets keys presses and sends keycodes to the user space using
   the old-style scancode interface with a special encapsulation
   (see drivers/char/keyboard.c kernel source, lines 1204-1222).
   Only key codes < 16384 can be transferred.
5. Evdev interface. Kernel interprets keys presses and sends keycodes
   to the user space using the evdev interface.

As you can see 1 and 2 are intended to provide the same results (but
they often don't) and 4 and 5 are intended to provide the same results.


Note that there is a major limitation of X11 protocol to 256 keycodes.
http://bugs.freedesktop.org/show_bug.cgi?id=11227
It will be targetted in X12 development, but we should not expect it
soon. X11 is there for about 20 years and it would be hard to change it.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Junqian Gordon Xu]

On 01/30/2008 06:13 AM, Stanislav Brabec wrote:
>> Paul Sokolovsky wrote:
>> Can you please elaborate what the application of this patch would mean
>> for OE (besides fixing support for one specific obscure peripheral)? 

I guess I probably would be yelled at for not raising this before 
committing your patch.

Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In other 
words, are there any other devices benifiting from the extended keycode. 
  I vaguely remember Dmitry asked about extended keycode for tosa, but 
I'm not sure he's talking about the same thing.

Regards
Gordon

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Stanislav Brabec]

Junqian Gordon Xu wrote:
> On 01/30/2008 06:13 AM, Stanislav Brabec wrote:
> >> Paul Sokolovsky wrote:
> >> Can you please elaborate what the application of this patch would mean
> >> for OE (besides fixing support for one specific obscure peripheral)? 
> 
> I guess I probably would be yelled at for not raising this before 
> committing your patch.
> 
> Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In other 
> words, are there any other devices benifiting from the extended keycode. 
>   I vaguely remember Dmitry asked about extended keycode for tosa, but 
> I'm not sure he's talking about the same thing.

No. It adds support for key codes 128-255 in general.

Let he test to assign these key codes in the kernel driver. He should
see them non-mangled in X.

Note that is cannot provide codes above 255 - it is a major limitation
of X11 protocol.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Dmitry Baryshkov]

Hi,

Stanislav Brabec wrote:

> Junqian Gordon Xu wrote:
>> On 01/30/2008 06:13 AM, Stanislav Brabec wrote:
>> >> Paul Sokolovsky wrote:
>> >> Can you please elaborate what the application of this patch would
>> >> mean for OE (besides fixing support for one specific obscure
>> >> peripheral)?
>> 
>> I guess I probably would be yelled at for not raising this before
>> committing your patch.
>> 
>> Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In other
>> words, are there any other devices benifiting from the extended
>> keycode.
>>   I vaguely remember Dmitry asked about extended keycode for tosa, but
>> I'm not sure he's talking about the same thing.
> 
> No. It adds support for key codes 128-255 in general.
> 
> Let he test to assign these key codes in the kernel driver. He should
> see them non-mangled in X.

Thanks. I'll test. Should I use -keybd keyboard or -keybd evdev... ?

> 
> Note that is cannot provide codes above 255 - it is a major limitation
> of X11 protocol.

Hmmm. According to the <linux/input.h> there are a plenty of keys with 
keycodes 0x160 -- 0x1ff. They can't be handled by the X11?

-- 
With best wishes
Dmitry

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Stanislav Brabec]

Dmitry Baryshkov wrote:
> >> 
> >> I guess I probably would be yelled at for not raising this before
> >> committing your patch.
> >> 
> >> Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In other
> >> words, are there any other devices benifiting from the extended
> >> keycode.
> >>   I vaguely remember Dmitry asked about extended keycode for tosa, but
> >> I'm not sure he's talking about the same thing.
> > 
> > No. It adds support for key codes 128-255 in general.
> > 
> > Let he test to assign these key codes in the kernel driver. He should
> > see them non-mangled in X.
> 
> Thanks. I'll test. Should I use -keybd keyboard or -keybd evdev... ?

Patch affects only the old keyboard driver, not evdev.

See details in the bottom of this mail.

> > Note that is cannot provide codes above 255 - it is a major limitation
> > of X11 protocol.
> 
> Hmmm. According to the <linux/input.h> there are a plenty of keys with 
> keycodes 0x160 -- 0x1ff. They can't be handled by the X11?

No, they can't. http://bugs.freedesktop.org/show_bug.cgi?id=11227

Somebody could design a work-around, but real solution can come with X12
protocol change.

-

Long description:

Here is a description what X does:

xserver-kdrive:
- If XKB is disabled, MEDIUMRAW mode is used.
- If XKB is enabled, AT keyboard scancode interface is used.

xorg-xserver:
- AT keyboard scancode interface is used by default.
- If you have PPC linux with a very very old kernel with
  MAC_ADBKEYCODES support, MEDIUMRAW mode is used.
- evdev driver exists, but its configuration files are not yet working
  properly.


Here is a description what kernel can do:

1. Native RAW mode (AT keyboards only, default in kernel 2.4, can be
   turned on in 2.6 by softraw=0 kernel arg to atkbd).
   X gets exact AT scancodes what from the keyboard.
2. SOFTRAW mode (default in kernel 2.6). Kernel interprets the scancodes
   from keyboard or similar codes from other input devices. Then it
   emulates scancodes of Microsoft Multimedia AT keyboard and sends them
   to the user space.
3. MEDIUMRAW mode (obsolete). Kernel interprets keys presses and sends
   keycodes to the user space using the old-style scancode interface.
   Only key codes < 128 can be transferred.
4. Extended MEDIUMRAW mode (switched in kernel using ioctl()). Kernel
   interprets keys presses and sends keycodes to the user space using
   the old-style scancode interface with a special encapsulation
   (see drivers/char/keyboard.c kernel source, lines 1204-1222).
   Only key codes < 16384 can be transferred.
   This is implemented by my patch:
   http://bugs.freedesktop.org/show_bug.cgi?id=11545
5. Evdev interface. Kernel interprets keys presses and sends keycodes
   to the user space using the evdev interface.

As you can see 1 and 2 are intended to provide the same results (but
they often don't) and 4 and 5 are intended to provide the same results.


Note that there is a major limitation of X11 protocol to 256 keycodes.
http://bugs.freedesktop.org/show_bug.cgi?id=11227
It will be targetted in X12 development, but we should not expect it
soon. X11 is there for about 20 years and it would be hard to change it

-- 
Stanislav Brabec
http://www.penguin.cz/~utx, ICQ 116020046

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Junqian Gordon Xu]

On 02/03/2008 03:57 PM, Stanislav Brabec wrote:
> Junqian Gordon Xu wrote:
>> On 01/30/2008 06:13 AM, Stanislav Brabec wrote:
>>>> Paul Sokolovsky wrote:
>>>> Can you please elaborate what the application of this patch would mean
>>>> for OE (besides fixing support for one specific obscure peripheral)? 
>> I guess I probably would be yelled at for not raising this before 
>> committing your patch.
>>
>> Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In other 
>> words, are there any other devices benifiting from the extended keycode. 
>>   I vaguely remember Dmitry asked about extended keycode for tosa, but 
>> I'm not sure he's talking about the same thing.
> 
> No. It adds support for key codes 128-255 in general.

I understand this patch is general. But could you educate me that except 
for the Z clamshells, what's the use case for other devices? I guess my 
question is more in line with Paul's challenge. Is this patch just a 
why-not for other devices or something might be helpful?

Regards
Gordon

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Paul Sokolovsky]

Hello,

On Sat, 09 Feb 2008 07:00:34 -0600
Junqian Gordon Xu <xjqian@gmail.com> wrote:

> On 02/03/2008 03:57 PM, Stanislav Brabec wrote:
> > Junqian Gordon Xu wrote:
> >> On 01/30/2008 06:13 AM, Stanislav Brabec wrote:
> >>>> Paul Sokolovsky wrote:
> >>>> Can you please elaborate what the application of this patch
> >>>> would mean for OE (besides fixing support for one specific
> >>>> obscure peripheral)? 
> >> I guess I probably would be yelled at for not raising this before 
> >> committing your patch.
> >>
> >> Is this patch specific to Zaurus clamshells, akita/spitz/c7x0? In
> >> other words, are there any other devices benifiting from the
> >> extended keycode. I vaguely remember Dmitry asked about extended
> >> keycode for tosa, but I'm not sure he's talking about the same
> >> thing.
> > 
> > No. It adds support for key codes 128-255 in general.
> 
> I understand this patch is general. But could you educate me that
> except for the Z clamshells, what's the use case for other devices? I
> guess my question is more in line with Paul's challenge. Is this
> patch just a why-not for other devices or something might be helpful?

Something which might be helpful. What exactly do you want to know, or
what implications you want to make from that?

> 
> Regards
> Gordon



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Stanislav Brabec]

On Sat, 09 Feb 2008 07:00:34 -0600 Junqian Gordon Xu wrote:

> On 02/03/2008 03:57 PM, Stanislav Brabec wrote:

> > It adds support for key codes 128-255 in general.
> 
> I understand this patch is general. But could you educate me that
> except for the Z clamshells, what's the use case for other devices? I
> guess my question is more in line with Paul's challenge. Is this
> patch just a why-not for other devices or something might be helpful?

Many devices have special keys with (input.h) keycodes outside 1-127
(e. g. Mail - KEY_MAIL).

Now you have to map them to a random keys from range 1-127, otherwise
it will not work. In particular it invalidates key interpretation in
the kernel - kernel knows, that the key is Mail and not F11 but it has
to send KEY_F11, because KEY_MAIL is lost.

Even after this patch the situation will not be ideal - for example
KEY_OK has keycode 352 and cannot pass through X11 protocol. That is
why it is only a partial solution. Final solution could be: upgrade to
X12 (rewrite X and give up 20 years of compatibility; in proposal
collection stage) or at least write X Evdev Extension and Xlib keyboard
code rewrite (simpler to implement, but not yet started to work on).

The opinion of kernel people: We have a good and modern keyboard
layer, which can provide exact key meaning. We don't want to be limited
to 1-127 and mangle our keycodes. Let userspace fix their broken
drivers.

And hardware manufacturers don't make things easier. Many USB keyboards
identify themselves as devices including keys defined in the HID
standard (it allows them to recycle the same chip).

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [patch commit request] kdrive xserver: support for key codes 128-255

[Junqian Gordon Xu]

On 01/28/2008 12:19 PM, Stanislav Brabec wrote:
> Would be anybody with commit privileges to OE mtn so kind and review and
> commit attached fixes regarding keycodes 128-255 in kdrive xserver.

committed revision 3ea27c0c881e1f8965e9208c8a3d98d022602838

please feel free to test/comment or disapprove.

Regards
Gordon