Re: [PATCH][RFC] add support for PC-9800 architecture (13/26) key board

[Osamu Tomita]

Vojtech Pavlik wrote:
> 
> On Wed, Oct 23, 2002 at 02:09:12PM +0900, Osamu Tomita wrote:
> > Thanks for comments.
> >
> > -----Original Message-----
> > From: Vojtech Pavlik
> > To: Osamu Tomita
> > Cc: LKML; Linus Torvalds
> > Sent: 2002/10/22 19:43
> > Subject: Re: [PATCH][RFC] add support for PC-9800 architecture (13/26)
> > keyboard
> >
> > > I won't merge this unless it's cleaned up, kana support either made
> > > generic or put into keymaps, and the below problems resolved.
> >
> > > ... no way I'll add another default keymap when now we have unified
> > > keycodes. And we do support japanese keycodes/keymappings.
> > Japanese keycodes/keymapping support! We are very happy. IMHO To realize
> > this, emulations include shift-state modifier are needed??
> > Please point me where is source code, and we don't touch defkeymaps.
> 
> Tell me what exactly you need and if it cannot be done, I'll try to
> implement it in a generic way.
Thanks! Our needs are very simple. We want to get identical letter(keycode?)
with key top letter. For example, get "{" by shift + "[", "+" by shift + ";".
hardware of jp106 keyboard is similar with us keyboard, but key top letters
have differeces. Also PC-9800 keyboard has similar key top letter, according 
to JIS(Japanese Industrial Standards).
So I always load keymap when use jp106 keyboard.
 
> > >> diff -urN linux/drivers/char/keyboard.c
> > > Either there is a need for a special kanji mode changing function for
> > > japanese keyboards or there is not. Either way, it isn't PC-98 specific.
> 
> > I think it's for emergency(or rescue) purpose. For example, system cannot
> > boot due to illegal kanji named file, input kenji to select one and change
> > it. We plan direct character code input. In kanji-mode, do convert from
> > hex numeric input to kanji. But not implemented yet.
> 
> No problem, but this should be handled by a keymap (if possible). If
> not, the keymap code needs to be extended to be able to handle this.
I'll try, But I cannot do soon.

> > >> +#ifndef CONFIG_PC9800
> > >>  #define KBD_DEFLEDS 0
> > >> +#else
> > >> +#define KBD_DEFLEDS (1 << VC_NUMLOCK)
> > >> +#endif
> > > You want numlock on by default?
(snip)
> > >>  static void fn_scroll_forw(struct vc_data *vc)
> > >>  {
> > >> +#ifndef CONFIG_PC9800
> > >>    scrollfront(0);
> > >> +#else
> > >> +  scrollfront(3);
> > >> +#endif
> > >>  }
> > > Huh?
> > Due to our implementation of console driver. For old PC-9800, we use only
> > video ram. If don't, scrolling is _very_ slow. So our console can scroll
> > less than half lines of screen. If call with 0, screen doesn't scroll.
> 
> I see. However, I believe this should be handled in your implementation
> of the scrolling, and not affecting keyboard.c code.
I agree. This should be in VT module.

> > >> diff -urN linux/include/linux/logibusmouse.h
> > linux98/include/linux/logibusmouse.h
> > >> --- linux/include/linux/logibusmouse.h     Tue Aug  3 01:54:29 1999
> > >> +++ linux98/include/linux/logibusmouse.h   Fri Aug 17 22:15:13 2001
> > > Hmm, this file isn't used at all in 2.5. Why patching it?
> > IMHO Those (pc_keyb.h too) are remaining to compile user mode application.
> > I think it's a very rare, but ....
> 
> pc_keyb.h maybe. logibusmouse.h definitely not, no application is
> supposed to use those defines.
I see. I remove it from patch.

Regards
Osamu Tomita