[Pkg-kbd-devel] Re: pkg-kbd project on Alioth to maintain kdb Debian package

[Anton Zinoviev]

I am very glad for the initiative to create the pkg-kbd project.  So
far I have informed only Alastair about my work for the console data,
now we have a public mailing list so more people can be involved.
Unfortunately I was more busy that I supposed to be and fortunately
the work I wanted to do is already almost complete. :-)

Last year I promised Alastair to create a new, consistent collection
of console fonts.  This task is done.  But when I looked more closely
at the console-data package in order to see how to integrate the new
collection I was scared - this simple in nature package turned out to
be so complex! :-O

Alastair had told me that he intends to create a system that allows
the X keyboard definitions to be used on the console.  This task is
quiet difficult but necessary in order to simplify the console-data
package.  So I decided to try to create a quick and durty "X to
console" translator that could also serve as proof of the concept and
helped Alastair to implement easier his system.  This task is also
already done and tested for the "AT" keyboards.  It works better than
I had initially supposed it to work; it will allow us to configure the
keyboard together for X and for the console.

Due to lack of enough time I was unable to implement the Debian part
of all this, i.e. to do any Debian packaging.  I think it will be
easier to create a completely new package that is not based on the
current console-data.  I have no idea about what should be its name.
I have some uncertainty about how to package the keyboard part.

I will give more info in another message.  There is ready to commit
code, probably we do not need another project on Alioth and I can
commit in the SVN of pkg-kbd?

On Mon, Sep 19, 2005 at 03:21:43AM +0300, Konstantinos Margaritis wrote:
> On Κυριακή 18 Σεπτέμβριος 2005 22:43, Denis Barbier wrote:
> >   * kbd and console-tools have forked a long time ago, how to
> > include fixes from both branches?

I think from users point of view the only feature of console-tools
that is missing from kbd is the support of fallbacks tables.  For
example if the console font does not have a gliph for say "a with
diaeresis" some users will prefer to display "a" instead of "a with
diaeresis" while others will prefer say question mark.  With the kbd
package the fallback table is always embedded in the font and only way
to achieve this is to use two different fonts.  I think that this
feature is not vital so we can orphan console-tools.

>From the developers point of view console-tools is superior to kbd
because it has its own library.  Alastair wanted to do the same for
the kbd package and the upstream agreed.

> * A universal way to setup console fonts and keymaps, regardless of 
> the actual locale.

Sergey Udaltsov has discovered how to do the keyboard part, look at
/etc/X11/xkb/rules/xfree86.xml and the keyboard configurator of GNOME.
The font part is not tricky at all.

> 			* Cyrillic locales. In my understanding these
> are probably fit in the above subcategory, but I'll refrain from
> doing that statement as I'm not familiar with the actual intricacies
> of setting up the console for Cyrillic. If possible the
> console-cyrillic code should be merged into the

True.  The package console-cyrillic was created because both kbd and
console-tools did not have very involved maintainers.

> Assuming that UTF-8 is used universally, this should make things 
> easier for us actually and spare us the effort of having to handle 
> different encodings. In my opinion, I don't think we should even 
> bother to support older encodings for the console. Just go UTF-8 all 
> the way.

The kernel does not support fully UTF-8 on the console.  So far many
patches have been submitted and rejected by the kernel developers. :-)
Acording to them the kernel should stay as simple as possible, the
text mode Linux console should be used only in emergency cases (aka
single user mode) and in most cases people should use programs such as
jfbterm (even for the Latin1 languages).

Currently the CapsLock key does not work properly in UTF-8 mode.  The
Compose key also does not work.

Anton Zinoviev