> > The label is what is printed on the key. That is, it is kind of an
> > abstracted scancode. The symbol is what the key is supposed to produce,
> > given the current modifier setup.

> "is supposed to": isn't it a libgii issue rather than an input-driver one?

No - it is IMHO an issue of the operating system keyboard drivers.

They already do what has to be done, as they have to provide cooked 
input to the tty layer anyway.

> This was the last remark in my post, why should the input-driver take care
> of the status of the modifiers to return the symbol? 

No - actually it should receive both symbol and label from the kernel. 
That's how it would be in a sane system. Everything else is a workaround 
to cope with existing interfaces.

> At the input-driver level, I would have imagined something really 
> straighforward (like for games) and that libgii would do the label 
> --> symbol conversion depending on the keyboard layout (French, UK, US...).

Where would it get that info, and worse, how would it know, if someone has 
configured his keyboard in a nonstandard way.

This is why we query the kernel keymaps in the Linux case. To make sure 
the keyboard behaves like it always does.

Same for X. Some map Delete to the Del Key, some Erase, ... if they 
configured it, they want it this way and not use yet another ggiloadkeys
or something.

> > Those that expect textual input from the keyboard (like when entering data
> Isn't it the libgii job?

No. It's the input sources job.

IMHO this mapping should be done in a central place once and only once and 
be relayed to the rest of the world as appropriate. There exist whole Howtos
for Linux about getting the console and X keymaps in sync - I'd rather like
to avoid adding another howto on how to sync them with GGI as well.

If at all possible, read them from the kernel.

If it proves necessary, we can add a generic mapping layer to LibGII
(I've designed such code for other projects, so it would be pretty quick 
 to make something up), but I'd really like to avoid that.

CU, Andy

-- 
Andreas Beck              |  Email :  <[EMAIL PROTECTED]>

Reply via email to