Mailing List Archive

Syslinux keyboard mappings
Hi,

I finally want to end the fights we have had in the past with keyboard
mappings. I already curse the person who is responsible for this keyboard
mess (and even more the persons who could have create a 'detect keyboard'
kind of functionality in modern PCs :))

But the general problem is this, BIOSes are US qwerty, Belgium uses
be-latin1 (azerty with lots of custom keys). And to complicate the matter,
we're often logged on to Citrix and into some sort of remote java gui
console.

All of these complicate the issue (or at least do not improve it).

Now, somehow I hoped the solution would be fairly simple. Take the us.map,
take the be-latin1.map, create a be_latin.ktl out of it by running:

/usr/lib/syslinux/keytab-lilo.pl us.map be-latin1.map >be_latin1.ktl

Beware that I had to modify the default path inside the perl script and
unzip the maps that usually are zipped on my system.

Also beware that the file be-latin1.ktl will end up being be_latin1.ktl.

Now after doing this, it doesn't work. The mappings seem not to have
been changed and I even wonder whether the file is being used or it isn't
supposed to work like this. I just refer to the file like:

kbdmap be_latin1.ktl

and it is located in /isolinux/be_latin1.ktl

Now, is this supposed to work like this or is there some other mapping
causing havoc (like citrix ot the java gui) and is there any chance we can
debug if the file is being read ?

We talked to HP about this and they're official answer to this is that
they only support a setup where the keyboard is consistently configured
over the complete line. But this for us is impossible in the sense that
before booting the operating system (or setup utility) the keyboard by
default is us (so we have to configure the local system and remote citrix
and java gui to us as well) and once we have started the anaconda process
I have to remap all those instance to be-latin1 (belgian).

This seems pretty silly and makes it impossible to use the commandline
(because some numbers eg 2, 7 and necessary characters eg :, = are NOT
mapped at all)

I'd like to have a conclusive answer so we can fix this for syslinux (and
have belgian keyboard configured everywhere). I'd like to integrate this
with footprint to create custom bootdiscs that fix this for non-us
keyboard users :)


Thanks in advance,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[.all I want is a warm bed and a kind word and unlimited power]

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.
Re: Syslinux keyboard mappings [ In reply to ]
On Thu, 23 Mar 2006, Dag Wieers wrote:

> But the general problem is this, BIOSes are US qwerty, Belgium uses
> be-latin1 (azerty with lots of custom keys). And to complicate the matter,
> we're often logged on to Citrix and into some sort of remote java gui
> console.
>
> All of these complicate the issue (or at least do not improve it).
>
> Now, somehow I hoped the solution would be fairly simple. Take the us.map,
> take the be-latin1.map, create a be_latin.ktl out of it by running:
>
> /usr/lib/syslinux/keytab-lilo.pl us.map be-latin1.map >be_latin1.ktl

Renaming this file from be_latin1.ktl to be.ktl fixed the issue (at least
now the file is being used and some of the keys map correctly).

Bbut the numbers (pressed starting from 1 to 9 and 0 holding the SHIFT, as
is required with azerty) map to this:

!@#$%§^&*()

While pressing the same row without SHIFT results in the correct
characters:

&é"'(§è!çà)-

At least the ones that us qwerty doesn't have are printing another symbol,
but that's fine. Fact is now that the numbers (when pressing SHIFT) are
not returning numbers. Effectively blocking us from typing numbers :)

Also the uppercase characters (pressing AZQW with SHIFT) are also not
mapped properly.

So I conclude that the mappings do not have any effect when you press
SHIFT. (Which disables the use of numbers on Belgian keyboards when
using kbdmap).

Can this be verified in the code ?

Kind regards,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[.all I want is a warm bed and a kind word and unlimited power]
Re: Syslinux keyboard mappings [ In reply to ]
On Thu, 23 Mar 2006, Dag Wieers wrote:

> On Thu, 23 Mar 2006, Dag Wieers wrote:
>
> > But the general problem is this, BIOSes are US qwerty, Belgium uses
> > be-latin1 (azerty with lots of custom keys). And to complicate the matter,
> > we're often logged on to Citrix and into some sort of remote java gui
> > console.
> >
> > All of these complicate the issue (or at least do not improve it).
> >
> > Now, somehow I hoped the solution would be fairly simple. Take the us.map,
> > take the be-latin1.map, create a be_latin.ktl out of it by running:
> >
> > /usr/lib/syslinux/keytab-lilo.pl us.map be-latin1.map >be_latin1.ktl
>
> Renaming this file from be_latin1.ktl to be.ktl fixed the issue (at least
> now the file is being used and some of the keys map correctly).
>
> Bbut the numbers (pressed starting from 1 to 9 and 0 holding the SHIFT, as
> is required with azerty) map to this:
>
> !@#$%§^&*()
>
> While pressing the same row without SHIFT results in the correct
> characters:
>
> &é"'(§è!çà)-
>
> At least the ones that us qwerty doesn't have are printing another symbol,
> but that's fine. Fact is now that the numbers (when pressing SHIFT) are
> not returning numbers. Effectively blocking us from typing numbers :)
>
> Also the uppercase characters (pressing AZQW with SHIFT) are also not
> mapped properly.
>
> So I conclude that the mappings do not have any effect when you press
> SHIFT. (Which disables the use of numbers on Belgian keyboards when
> using kbdmap).
>
> Can this be verified in the code ?

"Of course not.", he answered to himself.

The problem is in the keytab-lilo.pl script. The output it generates is
missing the correct mappings when the shift-key is pressed.

I have been entering them in a hex editor and constructed the following
file for a be-latin1 keyboard. (1 key I mapped differently because we
would lack the ~ sign)

And now everything works as expected. If someone competent can fix this
(the keytab-lilo code looks a bit ugly to me) I'd appreciate it.
You can use the supplied be.ktl file to verify if the new output matches
this file for be-latin1.map

Maybe something for the syslinux TODO so someone can find it there ?

That said, the keys that require the ALT key do not seem to generate a
scancode and therefor cannot be produced.

Kind regards,
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
[.all I want is a warm bed and a kind word and unlimited power]