Comment 13 for bug 543065

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