[RFC] Different keyborad layouts

[RFC] Different keyborad layouts

[Carles Pina i Estany]

Hello,

I was thinking how we could have different keyboard layouts and after
have some ideas I sent some emails to Robert about this topic (who had some
better ideas :-) )

Let me to explain here some plan/design. I would like to research on it
after some weeks, but if we need some discussion we could have it before
:-)

(this is the result of some mails with Robert, so I'm copying/pasting and
changing some things, if I'm wrong Robert correct me!)

Plan:
- in term/i386/pc/at_keyboard.c we could have something like this:

  static char english_map[] = { x, x, x };
  char *map = english_map;

- have a new module with different layouts and variable hook

- when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module would
redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
de_map, etc.)

Nowadays at_keyboard.c is not used, I could enable for testing. It seems that
when USB keyboard will be integrated everybody will use at_keyboard.c (or at
least USB and i386-pc)

How it sounds?

It would be very nice for Grub, to have different layouts and localization :-)

Thanks,

-- 
Carles Pina i Estany		GPG id: 0x17756391
	http://pinux.info

Re: [RFC] Different keyborad layouts

[Vesa Jääskeläinen]

Carles Pina i Estany wrote:
> Hello,
> 
> I was thinking how we could have different keyboard layouts and after
> have some ideas I sent some emails to Robert about this topic (who had some
> better ideas :-) )
> 
> Let me to explain here some plan/design. I would like to research on it
> after some weeks, but if we need some discussion we could have it before
> :-)
> 
> (this is the result of some mails with Robert, so I'm copying/pasting and
> changing some things, if I'm wrong Robert correct me!)
> 
> Plan:
> - in term/i386/pc/at_keyboard.c we could have something like this:
> 
>   static char english_map[] = { x, x, x };
>   char *map = english_map;

Explain this a bit more...

Remember that in some keyboard you need to press combos in order to
generate some character. Like in Finnish keyboard you press alt-gr + e
in order to generate euro sign (or alt-gr + 5). Also there are
multi-keypress sequences like in order to make '^' this sign you have to
press ctrl + '^' button and when released then press space. If you
happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
do not think this is the only keyboard with this feature. Also there is
those dec input sequences like alt+number sequence. In example alt
(pressed) + '6', '5' you get 'A'.

> - have a new module with different layouts and variable hook
> 
> - when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module would
> redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
> de_map, etc.)

I do not like the idea of using variable for this as it will most likely
require loading of keymap definition form disk. So I would prefer something:

insmod keymap
keymap /boot/grub/keyboard/fi

Also remember that you most likely want to play with scancodes when
transcoding keysequences. I would propose that you convert those
sequences to unicode so it would be easier to process. And if key is not
possible to code as unicode then some kinda of keyevent with flag that
this is eg. key up or something like that.

Re: [RFC] Different keyborad layouts

[Carles Pina i Estany]

Hello,

On Sep/29/2008, Vesa Jääskeläinen wrote:
> Carles Pina i Estany wrote:
> > Hello,
> > 
> > I was thinking how we could have different keyboard layouts and after
> > have some ideas I sent some emails to Robert about this topic (who had some
> > better ideas :-) )
> > 
> > Let me to explain here some plan/design. I would like to research on it
> > after some weeks, but if we need some discussion we could have it before
> > :-)
> > 
> > (this is the result of some mails with Robert, so I'm copying/pasting and
> > changing some things, if I'm wrong Robert correct me!)
> > 
> > Plan:
> > - in term/i386/pc/at_keyboard.c we could have something like this:
> > 
> >   static char english_map[] = { x, x, x };
> >   char *map = english_map;
> 
> Explain this a bit more...
> 
> Remember that in some keyboard you need to press combos in order to
> generate some character. Like in Finnish keyboard you press alt-gr + e
> in order to generate euro sign (or alt-gr + 5). Also there are
> multi-keypress sequences like in order to make '^' this sign you have to
> press ctrl + '^' button and when released then press space. If you
> happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
> do not think this is the only keyboard with this feature. Also there is
> those dec input sequences like alt+number sequence. In example alt
> (pressed) + '6', '5' you get 'A'.

Spanish one is similar (well, vowells are easier to pronunce ;-) )

> > - have a new module with different layouts and variable hook
> > 
> > - when user (or grub.cfg) change some variable (KEY_LAYOUT?), this module would
> > redefine the term/i386/pc/at_keybord.c char *map to KEY_LAYOUT_map (es_map,
> > de_map, etc.)
> 
> I do not like the idea of using variable for this as it will most likely
> require loading of keymap definition form disk. So I would prefer something:
> 
> insmod keymap
> keymap /boot/grub/keyboard/fi

