XI2 = moving target?

[Maxim Levitsky]

On Sun, 2009-07-26 at 18:41 +1000, 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.


And besides, this even doesn't work.
The older keyboard driver will read from underlying tty, while putting
it in raw mode. It actually assumes it always talks to standard PC
keyboard controller, (and kernel emulates it)

And newer evdev will pass keycodes as is to X, thus only way around
today is to make kernel driver remap the keycodes, and not all kernel
drivers support this, and there is no standard way to set such.

So, when we see 32 keycodes?


Best regards,
	Maxim Levitsky
> 
> 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.
> 
> Cheers,
>   Peter
> 
> > Alan Cox wrote:
> > >> Ergo my question on whether anyone has ever actually seen in captivity a 
> > >> keyboard with more than 248 keys...
> > > 
> > > I'm not sure that is a useful question.
> > > 
> > > I have a collection of keyboards and remotes. All of them have different
> > > functions above 255 which could be remapped. All of them are hot
> > > pluggable.
> > > 
> > > Trying to manage a mapping of all the devices randomly on the fly plugged
> > > into a system and map them into a tiny space is rather more difficult
> > > than you make out.
> > > 
> > > If you had to map a set of devices, once, to a fixed mapping it wouldn't
> > > be a big deal, but the world has moved on from that.
> > > 
> > > Alan
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg