XI2 = moving target?

[Jim Gettys]

Peter Hutterer wrote:
> On Sat, Jul 25, 2009 at 08:29:40PM -0400, Jim Gettys wrote:
>> I guess I'm still confused...
>>
>> So they'd show up as different devices with time; each time you get 
>> notification that the keysym mapping for the keycodes have changed.
>>
>> Why is there a problem?
> 
> It makes things overly complicated.
> 
> We use a number of shortcuts to simplify the keycode handling. One is that
> we don't actually use the keycode range as an actual range but rather use
> the keycodes in a way similar to keysyms. If you're using the evdev driver,
> each keycode is already defined to a specific symbol with hardware-specific
> quirks being done in the kernel or in HAL (possibly udev now, I still
> haven't looked into that).
> 
> You could free the keycodes completely but then you'd have to have a Kcgst
> mapping for xkeyboard-config for every single device. Which means that the
> maintainance of xkeyboard-config becomes a nightmare, together with the
> myriads of things that can go wrong when users select the wrong keyboard
> model. 
> 
> By having a standardised set of keycodes this becomes much easier.
> In fact these days it is irrelevant what you select as your keyboard model
> in the evdev ruleset - they all map to the evdev model (there are a few
> exceptions that do require separate models). So the XKB configuration mostly
> deals with the actual layouts, taking one layer of complexity out.
> 
> You could treat the keycode range as intended in the original X protocol,
> but then you'd have to have a model for every keyboard, remote, magic other
> device ever manufactured. We sort-of do that (look at the xorg/xfree86
> ruleset) but it's not pretty.
> 
> So by upping the keycode range to 32 bits we enable a larger standardised
> set of keycodes without the nightmare of maintaining loads of different
> keyboard models and requiring the user to configure them correctly.
> 
> Note that a keycode still doesn't stand for a symbol. KEY_Q is still an 'a'
> if you have an azerty group.

It certainly simplifies the drivers on PC hardware, ***so long as you 
don't want to support such hardware on old applications(*** (would that 
there had been anything close to a "standard" keyboard in 1988).

That may be reasonable at this date.

Embedded systems, however, are just as likely to expose raw scancodes; 
their evdev driver will be having to stand on their head to fit the PC 
model, which we may or may not consider to be a 'good thing'.

In anycase, the Xlib event structures are "int", which in these days can 
be presumed to be 32 bit quantities (since int=16 is now historical).
                             - Jim