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.
Created attachment 10671 [details] [review] xorg-x11-server-linux-keyboard-mediumraw.patch
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.
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.
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.
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.
see bug #11227
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.
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.
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.
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.
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.
Created attachment 12567 [details] [review] xorg-kdrive-linux-keyboard-mediumraw.patch Updated patch with a fix mentioned in previous comment.
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.
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.
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.
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.