MASTER: evdev driver ignores keycodes > 255

[casbon]

Binary package hint: xserver-xorg-input-evdev

package Version: 1:2.0.99+git20080912-0ubuntu5
Ubuntu 8.10

Keyboards can use keycodes that go above 255. See http://lxr.linux.no/linux+v2.6.28/include/linux/input.h
These are often multimedia keys for keyboards and remotes.

These are ignored by the evdev driver:
gimble:~/xserver-xorg-input-evdev-2.0.99+git20080912$ grep 255 src/evdev.c
    if (code > 255 && ev->code < KEY_MAX) {
    /* The X server can't handle keycodes > 255 anyway, just drop them. */

Which means they never reach X and therefore cannot be used in anyway.

The only workaround at the minute would be to use input-kdb to remap all keys for an input device to values lower than 255.

[Warp-spam+fdo (warp-spam+fdo)]

This is on my todo list for the xserver 1.4 release, however due to protocol issues it may not happen.

It most definitely will never be supported in the 1.1 branch.

It will definitely not happen instantly.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

I know it's a difficult problem, but lists blogs & wikis are littered with users trying to figure where in the kernel -> xorg input -> xkb bermuda triangle from hell their keys are lost (and then they pile on workarounds that make the situation worse more often than not)

I hope it will make 1.4. This is a major problems that has needed urgent fixing for a long time.

[Daniel Stone (daniels)]

by far the easiest way to fix this, is to bump the protocol to x12. that should give you an idea of how hard the alternatives are.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

despair :(

And yet it is getting impossible to buy plain input hardware without extended keys, and once users have them they expect them to work, so the house is burning today

Is x12 realistic for xserver 1.4?

[Daniel Stone (daniels)]

well, we've been on x11 since 1985, so it's not feasible to go to x12 in the next two months, no.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Ok.

I just hope then you're planning x12 inside xorg today then, because Linux is moving on the desktop space now (with Ubuntu and friends), and it won't be possible to ignore input problems anymore soon. We're not talking of ssh-accessed servers now.

[Daniel Stone (daniels)]

thanks for your concern, but you're talking to the people who are gradually rewriting the input code, and have, in fact, rewritten basically all of it (bar xkb -- which is in the middle of being rewritten itself) between three of us, in the past year. any contribution you may want to make is more than welcome, but failing that, you'll just have to be patient.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

I didn't want to seem disrespectful or anything like that. (If I was I apologize)

It's just all this x12 talk feels like even if the input code was written soon it would be delayed a long time before the other xorg maintainers agree on what to include in the protocol bump. So I was wondering if x12 was discussed @xorg so the excellent input code you fine people will surely write in the near future won't be delayed by x12 discussions.

(I also wanted to know if it was reasonable to plan xkb-config patching for my hardware, or if I was likely to use something else by the time evdev is fixed.)

[Alan Coopersmith (alan-coopersmith)]

Do you really need more than 255 keycodes at the same time? If not,
remapping keycodes > 255 to values < 255 should work with the existing
protocol (though I have no idea how hard it would be to do this mapping
in xevdev, since I've never looked at it).

As for X12 planning, the transition will be painful enough, we don't want
to do it more than once this decade, so we're in the stage of gathering up
all the things that need to be changed to get them all at once - see:
http://wiki.x.org/wiki/Development/X12

[Daniel Stone (daniels)]

unfortunately, xkb makes this mind-smashingly hard, but if anyone wants to code keycode compression into xkbcomp, feel free. (hint: don't start with the existing codebase.)

[Daniel Stone (daniels)]

(as an addendum, you'd need a way of hinting xkbcomp as to which keycodes to preserve, presumably by testing the EV_KEY bits. evdev needs a complete map; we don't know which keycodes will be needed until we've opened the device.)

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Add to this hotplug fun, when a new device that uses keys discarted to make place for something else can be inserted at any time.

No remapping is a requirement if you want to support new input hardware by default. To have generic support you need to declare every known extended keycode, so devices the user plug in (which use any subset of those) just work. As hardware manufacturers are real good at finding new extended keys and coming up with new input devices the 255 limit has been passed some time ago. Any form of reduction to 255 codes only results in key collisions with some input device sets.

Current remapping only works for configs customized for a particular device set, where you know the specific keycode set used. Also, every remapping requires a customized set of xkeyboard-config localized layouts. Since the result can not be safely shared, that's a labour-intensive enthusiast-only solution.

[Daniel Stone (daniels)]

(In reply to comment #12)
> Add to this hotplug fun, when a new device that uses keys discarted to make
> place for something else can be inserted at any time.

yes, that's fine. new devices are inserted individually, with completely different maps. the keymap of one device has absolutely no effect on the other: you can have three keyboards: one with a us layout, one with german, and one with french. actually, you can have 127 keyboards with different layouts.

> No remapping is a requirement if you want to support new input hardware by
> default. To have generic support you need to declare every known extended
> keycode, so devices the user plug in (which use any subset of those) just work.

that's what i said.

> As hardware manufacturers are real good at finding new extended keys and coming
> up with new input devices the 255 limit has been passed some time ago. Any form
> of reduction to 255 codes only results in key collisions with some input device
> sets.

you reduce per device. evdev lets you query which keys your keyboard is capable of producing, so unless you have a device with more than 255 physical keys, you're doing okay.

> Current remapping only works for configs customized for a particular device
> set, where you know the specific keycode set used. Also, every remapping
> requires a customized set of xkeyboard-config localized layouts. Since the
> result can not be safely shared, that's a labour-intensive enthusiast-only
> solution.

i'm not sure what you're trying to say here, other than manufacturers should make it possible for us to have any clue what the keyboard is automatically. right now, there are very, very, very few keyboards which actually give us enough information to set up a proper map per default.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #13)

> you reduce per device. evdev lets you query which keys your keyboard is
> capable of producing, so unless you have a device with more than 255 physical
> keys, you're doing okay.

But if you have device1 with extended key A, and device2 with extended key B, you still need to assign A & B different codes if you want A & B to have different effects on apps (that to not care where A & B are coming from)

To put stuff in perspective :

1. I have a bog-standard MS keyboard (ergo 4000). I count ~ 33 additional keys on it (not all exported via evdev yet, but they should be) 105 + 33 = 138 keys

2. I have an harmony universal remote. I will plug it in evdev someday. I count 47 keys that send an IR signal (actual number is higher, as the keys are modal and send different signals depending on the remote mode) 138 + 47 = 185 (most of the keys have different effects than the keyboard on and would be mapped to XF86Foo)

3. I've seen an xorg log yesterday with a mouse declaring ~ 30 buttons (most of which will be mapped to specific evdev codes) 185 + 30 = 215

That's awfully close to the 255 limit. Without even going to MPX and having several keyboards with different extended keys set on them

[Daniel Stone (daniels)]

(In reply to comment #14)
> (In reply to comment #13)
> > you reduce per device. evdev lets you query which keys your keyboard is
> > capable of producing, so unless you have a device with more than 255 physical
> > keys, you're doing okay.
>
> But if you have device1 with extended key A, and device2 with extended key B,
> you still need to assign A & B different codes if you want A & B to have
> different effects on apps (that to not care where A & B are coming from)

no, not really true. if you're typing on two different keyboards, then the core map gets pivoted every time the active device changes. anyhow, any toolkit not dealing with multiple devices separately is always going to have suboptimal behaviour. any app not using a toolkit is always going to have suboptimal behaviour.

> To put stuff in perspective :
>
> 1. I have a bog-standard MS keyboard (ergo 4000). I count ~ 33 additional keys
> on it (not all exported via evdev yet, but they should be) 105 + 33 = 138 keys
>
> 2. I have an harmony universal remote. I will plug it in evdev someday. I count
> 47 keys that send an IR signal (actual number is higher, as the keys are modal
> and send different signals depending on the remote mode) 138 + 47 = 185 (most
> of the keys have different effects than the keyboard on and would be mapped to
> XF86Foo)

no, you're still on device a: 138, and device b: 47.

> 3. I've seen an xorg log yesterday with a mouse declaring ~ 30 buttons (most of
> which will be mapped to specific evdev codes) 185 + 30 = 215

device a: 138, device b: 47, device c: 30.

> That's awfully close to the 255 limit. Without even going to MPX and having
> several keyboards with different extended keys set on them

i don't know what mpx has to do with multiple keyboards with multiple keymaps, since that can be done today.

you're still missing the point that we don't need to compress every device map into one map that covers every single keyboard plugged into the system. this is _not_ the case. really.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

Ok. Does compression need x12 too? or can it happen say this year?

[Daniel Stone (daniels)]

it's possible for someone to do it, yes. but it's not a small amount of work.

[Stanislav Brabec (sbrabec-suse)]

Two ideas, how to accept keycodes > 255 it backward compatible. All of them are ugly hacks, but may be accepted in X11 line:

1) evdev driver will query kernel for all available keys on all configured keyboards, then it will create table of false one-byte keysyms. In correspondence to them it will also write temporary xkb keycodes/evdev table.

2) X will accept keycodes > 255 internally, but in protocol level it will provide correct keysym with possibly incorrect keycode.

For both ugly hack is valid following limitation: Most applications read only keysym, the rest will break.

[Daniel Stone (daniels)]

(In reply to comment #18)
> 1) evdev driver will query kernel for all available keys on all configured
> keyboards, then it will create table of false one-byte keysyms. In
> correspondence to them it will also write temporary xkb keycodes/evdev table.

That only works if you have less than 255 possible keys.

> 2) X will accept keycodes > 255 internally, but in protocol level it will
> provide correct keysym with possibly incorrect keycode.
>
> For both ugly hack is valid following limitation: Most applications read only
> keysym, the rest will break.

The keysym is not sent with the event. Only the keycode is sent, and the applications keep a keycode/keysym mapping table. Having two mappings and switching between them will almost certainly break grabs, as well.

[Stanislav Brabec (sbrabec-suse)]

> That only works if you have less than 255 possible keys.

Yes. That can only work if you have less than 255 actual keys. You can still have more possible kernel key codes and assign X keycodes dynamically for actually existing keys. It can work, if only xkb will use keycodes directly and you will modify xkb table.

> The keysym is not sent with the event.

It means that xkb is completely in user level, isn't it?

There is a third ugly hack method inspired by "Extended MEDIUMRAW Mode" in Linux kernel. I guess that this one can be used to transfer keycodes without breaking protocol compatibility, but it will introduce need to modify input handling:

3) Use virtual key sequences to transfer more data:

Define say 17 reserved keys in the range < 256 - one ExtraEscape and sixteen ExtraData0-ExtraDataF.

Process keypresses in the following way:

- If the input keycode is from range 0-255 (except these 17 keys), handle it in a standard way.

- If the input keycode is outside this range, send it as a sequence of more keycodes: Each event can represent 4 bits, 4 events will create all 16 bits.

- These four events may be release only. If you allow press events as well, then it will need no ExtraEscape.

This method will still break applications waiting for "single press/release of any key".

[Stanislav Brabec (utx)]

Another idea, how to transfer characters > 255 through X11:

- Reserve say two modifiers for high keycodes (say ExtMod0, ExtMod1). Each extmod will add 1 bit.
- Programs using old byte-wide communication will get keypress as e. g. as ExtMod_combination+any_key_1-266
- Programs using new wide Xlib calls will get real keypresses (which can be sent in parallel with "compatible" way, or server and client can handshake about using this new way).

With 2 reserved modifiers we can transfer at least 956 keycodes, which seems to be sufficient in next few years.

[Daniel Stone (daniels)]

*** Bug 13203 has been marked as a duplicate of this bug. ***

[Daniel Stone (daniels)]

*** Bug 14843 has been marked as a duplicate of this bug. ***

[Stanislav Brabec (sbrabec-suse)]

Yet another idea, how to make it possible for X11: X Keycode Extension.

It would need patched of libX11 and server code on both sides. If X Keycode Extension will be present on both server and client, then wide keycodes will be transfered via extension. If not, low keycodes will be tranferred via standard X keyboard events, high keycodes will use "random" translation or they will be lost.

[Paul de Vrieze (pauldv)]

What are the possibilities of using a synthetic keyboard for this? This keyboard could just remove the most significant bit, and map the right keycodes.

[Daniel Stone (daniels)]

(In reply to comment #24)
> Yet another idea, how to make it possible for X11: X Keycode Extension.
>
> It would need patched of libX11 and server code on both sides. If X Keycode
> Extension will be present on both server and client, then wide keycodes will be
> transfered via extension. If not, low keycodes will be tranferred via standard
> X keyboard events, high keycodes will use "random" translation or they will be
> lost.

Given that this requires updates to XKB and Xi as well as the API and ABI of a lot of libraries, it's a lot easier for it to just be Xi 2/3 and XKB 2.

[Daniel Stone (daniels)]

(In reply to comment #25)
> What are the possibilities of using a synthetic keyboard for this? This
> keyboard could just remove the most significant bit, and map the right
> keycodes.

Unfortunately no, because this would break apps anyway, as no-one does the right thing of recalculating their keysym -> keycode tables for grabs when the map changes. So might as well just be Xi 2/3 and XKB 2.

[Daniel Stone (daniels)]

*** Bug 14078 has been marked as a duplicate of this bug. ***

[casbon (casbon)]

Binary package hint: xserver-xorg-input-evdev

package Version: 1:2.0.99+git20080912-0ubuntu5
Ubuntu 8.10

Keyboards can use keycodes that go above 255. See http://lxr.linux.no/linux+v2.6.28/include/linux/input.h
These are often multimedia keys for keyboards and remotes.

These are ignored by the evdev driver:
gimble:~/xserver-xorg-input-evdev-2.0.99+git20080912$ grep 255 src/evdev.c
    if (code > 255 && ev->code < KEY_MAX) {
    /* The X server can't handle keycodes > 255 anyway, just drop them. */

Which means they never reach X and therefore cannot be used in anyway.

The only workaround at the minute would be to use input-kdb to remap all keys for an input device to values lower than 255.

[casbon (casbon)]

It looks like X will not regard mappings above 255 and therefore a better way to solve this is with HAL keymaps. Not having much luck here though. I set a map for the keycode and the scancode,

root@gimble:/usr/share/hal/fdi/information/10freedesktop# lshal | grep keymap
  info.callouts.add = {'hal-setup-keymap', 'debian-setup-keyboard'} (string list)
  info.capabilities = {'input', 'input.keys', 'input.keymap', 'button'} (string list)
  input.keymap.data = {'377:wifi', '001c:wifi'} (string list)

but xev is not seeing those events.

[Timo Aaltonen (tjaalton)]

X can't handle keycodes above 255, so evdev is right. The mappings should be done in the kernel AIUI.

[casbon (casbon)]

Hi Timo,

I'm not sure that's correct. I think it's probably better to file as a bug against X in that case. There are more than 255 keycodes that can be generated by input.h so no mapping could be possible. I think it should be done by either the evdev driver or HAL.

[casbon (casbon)]

indeed, here is the upstream bug http://bugs.freedesktop.org/show_bug.cgi?id=x11-keycode-limit

[Johnathon (kirrus)]

Assigned to the upstream bug. I think this bug should be moved over to the xserver package, but I can't find it in the listing after a brief search...

[Johnathon (kirrus)]

It helps if I use the right URL to link it...

[Bryce Harrington (bryce)]

In the upstream bug report it indicates that this issue would be resolved by revving the x11 protocol. Presumably something in the protocol limits the data size to one byte, and would need to be changed to a larger size. Obvious question is why this couldn't be handled via an X extension.

[Bryce Harrington (bryce)]

Several other alternatives described:

 * "keycode compression" in xkbcomp.
 * Add two more reserved "modifiers" (say ExtMod0, ExtMod1) to increase key space to 0-956.
 * X Keycode Extension. Client apps would need to be modified to use this.

[Daniel Stone (daniels)]

fwiw, xi 2 will be released with xserver 1.7 in mid-2009.

[Peter Dey (s-launchpad-realmtech-net)]

I note that evdev-1.1.2 had a 'workaround', so at least some of the keys on these keyboards would work -- it would blindly remap the keycodes:

    X keycode = ((kernel keycode + 8) mod 256)

It's nasty, but at least it allows users with strange devices (like my Logitech UltraX) to work...

[Lauri Niskanen (ape3000)]

I have a Razer Tarantula USB keyboard. It is generally working fine and most of the multimedia keys are fully working. But some keys don't work.

Working multimedia keys: Sleep, Home, Player, Play, Stop, Next Song, Previous Song, Volume Up, Volume Down, Mute

I ran input-events to see if it recognizes the key events. I pasted the output.

No events: Rotate, Zoom 100%, Shuffle
Not working but events were found: Zoom In, Zoom Out

So some of the keys that are not working in X did show an event. They do have a key code that is over 0x0ff. (0x1a2 and 0x1a3)

acpi_listen didn't see the key presses. I also pasted the part of xorg.log that shows messages about this device.

[Bryce Harrington (bryce)]

Lauri, follow the troubleshooting directions at
http://wiki.ubuntu.com/Hotkeys/ and file a new bug for your issue. This
bug is just for tracking the issue in general not fixing specific issues.

On Fri, Mar 27, 2009 at 02:18:05PM -0000, Lauri Niskanen wrote:
> I have a Razer Tarantula USB keyboard. It is generally working fine and
> most of the multimedia keys are fully working. But some keys don't work.
>
> Working multimedia keys: Sleep, Home, Player, Play, Stop, Next Song,
> Previous Song, Volume Up, Volume Down, Mute
>
> I ran input-events to see if it recognizes the key events. I pasted the
> output.
>
> No events: Rotate, Zoom 100%, Shuffle
> Not working but events were found: Zoom In, Zoom Out
>
> So some of the keys that are not working in X did show an event. They do
> have a key code that is over 0x0ff. (0x1a2 and 0x1a3)
>
> acpi_listen didn't see the key presses. I also pasted the part of
> xorg.log that shows messages about this device.
>
> ** Attachment added: "input-events output"
> http://launchpadlibrarian.net/24406837/input-events
>
> --
> MASTER: evdev driver ignores keycodes > 255
> https://bugs.launchpad.net/bugs/313514
> You received this bug notification because you are a member of Ubuntu-X,
> which is subscribed to xorg-server in ubuntu.

[Stanislav Brabec (sbrabec-suse)]

As this problem is going to be resolved, we should start think about getting correct translation between kernel and X.

Proposed patch for the old keyboard driver to pass keycodes 128-16383 (128-255 with old Xi) using "Extended MEDIUMRAW" encapsulation: bug 11545

Keyboard mapping project page:
http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys

Mapping work-in-progress. One table and set of scripts providing all needed tables. Some keys still need discussion.

* Proposed mapping table between kernel and X: http://pack.suse.cz/sbrabec/keyboards/input_linux_map_fixed.txt

* Proposed logical categories of keys (to help understanding them): http://pack.suse.cz/sbrabec/keyboards/keymap_editor/keys.txt

* Scancode scripts for kernel (generated from X symbols/inet and table above): http://pack.suse.cz/sbrabec/keyboards/scancode_tables/

* Proposed code snippet to evdev_key.c driver (generated from the table above): http://pack.suse.cz/sbrabec/keyboards/evdev_key_c_table.txt

* Proposed X keycodes/evdev for evdev driver (generated from the table above): http://pack.suse.cz/sbrabec/keyboards/keycodes_evdev

* Proposed common extended basic keymap for X: http://pack.suse.cz/sbrabec/keyboards/symbols_evdev

* Proposed X keycodes/inet for RAW and SOFTRAW drivers (generated from X symbols/inet and table above): http://pack.suse.cz/sbrabec/keyboards/keycodes_inet

Things to discuss are marked with FIXME (X=X) (K=kernel)). It seems that several key codes in kernel are incorrect, and in X there are several duplicate codes.

Vojtech Pavlik provided a several banana boxes of obscure keyboards to me, so I am using the same source as he had 11 years ago for kernel.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #30)
> Proposed patch for the old keyboard driver to pass keycodes 128-16383 (128-255
> with old Xi) using "Extended MEDIUMRAW" encapsulation: bug 11545

I'm not sure that we'd want to extend the kbd driver. evdev is the better vehicle for this, and maybe this puts enough pressure on other OS to provide an evdev-like input system.

> * Proposed code snippet to evdev_key.c driver (generated from the table above):
> http://pack.suse.cz/sbrabec/keyboards/evdev_key_c_table.txt

this table is ifdef'd out if you're compiling against the server past 1.6. so this part not needed.

[Stanislav Brabec (sbrabec-suse)]

For kdrive, the patch is important. Many embedded platforms still use old keyboard driver in MEDIUMRAW mode as a default and this patch extends key code range from 0-127 to 0-255. The kdrive patch is used in distributions derived from OpenEmbedded for several years.

"Extended MEDIUMRAW" mode should be superseded by evdev in the standard Xorg server. MEDIUMRAW mode is not used there for ~10 years and the code may be simplified by dropping its support at all as an alternative to "MEDIUMRAW -> Extended MEDIUMRAW" patch.

[Dakkar-thenautilus (dakkar-thenautilus)]

I realize I'm coming in pretty late to this bug, but I actually wrote a work-around (I won't presume to call it a "solution", I know it's a hack) to the evdev code that "work for me".

You can see it at http://www.thenautilus.net/cgit/xf86-input-evdev/?h=code-remap

Summary: I added a new option, "evdev_key_remap", whose value should be a string of the format "$evdev_code = $x11_code ..." (a sequence of "assignments" separated by spaces). The PostKbdEvent function will then use those "assignments" to remap the codes coming from the device.

I have it running on my machine, with the new option set to "464=118", so that the "Fn" key in my Apple Aluminium keyboard is treated as the "Ins" key that occupies that space on most other keyboards.

Hope this helps.

[Andre Klapper (a9016009)]

(Maemo downstream ticket at https://bugs.maemo.org/show_bug.cgi?id=3021 .)

[Peter Hutterer (peter-hutterer)]

*** Bug 23538 has been marked as a duplicate of this bug. ***

[Julien Cristau (jcristau)]

*** Bug 26876 has been marked as a duplicate of this bug. ***

[markus haider (markus.haider)]

I am running the beta of Lucid Lynx, and the problem still exists (it doesn't recognize the Zoom stick of my Microsoft Ergonomic 4000)

[Marcin Gil (marcin.gil)]

Same here: Lucid, MS Ergonomic 4000. Zoom doesn't work.

[Roman V. Isaev (rm-isaev)]

Same here. Ubuntu 10.04, MS Natural 4000, zoom does not work.

[Roman V. Isaev (rm-isaev)]

I made a quick fix for this problem. It's based on kbd's showkey that DOES show scancodes. It looks into configuration table and stuffs required keysyms into X via Xtst package. Ugly, buggy and setuid (to read console under X you have to be setuid), but it works (at least for me) and requires only installation of the deb package. Lucid package is here:

add-apt-repository ppa:rm-isaev/rawkeybind
apt-get update
apt-get install rawkeybind

Source code: http://www.isaev.ru/rawkeybind/

By default zoom up and down are bound to up arrow and down arrow but you can change it in /etc/rawkeybind.conf

[Maxim Levitsky (maximlevitsky)]

ping

[Julien Cristau (jcristau)]

> --- Comment #37 from <email address hidden> 2010-07-03 18:52:41 PDT ---
> ping

pong. did you want to say something?

[Maxim Levitsky (maximlevitsky)]

I mean, is there any update on this?

[Andre Klapper (a9016009)]

(In reply to comment #39)
> I mean, is there any update on this?

No.

[stinkinrich88 (stinkinrich88)]

Roman, your workaround works for me. But only with up/down arrow keys. I can't assign my zoom stick to fire mouse buttons 4 & 5 (i.e. scroll wheel). It gives me an error when I try this...

[Zoran Olujić (olujicz)]

Roman, it is working here on lucid and Microsoft Natural 4000. Thanks :)

[Adriano Mitre (adriano-mitre)]

Not working here: Ubuntu 9.10 (Karmic Koala) 64-bits, Microsoft Natural
Ergonomic Desktop 7000.

2010/8/26 Zoran Olujić <email address hidden>

> Roman, it is working here on lucid and Microsoft Natural 4000. Thanks :)
>
> --
> MASTER: evdev driver ignores keycodes > 255
> https://bugs.launchpad.net/bugs/313514
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (356075).
>

[Maxim Levitsky (maximlevitsky)]

Why not at least for now let the evdev to send extended keys as a say Mod5+key?
I mean this is real very nasty problem for users with IR remotes, and formal support for which will land in 2.6.36.

[Peter Hutterer (peter-hutterer)]

any "for now" solution that ends up being used is hard to change later on
without breaking clients. And we're generally trying to avoid that.

besides, evdev doesn't really have a notion of Mod5, it may be reassigned at
any time and the driver wouldn't even notice. while that's not common it
cannot be ruled out and would just causes more issues

[RussianNeuroMancer (russianneuromancer)]

> I mean this is real very nasty problem for users with IR remotes
Also there is a big problem with hardware hotkeys on laptops. Many laptops have hardware buttons for launch audio and video players, but because of this bug at this moment not possible to assign this buttons to suitable KEY_AUDIO and KEY_VIDEO scancodes.

[gcb (gcb0)]

The shotgun solution for this, that does not require to rewrite X protocols, are to:

1) simply remap based on model.
Who cares if microsoft wants my keyboard 4000 zoom keys to be scancode 89354^2? just map it to 139 or any other scan code available (the keyboard does not have more than 255 keys!). also, everyone will map it to mouse buttons 4 and 5 anyway :)

2) or just assign the next non-standard key available.

if standard keys goes up to 127 (don't know, i'm guessing, as this was the old limit), and let's say my natural keyboard 4000 uses keys up to 127 and then goes on to use 140, 141 and 142, and then start using wacky numbers, say 498 and 497 for the zoom thing in the middle. simply map those as 128 and 129, since they are the lowest non-standard (>127 or other number) available.

[Dana Goyette (danagoyette)]

On my laptop, the keys that are handled by the hp_wmi give no scancodes at all -- they're hardcoded to specific, too-high keycodes such as KEY_INFO! You have to edit the module source to change them.

Some of the other keys' mappings are handled by udev, though. If the keymap creators, as shown by the "(high keycode)" comments in the udev keymap file, already know we can't handle KEY_PRESENTATION, then why do they use that key? They should use something else, like xf86launch1!

[RussianNeuroMancer (russianneuromancer)]

@gcb
There already solution - Wayland.

[Marco Chiappero (mchiappero)]

Well, I hope for every distribution and developers to move to Wayland as soon as possible (so we can get rid of this 25 years old X crap), but in the meantime is there a chance to have keycodes > 255 working with X without having to poke at input.h every now and then? It there a solution to easily remap those keycodes so they can be seen by X? I'm trying to figure out whether it is possible via udev but I came to nothing at the moment. I think that multimedia keyboards are now too widespread, a workaround (and an howto) is really needed. It's just ridiculous having a simple thing like a keyboard key not working, in 2011!!!

[Marco Chiappero (mchiappero)]

Got my keys working thanks to udev, I was remapping to keycodes with no keysym associated (and avoiding xmodmap as well). WOW, after lots of waisted hours and after 3 years since I bought this keyboard, I can finally use all my multimedia/extra keys! Amazing! Thanks X11!

[Andrew (andrew-rw-robinson)]

@Marco, would you mind sharing what you did with udev to get it working?

[Vish (vish)]

Marco Chiappero , By 'extra keys' you mean , $ / € ? or.. ?

[Hossbeast (todd-freed)]

@Marco Do you have a zoom slider, and have you gotten it working?

[Marco Chiappero (mchiappero)]

First of all I own a Logitech LX710 desktop kit, one single USB receiver for both keyboard and mouse. You can have a look at the keyboard here http://launchpadlibrarian.net/21698239/lx710.jpg and see what I mean for extra/multimedia keys: on the left there is some image editing stuff, on the left some music stuff, a few customizable shortcuts (Fn+F9/F10/F11/F12) and some predefined ones (Word, Excel, Calendar, Calculator, and so on), a few more like Search, Mail, VoIP (as you can see no zoom slider, sorry). I just love the side keys (I wish I had them on my laptop too), but unfortunately many of them didn't work out of the box (all the left ones, the shuffle key, and some others). That's because they are correctly mapped by the kernel (using the right definitions in input.h) from scancodes (the way the hardware notifies a key pressure) to keycode numbers above the 255 value (you can verify this using showkey). So no chance to see them shown up by xev (note that X reads kernel keycodes - from 1 to 255 - and maps them to different keycodes and finally maps them to keysym). So, it is necessary to change the scancode -> keycode mapping at kernel level for all those "dead" keys, choosing from the ones not already assigned in the range 127-247 (have a look at input.h for keycode definitions and use showkey to avoid collisions). This can be accomplished using udev-extra (read /usr/share/doc/udev/README.keymap.txt for help), following two steps:

1) you have to define all the remappings that you need (in the form of "scancode keycode" list) and place them in a file under "/lib/udev/keymaps/" (for example I created logitech-lx710-cordless there). You can find the scancodes using evtest ("sudo evtest /dev/input/eventX", where X is your keyboard device. Be careful, sometimes these extra keys are exposed through a different device or your mouse interface: eg. event3 --> kbd, event4 --> mouse & extra keys). Here some sample output:

Event: time 1294153475.909379, type 4 (Misc), code 4 (ScanCode), value c1028
"c1028" is the scancode value you're going to place in your keymap file, then pick up a number from input.h as described earlier and convert it to hexadecimal. Then write the remap pair in your file, maybe with a descriptive comment, like this:

0xC1028 0x9a # rotate button

Iterate for every key > 255.

2) you have to tell udev to apply this remapping file everytime it encounters your keyboard, so edit the "/lib/udev/rules.d/95-keymap.rules" file adding the udev rule that matches your HW. Please don't ask me to define a rule for you. NOTE: you can immediately apply your keymap file by yourself typing "sudo /lib/udev/keymap /dev/input/eventX /lib/udev/keymaps/$YOUR_FILE" and verify it with evtest once again.

Now, you can use the Gnome shortcuts editor to see that the keys are now usable inside X and create new shortcuts. However it might happen that no keysym is assigned to that keycode (so you'll see 0xXY instead of XF86Foo). You can see current mappings through xmodmap -pke, save the output into a file and edit it if you need (a full keysym code list is available in "/usr/lib/X11/XKeysymDB"). Once you added the keysyms to those keys you remapped, y...

[Freedesktop-org (freedesktop-org)]

> Also there is a big problem with hardware hotkeys on laptops. Many laptops have
> hardware buttons for launch audio and video players, but because of this bug at
> this moment not possible to assign this buttons to suitable KEY_AUDIO and
> KEY_VIDEO scancodes.

It's not only laptops now. Many modern mice are affected, in fact I'm suffering now due to this bug. The only affordable mouse that conforms to my disability is unusable due to this bug. So for me, this is an accessibility issue as well.

[Peter Hutterer (peter-hutterer)]

1. We know this is already a problem.
2. The fix to this problem is huge, difficult and very invasive. It requires a new protocol extension and all the inertia that comes with it.
3. The proper fix to this problem breaks client-side API. see 2.
4. Workarounds can be found, but are limited to some use-cases only and will not work for the generic solution, because see 2.
5. We don't have enough man-power to fix this at this point, because see 2.

Please refrain from commenting on this bug unless you can help with 5. Points 1 to 4 are pretty much non-negotiable.

[Denis Kniazhev (denis-k1985)]

Microsoft Ergo 4000 - center zoom key doesn't work (using sudo showkey -k, key codes are 418 and 419)

[Denis Kniazhev (denis-k1985)]

@Marco Chiappero - Thank you, your guide worked!

[Marco Chiappero (mchiappero)]

Glad I could help

[Adriano Mitre (adriano-mitre)]

@Marco Chiappero - Thank you!

My config: Ubuntu 10.10 desktop 64 bits / MS Ergonomic Desktop 7000

On Tue, Jun 14, 2011 at 6:28 AM, Marco Chiappero <email address hidden> wrote:

> Glad I could help
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (356075).
> https://bugs.launchpad.net/bugs/313514
>
> Title:
> MASTER: evdev driver ignores keycodes > 255
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/313514/+subscriptions
>

[Jeremy Sequoia (jeremyhu)]

*** Bug 13356 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

Further to the advice in #72 above, I'd just like to point out that as of udev version 175, default udev keymapping can be overridden by means of a file in /etc/udev/keymaps/ named the same as the file in /lib/udev/keymaps/ that it overrides.

Suppose, for example, you want to make use of the Zoom key on a ThinkPad X220. The file /lib/udev/keymaps/module-lenovo maps this key with scancode 0x13 to "zoom", i.e., KEY_ZOOM, which has a value of 372. To change this to "prog2", i.e., KEY_PROG2, value 149 (corresponding to X event XF86Launch2, value 157), copy /lib/udev/keymaps/module-lenovo to /etc/udev/keymaps/module-lenovo and change the line "0x13 zoom" to "0x13 prog2".

[Martin Thoma (themoosemind)]

The special €-key and $-key on my Acer Travelmate 5735Z with Ubuntu 10.04.3 LTS are also not working.

(I'm not quite sure if this is the right place, but it was marked as duplicate of Bug 30562)

[Maxim Levitsky (maximlevitsky)]

Isn't it a solution just to fix XI2 to pass through extended codes?
So every TV viewer application, could just register for XI2 inputs and thats all.
That would at least make IR remote support on par with Windows, where also just few keys on the MCE remote work everywhere, but all keys work in media center.

[Maxim Levitsky (maximlevitsky)]

Especially knowing that on protocol level XI2 does support extended events.
Its just matter of fixing X code.

[Daniel Stone (daniels)]

On 9 March 2012 00:56, <email address hidden> wrote:
> --- Comment #48 from <email address hidden> 2012-03-08 16:56:28 PST ---
> Especially knowing that on protocol level XI2 does support extended events.
> Its just matter of fixing X code.

To an extent, yes. Extended keycodes could relatively easily be
passed through XI2, but XKB needs to be extended so clients know what
those keys actually mean.

[Nicolas-mailhot-laposte (nicolas-mailhot-laposte)]

(In reply to comment #49)
> On 9 March 2012 00:56, <email address hidden> wrote:
> > --- Comment #48 from <email address hidden> 2012-03-08 16:56:28 PST ---
> > Especially knowing that on protocol level XI2 does support extended events.
> > Its just matter of fixing X code.
>
> To an extent, yes. Extended keycodes could relatively easily be
> passed through XI2, but XKB needs to be extended so clients know what
> those keys actually mean.

Why would xkb need to know that ?

Can't apps and xkb maps not reference them by code number ? (as is already the case for most unicode points xkb has no pretty name for)

[Daniel Stone (daniels)]

Hi,

On 9 March 2012 12:51, <email address hidden> wrote:
> --- Comment #50 from Nicolas Mailhot <email address hidden> 2012-03-09 04:51:08 PST ---
> (In reply to comment #49)
>> On 9 March 2012 00:56,  <email address hidden> wrote:
>> > --- Comment #48 from <email address hidden> 2012-03-08 16:56:28 PST ---
>> > Especially knowing that on protocol level XI2 does support extended events.
>> > Its just matter of fixing X code.
>>
>> To an extent, yes.  Extended keycodes could relatively easily be
>> passed through XI2, but XKB needs to be extended so clients know what
>> those keys actually mean.
>
> Why would xkb need to know that ?
>
> Can't apps and xkb maps not reference them by code number ? (as is already the
> case for most unicode points xkb has no pretty name for)

XKB's keycode type is an unsigned char, which only holds eight bits.
It has no way of referring keycodes above 255, without breaking
protocol.

[Adam Jiang (jiang-adam)]

This issue blocks me to enjoy my new keyboard which has ZOOMIN/OUT and SPELLCHECK keys.

I have read through this thread. It seems we are facing manpower issues to get it fixed. I'd like to try to help on this if I can get mentor from you guys.

Another idea is about getting keycode > 255 by Xi2. Is this could be considered a shortcut to avoud protocol breaking. Shall we give a try on it?

[Peter Hutterer (peter-hutterer)]

XI2 already sends 32-bit keycodes, it's the XKB layer and thus the ability to interpret this that doesn't handle them.

[Stanislav Brabec (sbrabec-suse)]

If somebody is still interested in project of Linux input device => X key codes mapping from the comment 30, there is an update with new URLs (no other changes were done in the comment nor linked files):

Stanislav Brabec 2009-05-20 04:24:46 UTC

As this problem is going to be resolved, we should start think about getting correct translation between kernel and X.

Proposed patch for the old keyboard driver to pass keycodes 128-16383 (128-255 with old Xi) using "Extended MEDIUMRAW" encapsulation: bug 11545

Keyboard mapping project page:
http://fedoraproject.org/wiki/SIGs/Laptop/HotKeys

Mapping work-in-progress. One table and set of scripts providing all needed tables. Some keys still need discussion.

* Proposed mapping table between kernel and X: http://ftp.suse.com/pub/people/sbrabec/keyboards/input_linux_map_fixed.txt

* Proposed logical categories of keys (to help understanding them): http://ftp.suse.com/pub/people/sbrabec/keyboards/keymap_editor/keys.txt

* Scancode scripts for kernel (generated from X symbols/inet and table above): http://ftp.suse.com/pub/people/sbrabec/keyboards/scancode_tables/

* Proposed code snippet to evdev_key.c driver (generated from the table above): http://ftp.suse.com/pub/people/sbrabec/keyboards/evdev_key_c_table.txt

* Proposed X keycodes/evdev for evdev driver (generated from the table above): http://ftp.suse.com/pub/people/sbrabec/keyboards/keycodes_evdev

* Proposed common extended basic keymap for X: http://ftp.suse.com/pub/people/sbrabec/keyboards/symbols_evdev

* Proposed X keycodes/inet for RAW and SOFTRAW drivers (generated from X symbols/inet and table above): http://ftp.suse.com/pub/people/sbrabec/keyboards/keycodes_inet

...

[Dqarras (dqarras)]

It seems pretty clear that this is not going to get fixed for X but could someone add a comment here for reference whether this same limitation is true or not for Wayland?

[Peter Hutterer (peter-hutterer)]

wayland uses 32 bit keycodes, so it doesn't have the same limitation.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu laptop testing tracker.

A list of all reports related to this bug can be found here:
http://laptop.qa.ubuntu.com/qatracker/reports/bugs/313514

[Peter Hutterer (peter-hutterer)]

*** Bug 98998 has been marked as a duplicate of this bug. ***

[Daniel van Vugt (vanvugt)]

Thank you for reporting this bug to Ubuntu.
Ubuntu 8.10 (intrepid) reached end-of-life on April 30, 2010.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

[Ajax-a (ajax-a)]

https://gitlab.freedesktop.org/xorg/xserver/issues/260

[Paul Menzel (paulmenzel)]

Is this still a problem with *xserver-xorg-input-libinput*, which replaces *xserver-xorg-input-evdev*?