Keyboard tables with string definitions and diacriticals

Tue Aug 2 00:11:33 UTC 2011

 Hi all,

after a long delay (from end of March) ... and sorry for this delay, I
had been unexpectedly busy ... I'm going to pick up that keyboard stuff ...

On 27.03.2011 18:29, Denys Vlasenko wrote:
> On Sunday 27 March 2011 16:53, Harald Becker wrote:
>>> I think implementing loadkeys is a better solution.
>> What about implementing a separate loadkeys applet, that is based on the
>> "-b" option. That is: Parsing the ASCII key table and writing a binary
>> keyboard table on stdout. After doing some extension to loadkmap that
>> could be used in a modular and compatible fashion (internally loadkeys
>> always works in that two step fashion, only without the pipe).
>>
>> loadkeys -b KEYBOARD_DEFINITION | loadkmap
>>
>> For those purposes where the ASCII table parser is to be excluded the
>> loadkeys applet can be disabled in the configuration. That leaves
>> Busybox at the current usage level:
>>
>> loadkmap <BINARY_KEY_TABLE
>>
>> or
>>
>> zcat BINARY_KEY_TABLE_GZ | loadkmap
>>
>> What about that type of solution?
> Looks good to me.

Meanwhile there had been several discussions (in German) with Bernhard
Treutwein about converting keymaps files (the loadkeys format) to the
GRUB keyboard table format. As an extension of the idea above, we have
come to an even more modular solution which is now at the state where
I'm looking back to the needs of Busybox to continue / finish the
discussion / work I started at that topic.

Currently I do have a (yet separate) keymaps2keylist parser. This parser
reads keymaps files in the way loadkeys does (honoring all includes and
search path). On output it writes a simple textual representation of the
keymaps file, with one key definition per line in a format suitable for
further processing with Awk scripts (one key entry looks like "K keynum
modnum keycode_or_symbol", e.g. "K 1 2 Escape" for key #1, modifier
#2=AltGr). With some relatively simple Awk scripts and textual Tables
those keylists get converted into the key numbers and codes GRUB uses. A
trivial C program reads in the textual keylist representation and
outputs a binary GRUB key table.

GRUB isn't Busybox and uses a completly different format but beside this
a slightly modified Awk script and a really simple converter program is
all needed to output Busybox kmap files from any valid keymaps file.
This is the current state of development and I'm now going to look
deeper at the Busybox kmap format.

The Busybox kmap format is currently:

- a seven byte magic "bkeymap"
- a 256 byte (MAX_KEYMAP) table
  0x01 if the corresponding key map is used otherwise 0x00
- for every used keymap an array of 128 (NR_KEYS) 16bit integers
  those integers are the key codes to be bond to the corresponding keys

To this my "loadkeys -b" appends a string like: "Loading
/usr/share/keymaps/i386/qwertz/de-latin1.map.gz\n" ... but this string
is never read by Busybox.

That's all of the current kmap format ... but this is limited in several
ways:

- It does not allow for function key string definitions.
- It does not allow for compose key definitions (diacriticals).
- It does not honor newer Linux kernels which allow up to 256 keys,
where the keys above 127 are used for the special functions on modern
multi functional keyboards or notebooks.

Hence the current Busybox kmap  format needs modification, which affect
the applets dumpkmap, loadkmap and every binary keymap stored in that
format. This modification can be done in at least three ways:

1) Append a string and a compose definition table to the current kmap
format. This will give some compatibility, as older versions of Busybox
will just ignore those extended tables and newer versions can stop
reading if the extended tables are not present. This would be the most
compatible way but still neglects to allow for Linux keys 128..255.

2) We can radically modify the binary kmap format to allow for a
variable number of key maps with variable number of keys, plus string
definitions, plus compose key definitions. This will break compatibility
with older versions of Busybox. Beside this the conversion of old kmap
files is possible and not much work to be done.

3) We can drop the Busybox binary kmap format completely and modify
loadkmap, dumpkmap to read/write directly the textual keylist format (or
any alike). This keylist format needs only primitive parsing (example
keylist2grub.c appended) and has no such limits as any binary format.
The keylist format does not need a fully fledged parser as the loadkeys
keymaps format but still increases the size of Busybox. Using the
keymaps2keylist parser (which shall be made into a Busybox applet) in a
pipe it would be possible to load every keymaps definition file.

At the current I need a decision which one of the three ways Busybox
wants to go (or is there any other way?). After this decision I'm able
to proceed into the required work.

The keymaps2keylist parser is currently a single C source file with only
one critical dependency (/linux/keyboard.h). It compiles to a binary of
about 13k on my x86 (gcc -Os).
Current pre releases of the parser and example Awk scripts (conversion
to GRUB) are available on request. I won't swamp the mailing list
without having asked.

May be sugar: I had a short look on the FreeBSD keymap format and it
would be possible to write a parallel bsdkey2keylist which allows to
load key definition files of FreeBSD. All I need to do that job would be
some example keymap files in BSD format for testing purposes.

In addition I'm thinking of direct conversion of X11 key maps to the
keylist format. Currently this is possible using ckbcomp (a Perl script)
and keymaps2keylist. The direct conversion is a possible future
extension to eliminate the need of Perl.

--
Harald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keylist2grub.c
Type: text/x-c
Size: 1465 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20110802/c5617c29/attachment.c>