Re: Asian keyboards and input.h KEY_* defines

[Franz S. <Fra...@la...>]

On Sun, 23 Jul 2000, Vojtech Pavlik wrote:
> On Thu, Jul 20, 2000 at 04:07:52PM +0200, Franz Sirl wrote:
> > Hi,
> >
> > I have a hard time thinking about a reasonable mapping for the 4 extra
> > keys available on a Apple japanese USB and ADB keyboards (and this can
> > only get worse as more asian keyboards layouts will be supported). The
> > Apple version correctly uses international and language keys as defined
> > in the HUT spec 1.1, one of them is currently already mapped to KEY_JPN
> > in hid.c, but the others...
> >
> > So I suggest to add defines for KEY_INTL1-9 and KEY_LANG1-9 in input.h,
> > with a comment that they should be used as specified in the HUT. This
> > would in turn make KEY_JPN superfluous.
>
> I'd suggest KEY_INTL1 or KEY_LANG1 be the number KEY_JPN has now. What
> do you think?

Well, it's ugly, but I can live with that. Appended a new patch, which does 
it like you suggest. Mind you that I still didn't touch keycodes 179 and 180 
which seem to disagree between input.h and evtest.c (which says they are 
KPLeftParenthesis and KPRightParenthesis).

I included the generic changes for Macintosh keycode support too. The 
correction of the small plain_map/key_maps[0] uncleanliness in keyboard.c is 
necessary to support dynamic switching between keymaps, which I need to 
support both ADB and Linux keycodes at the same time.

OK, one roadblock removed now, I guess the changes in drivers/input  and 
input.h will be in 2.4 (and the backports) automatically with your merges?

Now I just have to pray to the Linux gods that Linus will accept the move of 
the input drivers into drivers/input in 2.4, so I can rely on them in the ADB 
HID driver even without CONFIG_USB defined. As soon that happens and I tested 
my code, I'll send you a clean adbhid.c for ruby.

I already said it and I say it again, I just _love_ the clean HID drivers 
possible with the input layer :-).

Franz.