from below problems (difficult to handle with the static char *map (that
we currenty have) plus this idea from you, my understanding is that we
should go having something like
/usr/share/keymaps/i386/qwerty/fi.kmap.gz (change your layout and
architecture, etc.)

So, the layout is not an easy char *map but it's a definition inside a
file. Maybe same one that Linux console?

> Also remember that you most likely want to play with scancodes when
> transcoding keysequences. I would propose that you convert those
> sequences to unicode so it would be easier to process. And if key is not
> possible to code as unicode then some kinda of keyevent with flag that
> this is eg. key up or something like that.

I take note.

All this "a bit more complicated case" if we want full layout in Grub.
Actually, what I miss in Grub is some characters like / ( ) = " ' < > :
; . & (I don't write texts in Grub :)   )

I mean, we could:
a) do nothing (worst option?)

b) parcial implementation (still using the char *map with different
basic layouts)

c) full implementation, like Linux console

Do you have some strong opinion about what to do? I guess that c) is
better, do we need it?

Anyway, next days I will study how the Linux keymaps are working and are
handled.

-- 
Carles Pina i Estany		GPG id: 0x17756391
	http://pinux.info

Re: [RFC] Different keyborad layouts

[Robert Millan]

On Mon, Sep 29, 2008 at 09:26:58PM +0300, Vesa Jääskeläinen wrote:
> 
> Remember that in some keyboard you need to press combos in order to
> generate some character. Like in Finnish keyboard you press alt-gr + e
> in order to generate euro sign (or alt-gr + 5). Also there are
> multi-keypress sequences like in order to make '^' this sign you have to
> press ctrl + '^' button and when released then press space. If you
> happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
> do not think this is the only keyboard with this feature. Also there is
> those dec input sequences like alt+number sequence. In example alt
> (pressed) + '6', '5' you get 'A'.

Do we really want to support all keys (and therefore all minor keyboard
variants) out there, or just those needed for metacharacters like '/' and
such?

> I do not like the idea of using variable for this as it will most likely
> require loading of keymap definition form disk. So I would prefer something:
> 
> insmod keymap
> keymap /boot/grub/keyboard/fi

Seems fine to me.  Note, however, that with the information currently exported
by e.g. at_keyboard.c it isn't possible to tell when special combinations like
"alt-gr + 5" were pressed.

There's quite a bit of pending rework for the input/output split (handlers?)
and USB keyboards (multiple input sources).  Perhaps it'd be better to address
this when the fundamentals have been laid out?

Btw, what happened to the handlers patch?  I thought it was about to be merged.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Different keyborad layouts

[Vesa Jääskeläinen]

Robert Millan wrote:

> Btw, what happened to the handlers patch?  I thought it was about to be merged.

Handlers has nothing to do with this :)

That is still pending before we get more discussion about that :)

Anyway... what you are after is multiple terminal inputs and outputs
support.

Re: [RFC] Different keyborad layouts

[Vesa Jääskeläinen]

Robert Millan wrote:
> On Mon, Sep 29, 2008 at 09:26:58PM +0300, Vesa Jääskeläinen wrote:
>> Remember that in some keyboard you need to press combos in order to
>> generate some character. Like in Finnish keyboard you press alt-gr + e
>> in order to generate euro sign (or alt-gr + 5). Also there are
>> multi-keypress sequences like in order to make '^' this sign you have to
>> press ctrl + '^' button and when released then press space. If you
>> happen to press in example 'a' after ctrl + '^' key you get 'â'. And I
>> do not think this is the only keyboard with this feature. Also there is
>> those dec input sequences like alt+number sequence. In example alt
>> (pressed) + '6', '5' you get 'A'.
> 
> Do we really want to support all keys (and therefore all minor keyboard
> variants) out there, or just those needed for metacharacters like '/' and
> such?

Probably not. But anyway... I would like simple combos to be handled
nicely. Like shift+7 (forward slash). And then if you have some weird
keyboard you should be able to generate unicode key based on some easy
way and to handle capslock + shift to make lowercase and uppercase
characters.

>> I do not like the idea of using variable for this as it will most likely
>> require loading of keymap definition form disk. So I would prefer something:
>>
>> insmod keymap
>> keymap /boot/grub/keyboard/fi
> 
> Seems fine to me.  Note, however, that with the information currently exported
> by e.g. at_keyboard.c it isn't possible to tell when special combinations like
> "alt-gr + 5" were pressed.

We need to uniform keyboard handling in way that USB and AT and bios
keyboards get handled in same path.

Now the next issue is if we have like two usb keyboards. How it should
work in grub's case is that both is listened for input.