Comment 15 for bug 313514

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