Re: Asian keyboards and input.h KEY_* defines

[Vojtech P. <vo...@su...>]

On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote:

> Well, it's ugly, but I can live with that.

It is, but it'll allow existing mappings to keep working. There is a lot
more ugliness in the numbering of the keys, so I think this is not a big
problem.

If you could also patch the attached list of scancodes with the added
stuff, I'd be grateful ...

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

Added to input.h

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

> 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?

Yes, I hope so. As long as they don't break 2.4.

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

I hope Linus will accept it. The split (drivers/usb +
drivers/char/joystick) already is causing trouble.

> As soon that happens and I tested 
> my code, I'll send you a clean adbhid.c for ruby.

Great. Well, you can send it even if it's not tested - ruby is a
development tree, many things there don't event compile.

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

Thank you. You know, it really makes me happy hearing this.

-- 
Vojtech Pavlik
SuSE Labs