[oe] [patch commit request] kdrive xserver: support for key codes 128-255
Stanislav Brabec
utx at penguin.cz
Wed Jan 30 12:13:16 UTC 2008
Paul Sokolovsky wrote:
> On Mon, 28 Jan 2008 19:19:04 +0100
> Stanislav Brabec <utx at 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
More information about the Openembedded-devel
mailing list