linuxconsole-dev

Asian keyboards and input.h KEY_* defines

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

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.

Franz.

[PATCH] Better support for foreign language keyboards (was: Asian keyboards and input.h KEY_* defines)

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

On Thu, 20 Jul 2000, 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 have done a patch now for this. Please note that evtest.c and input.h 
disagree on their understanding of keycode 179 and 180.

Franz.

Re: Asian keyboards and input.h KEY_* defines

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

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?

-- 
Vojtech Pavlik
SuSE Labs

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.

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

Re: Asian keyboards and input.h KEY_* defines

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

On Sun, 23 Jul 2000, Vojtech Pavlik wrote:
> On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote:
> If you could also patch the attached list of scancodes with the added
> stuff, I'd be grateful ...

Which attachment? Maybe you should checkin that to ruby :-).

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

Thanks. I've got another report now on the USB KPComma key (0x85), is it safe 
to map that to KEY_KPDOT, or do keyboards with both of them exist?

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

Any feedback from Linus yet?

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

OK, I have to make some decisions still, but after that I'll send it.

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

Well, that's the way I feel after working with the code. There are some minor 
loose ends, but I really like the design.

Franz.

Re: Asian keyboards and input.h KEY_* defines

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

On Mon, Jul 24, 2000 at 01:18:56AM +0200, Franz Sirl wrote:
> On Sun, 23 Jul 2000, Vojtech Pavlik wrote:
> > On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote:
> > If you could also patch the attached list of scancodes with the added
> > stuff, I'd be grateful ...
> 
> Which attachment? Maybe you should checkin that to ruby :-).

I forgot to attach it. Ok, it's in ruby, under utils/

> > > 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
> 
> Thanks. I've got another report now on the USB KPComma key (0x85), is it safe 
> to map that to KEY_KPDOT, or do keyboards with both of them exist?

I hope it's safe, I haven't seen a keyboard with both yet.

> > I hope Linus will accept it. The split (drivers/usb +
> > drivers/char/joystick) already is causing trouble.
> 
> Any feedback from Linus yet?

No, and I doubt there will be any - either the patch appears in some of
the later kernels or not.

> > Great. Well, you can send it even if it's not tested - ruby is a
> > development tree, many things there don't event compile.
> 
> OK, I have to make some decisions still, but after that I'll send it.

Thanks.

> > Thank you. You know, it really makes me happy hearing this.
> 
> Well, that's the way I feel after working with the code. There are some minor 
> loose ends, but I really like the design.

Yes, I believe it'll get better with time.

-- 
Vojtech Pavlik
SuSE Labs

Re: Asian keyboards and input.h KEY_* defines

[James S. <jsi...@ac...>]

> > I hope Linus will accept it. The split (drivers/usb +
> > drivers/char/joystick) already is causing trouble.
> 
> Any feedback from Linus yet?

Nope. Waiting for test5-pre5 to see if he accepted it. 

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

Everything should compile. Not everything will work right :-( You don't
need to set VT_EXTEND anymore.  

> > > 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.
> 
> Well, that's the way I feel after working with the code. There are some minor 
> loose ends, but I really like the design.

Me too. I love the /dev/input interface. I'm glad to see linux have a sane
interface now. Just to get all the mice converted for 2.4.0. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net