XI2 = moving target?

[Peter Hutterer]

On Sun, Jul 26, 2009 at 09:10:52AM -0400, Jim Gettys wrote:
> 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'.

we're not disallowing the old system. right now only Linux uses the above
approach including the evdev driver, other systems still happily (?) use
kbd and the xkb tables to map model-specific requirements.

the whole point of the evdev driver is that the kernel pre-maps scancodes.
if the kernel doesn't do it, evdev is not the driver to use.

Cheers,
  Peter

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