Bug 11545 - patch to support Linux Extended MEDIUMRAW keyboard mode (keycodes 128-255)
Summary: patch to support Linux Extended MEDIUMRAW keyboard mode (keycodes 128-255)
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Keyboard (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2007-07-11 11:56 UTC by Stanislav Brabec
Modified: 2018-06-12 19:07 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg-x11-server-linux-keyboard-mediumraw.patch (2.36 KB, patch)
2007-07-11 11:57 UTC, Stanislav Brabec
no flags Details | Splinter Review
xf86-input-keyboard-mediumraw.patch (2.59 KB, patch)
2007-11-14 07:22 UTC, Stanislav Brabec
no flags Details | Splinter Review
xf86-input-test-force-mediumraw-not-for-commit.patch (977 bytes, patch)
2007-11-14 07:26 UTC, Stanislav Brabec
no flags Details | Splinter Review
xorg-kdrive-linux-keyboard-mediumraw.patch (1.38 KB, patch)
2007-11-14 09:50 UTC, Stanislav Brabec
no flags Details | Splinter Review
unrelated-kdrive-without-xkb.patch (449 bytes, patch)
2007-11-14 14:09 UTC, Stanislav Brabec
no flags Details | Splinter Review
xorg-kdrive-linux-keyboard-mediumraw.patch (1.38 KB, patch)
2007-11-15 04:04 UTC, Stanislav Brabec
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2007-07-11 11:56:43 UTC
Attached patch adds support for Linux MEDIUMRAW keyboard more, which is required for supporting key codes >= 128 on platforms, where MEDIUMRAW is on (powerpc for xf86 and kdrive). It is intended to do nothing for platforms without MEDIUMRAW (keycode 0 used as escape is invalid and should never appear).

Notes:

- kdrive patch part is successfully tested: http://bugs.openembedded.org/show_bug.cgi?id=2637

- I currently have no machine to test xf86 driver. But both recycle the same code.

- Patch does not change kdrive API, which supports only 8-bit keycodes.

- It seems that KbdOn() is implemented twice: in hw/xfree86/os-support/linux/lnx_kbd.c and second time in lnx_io.c.
Comment 1 Stanislav Brabec 2007-07-11 11:57:35 UTC
Created attachment 10671 [details] [review]
xorg-x11-server-linux-keyboard-mediumraw.patch
Comment 2 Daniel Stone 2007-07-11 14:02:58 UTC
firstly, the protocol only supports keycodes up to 255, so there's no real way of working around that.  secondly, raw mode support has been in the linux keyboard driver for quite some time now, and is in the kdrive linux keyboard driver in git.

thanks for your report, though.
Comment 3 Stanislav Brabec 2007-07-12 03:02:48 UTC
This is not a patch for RAW more, but for MEDIUMRAW mode. MEDIUMRAW supports codes up to 16384.

MEDIUMRAW mode is default for PowerPC and for embedded devices using kdrive server.

And it for sure does not work for me without this patch.

MEDIUMRAW mode returns all keycodes >127 (not 256) as a sequence of three keys:

(KEYCODE 0) press/release
((KEYCODE >> 7) & 0x7f) release
(KEYCODE & 0x7f) release

For example Sharp CE-RH2 with sharpsl_rc kernel driver on Angstrom Linux with Xfbdev:

Without this patch xev shows for most keys on the remote:
Keycode 8 press
Keycode 8 release

With this patch it correctly works.
Comment 4 Daniel Stone 2007-07-12 03:33:48 UTC
yes, I'm aware of the extended keycodes.  largely because kdrive already supports them:
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;h=3193ab7613084f3f7feab7a6b7a4ae7044ab540c;hb=7c0ca27f6dd0a800dc27429a33dbc8e133f9a9c1;f=hw/kdrive/linux/keyboard.c

you are, however, mixing up x and linux keycodes.  x cannot emit a keycode above 255.  so you can support incoming keycodes of any value, but you can never put out a value above 255.  hence why attempting to feed a keycode of > 255 to kdrive is bogus: it _must_ be remapped in the driver.

your patch is against 1.2.0.  lnx_kbd.c already supports raw mode just fine, and now kdrive does too.  if your kernel refuses to emit raw scancodes for your particular architecture, then it can be easily fixed to do so, as was done for the nokia n800.
Comment 5 Stanislav Brabec 2007-07-12 08:08:51 UTC
The git code still uses MEDIUMRAW mode for XKB-disabled builds:

 733 #else
 734         ioctl(fd, KDSKBMODE, K_MEDIUMRAW);
 735 #endif

The new code handles RAW scancode prefixes for XKB-enabled. For XKB disabled and MEDIUMRAW, there is nothing new.

But my patch will need update to fit into the new source code.


Support for keycodes above 256 should be added anyway in some point in future. Without it it is impossible to fix evdev driver.
Comment 6 Daniel Stone 2007-07-12 08:28:34 UTC
see bug #11227
Comment 7 Stanislav Brabec 2007-07-12 08:46:34 UTC
Thanks to the pointer. Even without effort in bug 11227, my patch still can bring support for keys between 128 and 240 (255) for embedded systems using kdrive without xkb or powerpc.

Possible upper bits are now lost on the way, but at least 7 survive. It brings support for new devices (esp. audio control keys).

I'll update my patch for git snapshot.
Comment 8 Stanislav Brabec 2007-11-14 07:22:29 UTC
Created attachment 12543 [details] [review]
xf86-input-keyboard-mediumraw.patch

Updated patch for git version of xf86-input-keyboard and not using static variables.

Without this patch: Only MEDIUMRAW mode and key codes < 128 are supported.

With this patch: Extended MEDIUMRAW mode and key codes >= 128 are supported.

How to test the patch:

- Attach Sun keyboard to PowerPC machine with Linux kernel compiled with keyboard_sends_linux_keycodes feature (only there should be is MEDIUMRAW mode on by default).

- Test with Multimedia keyboard and simple patch attached in the next comment.

Question, why and where driver chooses RAW or MEDIUMRAW mode is above scope of this patch.
Comment 9 Stanislav Brabec 2007-11-14 07:26:49 UTC
Created attachment 12544 [details] [review]
xf86-input-test-force-mediumraw-not-for-commit.patch

Patch, which simplifies testing of previous patch. To test, run evtest in parallel with xev. X keycode should be equal to (evtest keycode + 8).

Note: I have suspicion, that at least some combinations of xf86-input-keyboard and xserver don't run PreInit properly - it was not sufficient to set it there.

kdrive patch will follow later.
Comment 10 Stanislav Brabec 2007-11-14 09:50:14 UTC
Created attachment 12548 [details] [review]
xorg-kdrive-linux-keyboard-mediumraw.patch

And here is ported patch for git version of kdrive.

It will be used only if --disable-xkb is used.

I failed to compile kdriver server from the git version (see below), but I believe, that the patch is correct, as it is a very conservative update of the previous patch (which works as expected).

devices.c:531: error: 'struct _KeyClassRec' has no member named 'xkbInfo'
window.c:433: error: too few arguments to function 'pScreen->CreatePixmap'

I will try to compile it later.
Comment 11 Stanislav Brabec 2007-11-14 14:09:25 UTC
Created attachment 12559 [details] [review]
unrelated-kdrive-without-xkb.patch

Confirming, that kdrive patch works as expected.

Tested on: Xfbdev with CE-RH2 remote control for Sharp Zaurus SL-C3200. This device (exactly kernel driver) sends some codes between 128 and 255. These codes are usable only after applying this patch.

Looking again at the patch, maybe it would be better to use "static unsigned char mediumraw_up;" instead of "static Bool mediumraw_up;".

Here is an unrelated fix, required to compile kdrive without xkb. Second error was mentioned above was caused by OpenEmbedded customization patches.
Comment 12 Stanislav Brabec 2007-11-15 04:04:57 UTC
Created attachment 12567 [details] [review]
xorg-kdrive-linux-keyboard-mediumraw.patch

Updated patch with a fix mentioned in previous comment.
Comment 13 Stanislav Brabec 2007-11-15 04:53:26 UTC
Could you review attached patches, please. (Please change comment "linux/drivers/keyboard.c" to "Linux kernel: drivers/char/keyboard.c")


Here is explanation of keyboard modes:

RAW: Kernel sends AT keyboard scancodes (linux-2.4) or false emulated AT keyboard scancodes (linux-2.6)

Extended RAW code processing: Processing of multi-byte RAW scancode sequences, typically E0 xx. Very long time in xfree86, new in kdrive.

MEDIUMRAW: Kernel sends keycodes as single bytes through the old keyboard interface. Only keycodes <128 can pass.

Extended MEDIUMRAW mode: Kernel sends keycodes through the old keyboard interface. Keys <128 as single virtual key, codes >=128 sends as sequence of 3 virtual keys: Key 0 press/release, virtual key "high 7 bits" release, virtual key "low 7 bits" release. See above mentioned kernel source link.

evdev mode: Kernel sends keycodes through the new keyboard interface. It can send real scancodes as an optional additional information.

Note: Extended MEDIUMRAW mode and evdev mode should provide the same keycodes.


Currently xf86-input-keyboard uses RAW mode for all devices except powerpc with kernel with MAC_ADBKEYCODES support and /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes, where it uses MEDIUMRAW. But there is no problem to enable it for all platforms (see xf86-input-test-force-mediumraw-not-for-commit.patch)

Currently kdrive uses RAW mode for builds with xkb and MEDIUMRAW mode for build without xkb.
Comment 14 Stanislav Brabec 2008-06-13 04:38:00 UTC
Ping. Could anybody comment this patch?

The kdrive version of this patch is used in OpenEmbedded based distributions for more than half year without any complain.
Comment 15 Stanislav Brabec 2009-05-20 04:40:05 UTC
Update to comment 13:

Currently xf86-input-keyboard uses RAW mode in all cases. Condition for powerpc with ADBKEYCODES is never true in kernels newer than ~8 years. If you don't want to apply this patch and make MEDIUMRAW mode available again, you can drop this code. evdev should do the same without any obscure encapsulation.

The patch for kdrive should be applied anyway, as MEDIUMRAW mode is used by default for all XKB-less builds and "Extended MEDIUMRAW" brings support for keys 128-255 there.
Comment 16 Adam Jackson 2018-06-12 19:07:41 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.