Bug 11227 (x11-keycode-limit)

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.

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.

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.

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?

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

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.

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.

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.)

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

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.)

(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.)

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.

(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.

(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

(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.

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

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

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.

(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.

> 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".

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.

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

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

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.

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.

(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.

(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.

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

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

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.

(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.

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.

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.

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

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

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

ping

> --- Comment #37 from maximlevitsky@gmail.com 2010-07-03 18:52:41 PDT ---
> ping

pong. did you want to say something?

I mean, is there any update on this?

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

No.

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.

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

> 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.

> 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.

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.

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

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.

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

On 9 March 2012 00:56,  <bugzilla-daemon@freedesktop.org> wrote:
> --- Comment #48 from maximlevitsky@gmail.com 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.

(In reply to comment #49)
> On 9 March 2012 00:56,  <bugzilla-daemon@freedesktop.org> wrote:
> > --- Comment #48 from maximlevitsky@gmail.com 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)

Hi,

On 9 March 2012 12:51,  <bugzilla-daemon@freedesktop.org> wrote:
> --- Comment #50 from Nicolas Mailhot <nicolas.mailhot@laposte.net> 2012-03-09 04:51:08 PST ---
> (In reply to comment #49)
>> On 9 March 2012 00:56,  <bugzilla-daemon@freedesktop.org> wrote:
>> > --- Comment #48 from maximlevitsky@gmail.com 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.

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?

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

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

...

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?

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

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

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