Keymap definitions for VT / NEWCONS

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Keymap definitions for VT / NEWCONS

Stefan Eßer
Hi Aleksandr,

I have converted quite a number of the SYSCONS keymaps to NEWCONS
format, using your script (uakbd2ukbd.pl).

Many conversions lead to identical files for NEWCONS, some had a
just a few replaced characters (e.g. Turkish or Brasilian keymaps).

I verified quite a number of single characters using web resources
(e.g. http://www.decodeunicode.org/ and keyboard layout images at
http://http://ascii-table.com/keyboard.php/275 - replace number at
the end for other locales).

When there were different source encodings (e.g. German ISO8859-1
and CP850), I compared those too - the results should have been
identical. In fact, there were minor changes and the version that
had been converted from ISO was better than the one from CP850,
with the exception of a single shifted key.


I want to commit the conversion results to share/vt/keymaps, if
you don't mind. In a first step, I want to commit those keymaps
that I think are correct (either because they are identical to the
SYSCONS keymaps, or because I checked them against web resources).

I did not know how to deal with Dvorak keymaps (especially since
they are not named according to the encoding used for SYSCONS),
they can come later.

These keymaps should be committed in time for 10.1, since NEWCONS
is in GENERIC and people will expect them.

When these maps are committed to -CURRENT, I can remove the hack
that made kbdcontrol lookup keymaps under share/syscons/keymaps
as a fall-back. This hack will not be merged to 10-STABLE ...


One minor point: I want to commit the keymaps under names that
just consist of the country code and ".kbd" (e.g. "us.kbd"), since
only Unicode encoding is supported/required.

Keyboards with accented characters will be named like "us.acc.kbd".

I'm planning to commit the keymap files that I have on Thursday,
if there are no objections.

Regards, STefan

PS: I have the keymaps that are ready to commit uploaded to:
    http://people.freebsd.org/~se/vt-keymaps.tar.bz2
    (This file includes the 3 sample keymaps that already are
     in SVN since I did not exclude them when tarring ...)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Andrey V. Elsukov-2
On 12.08.2014 16:55, Stefan Esser wrote:
> I'm planning to commit the keymap files that I have on Thursday,
> if there are no objections.
>
> Regards, STefan
>
> PS: I have the keymaps that are ready to commit uploaded to:
>     http://people.freebsd.org/~se/vt-keymaps.tar.bz2
>     (This file includes the 3 sample keymaps that already are
>      in SVN since I did not exclude them when tarring ...)

Hi,

I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected.

--
WBR, Andrey V. Elsukov
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
Am 12.08.2014 um 16:02 schrieb Andrey V. Elsukov:

> On 12.08.2014 16:55, Stefan Esser wrote:
>> I'm planning to commit the keymap files that I have on Thursday,
>> if there are no objections.
>>
>> Regards, STefan
>>
>> PS: I have the keymaps that are ready to commit uploaded to:
>>     http://people.freebsd.org/~se/vt-keymaps.tar.bz2
>>     (This file includes the 3 sample keymaps that already are
>>      in SVN since I did not exclude them when tarring ...)
>
> Hi,
>
> I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected.

The KOI8-R and KOI8-U keymaps are among those that I tried
to convert.

But I do not know which of the 5 variants are relevant:

- ru.cp866.kbd
- ru.iso5.kbd
- ru.koi8-r.kbd
- ru.koi8-r.shift.kbd
- ru.koi8-r.win.kbd

For example "ru.koi8-r.kbd" and "ru.koi8-r.shift.kbd" differ
only in that the ".shift" version has the digits on shifted
key positions. The ".shift" and ".win" keymaps are quite
similar, except for Shift-3, Shift-5..7 and a few control
and function keys.

I guess there will be 3 converted maps, that are actually
needed, all derived from KOI8-R encoded files:

- ru.kbd
- ru.win.kbd
- ru.shift.kbd

This is my list of converted keymaps I'm ready to commit:

be.acc.kbd
be.kbd
br275.acc.kbd
br275.kbd
by.kbd
ce.kbd
colemak.acc.kbd
danish.acc.kbd
danish.kbd
danish.macbook.kbd
dutch.acc.kbd
estonian.kbd
finnish.kbd
fr.acc.kbd
fr.kbd
fr_CA.acc.kbd
german.acc.kbd
german.kbd
hr.kbd
icelandic.acc.kbd
icelandic.kbd
it.kbd
jp.pc98.kbd
latinamerican.acc.kbd
lt.kbd
norwegian.kbd
pt.acc.kbd
pt.kbd
si.kbd
spanish.acc.kbd
spanish.kbd
swedish.kbd
swissfrench.acc.kbd
swissfrench.kbd
swissgerman.acc.kbd
swissgerman.kbd
tr.kbd
uk.kbd
us.acc.kbd
us.kbd

Regards, STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
On 12 August 2014 11:04, Stefan Esser <[hidden email]> wrote:
> This is my list of converted keymaps I'm ready to commit:
...
> danish.acc.kbd
> danish.kbd

I wonder if we should use this opportunity to rationalize the keyboard
layout names, using two letter codes consistently (so dk.kbd).  This
would also bring consistency with the X11 keyboard layout codes.

We'll already have some churn in rc.conf settings related to screen
maps / fonts, so this may not be too much of a burden.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Oliver Pinter (Pintér Olivér)
In reply to this post by Stefan Eßer
On 8/12/14, Stefan Esser <[hidden email]> wrote:

> Am 12.08.2014 um 16:02 schrieb Andrey V. Elsukov:
>> On 12.08.2014 16:55, Stefan Esser wrote:
>>> I'm planning to commit the keymap files that I have on Thursday,
>>> if there are no objections.
>>>
>>> Regards, STefan
>>>
>>> PS: I have the keymaps that are ready to commit uploaded to:
>>>     http://people.freebsd.org/~se/vt-keymaps.tar.bz2
>>>     (This file includes the 3 sample keymaps that already are
>>>      in SVN since I did not exclude them when tarring ...)
>>
>> Hi,
>>
>> I tried converted keymap from ru.koi8-r.win.kbd, seems work as expected.
>
> The KOI8-R and KOI8-U keymaps are among those that I tried
> to convert.
>
> But I do not know which of the 5 variants are relevant:
>
> - ru.cp866.kbd
> - ru.iso5.kbd
> - ru.koi8-r.kbd
> - ru.koi8-r.shift.kbd
> - ru.koi8-r.win.kbd
>
> For example "ru.koi8-r.kbd" and "ru.koi8-r.shift.kbd" differ
> only in that the ".shift" version has the digits on shifted
> key positions. The ".shift" and ".win" keymaps are quite
> similar, except for Shift-3, Shift-5..7 and a few control
> and function keys.
>
> I guess there will be 3 converted maps, that are actually
> needed, all derived from KOI8-R encoded files:
>
> - ru.kbd
> - ru.win.kbd
> - ru.shift.kbd
>
> This is my list of converted keymaps I'm ready to commit:
>
> be.acc.kbd
> be.kbd
> br275.acc.kbd
> br275.kbd
> by.kbd
> ce.kbd
> colemak.acc.kbd
> danish.acc.kbd
> danish.kbd
> danish.macbook.kbd
> dutch.acc.kbd
> estonian.kbd
> finnish.kbd
> fr.acc.kbd
> fr.kbd
> fr_CA.acc.kbd
> german.acc.kbd
> german.kbd
> hr.kbd
> icelandic.acc.kbd
> icelandic.kbd
> it.kbd
> jp.pc98.kbd
> latinamerican.acc.kbd
> lt.kbd
> norwegian.kbd
> pt.acc.kbd
> pt.kbd
> si.kbd
> spanish.acc.kbd
> spanish.kbd
> swedish.kbd
> swissfrench.acc.kbd
> swissfrench.kbd
> swissgerman.acc.kbd
> swissgerman.kbd
> tr.kbd
> uk.kbd
> us.acc.kbd
> us.kbd
>
> Regards, STefan

Hi!

I like to see the us.pc-crtrl.kbd too in this list. How can I convert
this in fastest way?

> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
On 12 August 2014 13:57, Oliver Pinter <[hidden email]> wrote:
>
> Hi!
>
> I like to see the us.pc-crtrl.kbd too in this list. How can I convert
> this in fastest way?

It doesn't have any code points >= 128 so no conversion is necessary -
it should work as-is.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Oliver Pinter (Pintér Olivér)
On 8/12/14, Ed Maste <[hidden email]> wrote:

> On 12 August 2014 13:57, Oliver Pinter <[hidden email]> wrote:
>>
>> Hi!
>>
>> I like to see the us.pc-crtrl.kbd too in this list. How can I convert
>> this in fastest way?
>
> It doesn't have any code points >= 128 so no conversion is necessary -
> it should work as-is.
>

Okay! Thanks the quick answer.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
In reply to this post by Ed Maste-2
Am 12.08.2014 um 19:40 schrieb Ed Maste:
> On 12 August 2014 11:04, Stefan Esser <[hidden email]> wrote:
>> This is my list of converted keymaps I'm ready to commit:
> ...
>> danish.acc.kbd
>> danish.kbd
>
> I wonder if we should use this opportunity to rationalize the keyboard
> layout names, using two letter codes consistently (so dk.kbd).  This
> would also bring consistency with the X11 keyboard layout codes.

Yes, one of the reasons that I did not commit the converted keymaps
as they currently are is naming. I left the old names (without .iso.)
to simplify comparisons, but wanted to normalize them before commit.

I have renamed the files to 2-character ISO country code names, and
have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd")
where there are several locales within a country.

Unresolved:

- Shall keymap names for countries where language and country are
  identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"?
  (I'd say yes ...)

- In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd".
  * Do we want to add "ch.kbd", too?
  * Should it be a symlink to one of the other keymap files (the
    majority of the Swiss population would use de_CH, I guess)
  * What in the case of "pt_PT.kbd" above - shall there also be a
    symlink named "pt.kbd"?

- What shall we do with keymaps like "latinamerican.kbd"?
  We could install it under one name and symlink (or link) all
  the other relevant locale names to this name.

I could use the list of supported locales under share/locale (sans
the encoding suffix) as a minimum list of keyboards to support.

That would imply, that for every locale selected by a user, there
is a matching default keyboard.

What do you think about this?


(I'm going to upload a new TAR file with the modified names, after
some further changes have been performed: The comments in the
keymap files often refer to encodings, that have no meaning after
the conversion to Unicode ...)


And after all these normalizations have been performed:

- How do we deal with accented versions of keymaps?
  (Those with ".acc." in their names ...)

- Do we keep all those variants that only differe in the handling
  of the Caps-Lock key (which often is mapped to an additional
  Control key)?

> We'll already have some churn in rc.conf settings related to screen
> maps / fonts, so this may not be too much of a burden.

Since the names will change anyway (because of the removal of the
encoding, in case NEWCONS is selected), this will not really hurt
us.

I could imagine a mapping file or script, which converts the name
of the keymap from a SYSCONS name to a NEWCONS name. That script
could be used to advise the user to modify rc.conf, or it could
(for the lifetime of 10.x) be invoked from the keymap set script
in rc.d when kbdcontrol failed to set a keymap based on the "old"
name.

Opinions?

Regards, STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Tom Evans-3
On Wed, Aug 13, 2014 at 8:02 AM, Stefan Esser <[hidden email]> wrote:
> - What shall we do with keymaps like "latinamerican.kbd"?
>   We could install it under one name and symlink (or link) all
>   the other relevant locale names to this name.
>

Thank you for doing this work Stefan!

Facebook (and a few others from what I can tell) are using es_LA for
Latin America (it should be Laos Spanish really) and ar_AR for a
generic Arabic.

Cheers

Tom
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
Am 13.08.2014 um 11:51 schrieb Tom Evans:

> On Wed, Aug 13, 2014 at 8:02 AM, Stefan Esser <[hidden email]> wrote:
>> - What shall we do with keymaps like "latinamerican.kbd"?
>>   We could install it under one name and symlink (or link) all
>>   the other relevant locale names to this name.
>
> Thank you for doing this work Stefan!
>
> Facebook (and a few others from what I can tell) are using es_LA for
> Latin America (it should be Laos Spanish really) and ar_AR for a
> generic Arabic.

Really?

Seems we do not have any support for Arabic locales, neither
in "/usr/share/locale", nor in the form of a keymap file ...
So, we have no use for "ar_AR".

But "es_LA" might really be a good name for the many Spanish
speaking South American countries.

I propose to rename "latinamerican.kbd" to "es_LA.kbd" using
that convention, then.

Thank you for bringing these points to my attention!


If we can agree on locale-based keymap names as the rule
(with exceptions, as required), then I'd like to commit the
first round of keymap files to vt/keymaps tomorrow.

This commit will not include accented versions or other
special cases (Ctrl <-> Caps-Lock), since I think we ought
to think about naming conventions or a general concept for
these variations of default keymaps.

If a locale defaults to "deadkeys", then the default keymap
should follow suit. These keymaps are currently named with
".acc" attached to the name. But it will take too long to
converge to an optimal keymap for each affected locale ...


I guess we should follow what other systems do (MacOS or
Windows), since this is what the majority of users will
expect, anyway.

But I'm open to suggestions ... ;-)

Best regards, STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Erik Cederstrand-3
Den 12/08/2014 kl. 19.40 skrev Ed Maste <[hidden email]>:

> On 12 August 2014 11:04, Stefan Esser <[hidden email]> wrote:
>> This is my list of converted keymaps I'm ready to commit:
> ...
>> danish.acc.kbd
>> danish.kbd
>
> I wonder if we should use this opportunity to rationalize the keyboard
> layout names, using two letter codes consistently (so dk.kbd).

Sounds like a good idea. Just provide some kind of translation file instead of bailing and using a default keymap. Trying to desperately remember the default US layout just to edit rc.conf and reboot is a pain. Preferably as a warning at boot time like 'keymap "danish.iso.kbd" is deprecated. The new name is "da_DK.kbd". Please edit /etc/rc.conf'.

Thanks,
Erik
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
In reply to this post by Stefan Eßer
On 13 August 2014 03:02, Stefan Esser <[hidden email]> wrote:
>
> I have renamed the files to 2-character ISO country code names, and
> have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd")
> where there are several locales within a country.

This sounds good to me.

> Unresolved:
>
> - Shall keymap names for countries where language and country are
>   identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"?
>   (I'd say yes ...)

We already had ua.kbd and pl.kbd and I just now brought over the
??.iso.kbd files before catching up on this thread.  It seems
reasonable to me to use only the language code unless we need to be
more specific.

> - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd".

Sounds good to me.

>   * Do we want to add "ch.kbd", too?
>   * Should it be a symlink to one of the other keymap files (the
>     majority of the Swiss population would use de_CH, I guess)
...
> That would imply, that for every locale selected by a user, there
> is a matching default keyboard.

I wouldn't worry about this unless there's a precedent in X11 or the
Linux console.

> And after all these normalizations have been performed:
>
> - How do we deal with accented versions of keymaps?
>   (Those with ".acc." in their names ...)

I think we can just bring them over as ??.acc.kbd once we've verified
they work as expected.

> - Do we keep all those variants that only differe in the handling
>   of the Caps-Lock key (which often is mapped to an additional
>   Control key)?

I don't see why not.

Oh, one other point: I'll add a stripped-down share/vt/INDEX.keymaps
shortly, and we can add new entries there as we bring the keymaps
over.  We'll also need UTF-8 encoded translations of the names.

-Ed
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
In reply to this post by Erik Cederstrand-3
On 13 August 2014 09:47, Erik Cederstrand <[hidden email]> wrote:
>>
>> I wonder if we should use this opportunity to rationalize the keyboard
>> layout names, using two letter codes consistently (so dk.kbd).
>
> Sounds like a good idea. Just provide some kind of translation file instead of bailing and using a default keymap. Trying to desperately remember the default US layout just to edit rc.conf and reboot is a pain. Preferably as a warning at boot time like 'keymap "danish.iso.kbd" is deprecated. The new name is "da_DK.kbd". Please edit /etc/rc.conf'.

Yeah, that's important.  It should be straightforward for us to
identify an old keymap variable (test that sysctl kern.vty=vt and that
/usr/share/vt/keymaps/${keymap} does not exist), and then just have a
big switch statement of old and new names.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
In reply to this post by Ed Maste-2
Am 13.08.2014 um 22:31 schrieb Ed Maste:

> On 13 August 2014 03:02, Stefan Esser <[hidden email]> wrote:
>>
>> I have renamed the files to 2-character ISO country code names, and
>> have used the form "fr_CH.kbd" (instead of "swisscfrench.iso.kbd")
>> where there are several locales within a country.
>
> This sounds good to me.
>
>> Unresolved:
>>
>> - Shall keymap names for countries where language and country are
>>   identical (e.g. "pt.kbd") be converted to "pt_PT.kbd"?
>>   (I'd say yes ...)
>
> We already had ua.kbd and pl.kbd and I just now brought over the
> ??.iso.kbd files before catching up on this thread.  It seems

:( :(

I had announced that I was waiting for feedback until Thursday
before I wanted to commit what I have prepared.

I have spent many hours converting keymaps (not only the trivial
ones, which are identical in ISO8859-1 and UTF-8), and I'm really
annoyed!

> reasonable to me to use only the language code unless we need to be
> more specific.

I wanted to have consensus on this before we start committing
keymap files.

And I think it is better to use locale names in any case. The
selection logic has to be there for locales, why complicate
matters by introducing 2-letter names, which in fact match
the 2nd half of a locale name when country code and language
code don't match (as in "en_US.kbd" vs "us.kbd").

I think we should provide keymap files under the same names
as the locale names (less the encoding).

We'll need a mapping file (like "INDEX.keymaps" for syscons),
I assume.

But I'm not sure about all these points ...

>> - In the example of Switzerland, "swissgerman.kbd" becomes "de_CH.kbd".
>
> Sounds good to me.
>
>>   * Do we want to add "ch.kbd", too?
>>   * Should it be a symlink to one of the other keymap files (the
>>     majority of the Swiss population would use de_CH, I guess)
> ...
>> That would imply, that for every locale selected by a user, there
>> is a matching default keyboard.
>
> I wouldn't worry about this unless there's a precedent in X11 or the
> Linux console.

Well, I do not think that a locale is complete without a keymap,
even though these are completely independent parts of the system
(locale handling vs. keymaps). But I'd expect that a keymap exists,
if a locale is supported and vice versa.

>> And after all these normalizations have been performed:
>>
>> - How do we deal with accented versions of keymaps?
>>   (Those with ".acc." in their names ...)
>
> I think we can just bring them over as ??.acc.kbd once we've verified
> they work as expected.

The keymap names are not consistent, as it is now. If we agree,
that names without ".acc." are "nodeadkey" variants and with
".acc." have dead keys for accents and the like, then for some
locales the ".acc." version will be "normal" and expected by
users, while its the plain version for other locales.

That's why I suggested to follow some other system (e.g. Windows)
use of accent keys / dead keys. Users in the respective locales
will know and expect the keyboard to behave just this way.

Special keyboards (e.g. Dvorak layouts) do obviously need special
keymap files (with .dvorak. inserted). But for the typical PC
keyboard used today, I'd hope for the same behaviour as under
Windows (not claiming that it is correct, just that it is
expected).

>> - Do we keep all those variants that only differe in the handling
>>   of the Caps-Lock key (which often is mapped to an additional
>>   Control key)?
>
> I don't see why not.
>
> Oh, one other point: I'll add a stripped-down share/vt/INDEX.keymaps
> shortly, and we can add new entries there as we bring the keymaps
> over.  We'll also need UTF-8 encoded translations of the names.

I really want to have a concept on what the keymap names shall be
and how they are selected (in rc.conf and in the installer).

And it is really annoying to see my efforts wasted! :(

STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
On 13 August 2014 18:59, Stefan Esser <[hidden email]> wrote:
>
> And I think it is better to use locale names in any case. The
> selection logic has to be there for locales, why complicate
> matters by introducing 2-letter names, which in fact match
> the 2nd half of a locale name when country code and language
> code don't match (as in "en_US.kbd" vs "us.kbd").
>
> I think we should provide keymap files under the same names
> as the locale names (less the encoding).

But there isn't a 1:1 mapping between locales and keyboard maps, since
we have to deal with some special cases (like dvorak).  We should let
the end user independently choose the language (for interacting with
the installer), keymap, and locale anyway, even though in most cases
there is a straightforward mapping between them.  So I don't think it
makes much difference if we have a keymap called fr.kbd for example,
or a different name.

> We'll need a mapping file (like "INDEX.keymaps" for syscons),
> I assume.

I wouldn't necessarily call INDEX.keymaps a mapping file; it's just
used for the menu-driven keymap selection.  I think we can use the
exact same scheme and file format for vt(4).

> The keymap names are not consistent, as it is now. If we agree,
> that names without ".acc." are "nodeadkey" variants and with
> ".acc." have dead keys for accents and the like, then for some
> locales the ".acc." version will be "normal" and expected by
> users, while its the plain version for other locales.

Are you proposing that we have a combination of *.kbd, *.acc.kbd, and
*.nodeadkey.kbd variants, depending on which type is the common /
expected case for various layouts?

> That's why I suggested to follow some other system (e.g. Windows)
> use of accent keys / dead keys. Users in the respective locales
> will know and expect the keyboard to behave just this way.

I think it's important to make a distinction between the way the user
selects a keymap, and the filename.  In the common case I think users
will choose a layout from a menu, and won't necessarily see or care
about the filename.  I'm not sure what contemporary Windows versions
do with respect to keyboard selection - can you describe the process
it uses?

> And it is really annoying to see my efforts wasted! :(

I don't think any of your effort is wasted -- my commit was just an
svn copy of the 8 trivial kbd files, as I thought you were working
only on the keymap files needing conversion for Unicode.  Anyhow,
changing the naming scheme (if we want to do that) isn't a big deal.
We'd have to deal with pl.kbd and ua.kbd already.

-Ed
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
Am 14.08.2014 um 05:14 schrieb Ed Maste:

> On 13 August 2014 18:59, Stefan Esser <[hidden email]> wrote:
>>
>> And I think it is better to use locale names in any case. The
>> selection logic has to be there for locales, why complicate
>> matters by introducing 2-letter names, which in fact match
>> the 2nd half of a locale name when country code and language
>> code don't match (as in "en_US.kbd" vs "us.kbd").
>>
>> I think we should provide keymap files under the same names
>> as the locale names (less the encoding).
>
> But there isn't a 1:1 mapping between locales and keyboard maps, since
> we have to deal with some special cases (like dvorak).  We should let
> the end user independently choose the language (for interacting with
> the installer), keymap, and locale anyway, even though in most cases
> there is a straightforward mapping between them.  So I don't think it
> makes much difference if we have a keymap called fr.kbd for example,
> or a different name.

There probably won't be a 1:1 mapping for all cases, but I think
that there is value in going for a regular naming scheme.

We can use "fr.kbd" as a short form of "fr_FR.kbd", but there
will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in
the short form will correspond to the "FR" in "fr_FR.kbd",
which is hidden by the fact, that both parts read "fr".

But look at "uk_UA.kbd", which will be short-named as "ua.kbd",
or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to
"be.kbd".

For some language/country combinations, the short form ends up
in a distant location to the long form names.

And will there be a "ch.kbd" for "de_CH.kbd" (the majority of
Swiss users will use that keymap), or will they all be of the
form "??_CH.kbd" ... ???

For all these reasons I think the short form serves no real
purpose. If you want to support it, you could symlink a short
name to the locale based name (to allow the use of just the
country code, if people edit rc.conf by hand, while I'd expect
the installer to use the locale based keyboard names).

>> We'll need a mapping file (like "INDEX.keymaps" for syscons),
>> I assume.
>
> I wouldn't necessarily call INDEX.keymaps a mapping file; it's just
> used for the menu-driven keymap selection.  I think we can use the
> exact same scheme and file format for vt(4).

Yes, I know its purpose and I agree, that the format should be
usable for NEWCONS keymaps, too. We'd just need to teach it
about the two supported drivers and make it select the correct
path for SYSCONS vs. NEWCONS (based on the sysctl).

I think this should be implemented in time for 10.1, if at
all possible.

Changes required are:

- Selection of NEWCONS/SYSCONS pathes and defaults:
  * DEFAULT_KEYMAP_DIR
  * DEFAULT_FONT_DIR
  * DEFAULT_FONT
  * DEFAULT_LANG


We may want to introduce a new rc.conf variable for NEWCONS,
since the format has changed (e.g. no ".iso." in names).

That way, a mapping script could suggest a suitable keymap
for NEWCONS, if running under NEWCONS and only a SYSCONS
keymap has been defined.

And that way, you could reboot into SYSCONS in case of
problems with NEWCONS and still have your SYSCONS keymap
defined (under the old rc.conf variable name).

>> The keymap names are not consistent, as it is now. If we agree,
>> that names without ".acc." are "nodeadkey" variants and with
>> ".acc." have dead keys for accents and the like, then for some
>> locales the ".acc." version will be "normal" and expected by
>> users, while its the plain version for other locales.
>
> Are you proposing that we have a combination of *.kbd, *.acc.kbd, and
> *.nodeadkey.kbd variants, depending on which type is the common /
> expected case for various layouts?

I'd think it was best, if we had a common keymap under the
name of the locale (e.g. "en_US.kbd").

This keymap should work as expected by users, which in case
of e.g. the German keyboard means, that a few accents are
deadkeys, while most keys are of the "nodeadkeys" variant.

E.g. ^ on my keyboard is used as an accent and needs a
blank typed after it to appear on its own, while ~ is not
considered an accent, but a "normal" character. (And ´ and
` are accents, while ° and ' are characters.)

On the Swiss-German keymap, other characters are expected
to work as accents or just as characters.

A nodeadkeys variant makes no sense in Switzerland, while
it might be of use in Germany (where the accents are only
used to write foreign names and the like).

>> That's why I suggested to follow some other system (e.g. Windows)
>> use of accent keys / dead keys. Users in the respective locales
>> will know and expect the keyboard to behave just this way.
>
> I think it's important to make a distinction between the way the user
> selects a keymap, and the filename.  In the common case I think users
> will choose a layout from a menu, and won't necessarily see or care
> about the filename.  I'm not sure what contemporary Windows versions
> do with respect to keyboard selection - can you describe the process
> it uses?

The selection is automatic when you install windows. You'll
be asked for the language and the country, and while not
being displayed, the selection of the keyboard follows the
locale selection.

You can switch keyboards, e.g. on a Swiss notebook between
de_CH and fr_CH. But the keyboard selection tool does not
show the locale in that form, instead it only shows the
language part (assuming that the country is known).

Staying with the example of the Swiss notebook, I get the
choice between "DE" and "FR" keyboards.

Only if I select the option to also display text labels,
these two variants are named "DE Deutsch (Schweiz)" and
"FR Französisch (Schweiz)" (the output locale is "German"
in both cases, leading to the display of "Französisch"
instead of a locale description in French).

If you want to add an alternate keyboard layout, your
choices are sorted by language, not by country. E.g. on
above mentioned Swiss notebook, invoking the "Add Language"
option of the keyboard selection utility places me in the
scroll area on "Deutsch (Schweiz)" with "Deutsch (Östereich)"
above and "Divehi (Malediven)" below ...

I'd have thought, that the sorting by country and then by
language was more reasonable, but the list is sorted in the
same way as in the MS-Office language option for the spell-
checker, for example.

This Windows tool provides a similar function our language
selection tool. After selecting a locale (language,country),
a button list is displayed, which allows to select between
one or more layouts for that locale.

In the case of "English (USA)" the layouts start with
"English (USA, Dvorak, left-handed)" and "English (USA,
Dvorak, right-handed)" and continue to "English (USA,
international)" and "US".

There is no choice of deadkeys vs. nodeadkeys variant
for any of the keymaps I looked at, but there appear to
be variants with regard to "Shift-Lock" or "Caps-Lock"
for a few locales.

And there are further specialties, like "Spanish" which
exists in "international" and "traditional" layouts.

This all looks very similar to a tuple of language and
country (while locales are country_LANGUAGE) with optional
modifiers for specific layouts (like our ".dvorak." in
keymap names).

>> And it is really annoying to see my efforts wasted! :(
>
> I don't think any of your effort is wasted -- my commit was just an
> svn copy of the 8 trivial kbd files, as I thought you were working
> only on the keymap files needing conversion for Unicode.  Anyhow,
> changing the naming scheme (if we want to do that) isn't a big deal.
> We'd have to deal with pl.kbd and ua.kbd already.

Sorry, it was late at night and I really have spent quite
some time on the conversion of keymap files. Your commits
do no harm, although I had prefered to have agreement on
the naming of keymap files. And I still strongly prefer
names that are identical to locale names, wherever possible.

Most users will either use the installer (and will thus
never see the locale IDs), or they'll manually edit rc.conf
and will know their way. And then it's easier to mechanically
put the locale ID in to the keyboard selection variable,
instead of thinking about (or looking up) whether this is
a country that does not need the full locale ID to select
a keymap. In Europe, you'll often need the locale name,
not only the country.

If you really think that the 2-character ISO country codes
should be available as a short-hand, than I'd really want
to install the keymap under the locale name and only add
a symlink from the country name.


Regarding the files you committed:

I had edited all files, including those that do not generate
different codes when converted to Unicode, at least in so
far as I have removed misleading comments (e.g. claiming that
the encoding was ISO5589-*, when Unicode is now universally
used).

I really think we'll regret using anything but locale names
for keymaps, and I'd want to rename those that you committed
under 2-letter ISO names. Is that acceptable to you?

Regards, STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Ed Maste-2
On 14 August 2014 08:21, Stefan Esser <[hidden email]> wrote:
> There probably won't be a 1:1 mapping for all cases, but I think
> that there is value in going for a regular naming scheme.
>
> We can use "fr.kbd" as a short form of "fr_FR.kbd", but there
> will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in
> the short form will correspond to the "FR" in "fr_FR.kbd",
> which is hidden by the fact, that both parts read "fr".

I agree that consistency is a useful overall goal, and I don't have a
very strong preference for the short names, it just seems to me to map
well to what it seems users actually call the keyboard layouts.
French, Swiss French, and French Canadian keyboard layouts in these
three cases. Also, Linux console setting seems to generally use
2-letter names as far as I can tell.

Would every locale we support have either a file or symlink?  Or only
a subset, roughly equivalent to what's provided by the syscons keymaps
today?

> But look at "uk_UA.kbd", which will be short-named as "ua.kbd",
> or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to
> "be.kbd".
>
> For some language/country combinations, the short form ends up
> in a distant location to the long form names.

But I expect most users would choose from a menu without seeing the
underlying keymap filename anyway, so I don't think this matters much.

> And will there be a "ch.kbd" for "de_CH.kbd" (the majority of
> Swiss users will use that keymap), or will they all be of the
> form "??_CH.kbd" ... ???

I would assume ??_CH.kbd since I suspect users would generally not
refer to a "Swiss" keyboard layout, but rather a "Swiss German" or
"Swiss French" layout.  (I'm happy to be corrected if wrong.)

> For all these reasons I think the short form serves no real
> purpose. If you want to support it, you could symlink a short
> name to the locale based name (to allow the use of just the
> country code, if people edit rc.conf by hand, while I'd expect
> the installer to use the locale based keyboard names).

If we do end up with locale names I don't think there's much value in
having short name symlinks.  It's just another level of indirection
that needs to be kept up to date.

> I think this should be implemented in time for 10.1, if at
> all possible.

Indeed, that is exactly why I wanted to move ahead with the "trivial"
cases, even if they turned out not to be so.  I'm sorry for the
conflict that caused with your work in progress.

> Most users will either use the installer (and will thus
> never see the locale IDs)

I think we agree that for these users it makes very little difference
what the keymap name actually is, since they won't see it.

> or they'll manually edit rc.conf and will know their way.

And in this case I think the country codes are often the way these
users think of a layout, with a few cases where more specific names
are needed. For example, I wouldn't think of a US English keyboard,
but just a US keyboard, and similarly for a French keyboard. I would
not expect to look for a Canadian English keyboard, but would look for
a Canadian French or Canadian Bilingual keyboard.

> And then it's easier to mechanically
> put the locale ID in to the keyboard selection variable,
> instead of thinking about (or looking up) whether this is
> a country that does not need the full locale ID to select
> a keymap.

But then we either need to provide symlinks for all locale names, or
the user needs to determine if their locale is one which has a keymap
or not. And there may be ambiguities in the "default" symlink mapping;
for instance, there are arguments to be made to symlink en_CA to
either en_US or fr_CA.

> In Europe, you'll often need the locale name,
> not only the country.

We don't seem to have many cases of this in the existing syscons
keymaps, but you certainly understand this better than I do; perhaps
this will be an issue when adding more keymaps.

> I really think we'll regret using anything but locale names
> for keymaps, and I'd want to rename those that you committed
> under 2-letter ISO names. Is that acceptable to you?

The worry I have with using locale names is that it implies there is a
1:1 mapping, which is sometimes true and sometimes not.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Stefan Eßer
Am 14.08.2014 um 19:13 schrieb Ed Maste:

> On 14 August 2014 08:21, Stefan Esser <[hidden email]> wrote:
>> There probably won't be a 1:1 mapping for all cases, but I think
>> that there is value in going for a regular naming scheme.
>>
>> We can use "fr.kbd" as a short form of "fr_FR.kbd", but there
>> will be a "fr_CH.kbd" and possibly a "fr_CA.kbd". The "fr" in
>> the short form will correspond to the "FR" in "fr_FR.kbd",
>> which is hidden by the fact, that both parts read "fr".
>
> I agree that consistency is a useful overall goal, and I don't have a
> very strong preference for the short names, it just seems to me to map
> well to what it seems users actually call the keyboard layouts.
> French, Swiss French, and French Canadian keyboard layouts in these
> three cases. Also, Linux console setting seems to generally use
> 2-letter names as far as I can tell.

The existing 2-letter names are inconsistent: most are country
codes, but in a few cases the language code was used. I do not
know why "iw" is used for he_IL (hebrew / Israel), since "iw"
does match neither "he" nor "il" ...

You can download and check my not-yet committed working files
from: http://people.freebsd.org/~se/vt-keymaps.tar.bz2

That TAR file contains a draft version of INDEX.keymaps, which
uses keymap files named after locales. I have removed the now
obsolete encoding from the explanation for each keymap file.

What's missing is the conversion of the localized texts to
Unicode (from some ISO8859 variant or CPxxx or koi8-[ru]).

I only fixed the English and German texts, so far.

> Would every locale we support have either a file or symlink?  Or only
> a subset, roughly equivalent to what's provided by the syscons keymaps
> today?

I think we should try to have at least one default keymap file
per locale. A special case is es_LA (which Tom Evans mentioned
to be used as a pseudo-locale for spanish speaking latin-american
countries by e.g. Facebook).

But we could link or symlink other locale names to the generic
file, for these cases.

>> But look at "uk_UA.kbd", which will be short-named as "ua.kbd",
>> or "be_BY.kbd" mapped to "by.kbd" versus "nl_BE.kbd" mapped to
>> "be.kbd".
>>
>> For some language/country combinations, the short form ends up
>> in a distant location to the long form names.
>
> But I expect most users would choose from a menu without seeing the
> underlying keymap filename anyway, so I don't think this matters much.

Well, if you already have a locale set by the user, then you
could prefer keymap files that start with the locale name
(sans encoding).

I have committed an initial fix to kbdmap/vidfont to make it
use share/vt instead of share/syscons if started on a system
using NEWCONS.

But I guess the selection logic is not correct or at least
not optimal. There ought to be sufficient time to fix this
for 10.1, though.

>> And will there be a "ch.kbd" for "de_CH.kbd" (the majority of
>> Swiss users will use that keymap), or will they all be of the
>> form "??_CH.kbd" ... ???
>
> I would assume ??_CH.kbd since I suspect users would generally not
> refer to a "Swiss" keyboard layout, but rather a "Swiss German" or
> "Swiss French" layout.  (I'm happy to be corrected if wrong.)

The selection in Windows is (AFAICR, it's been quite some time
since I last installed Windows from DVD) to first choose a
language (which changes the messages displayed for the following
selections). Then you choose a country to complete the selection
of a locale.

E.g. first selection is "German" or "French", next selection is
the country from a list where this language is spoken (which
would offer e.g. Germany, Switzerland, Austria for "German" and
Belgium, France, Switzerland for "French").

I really should start the Windows installer to check whether
this actually is what Windows does ... ;-)

>> For all these reasons I think the short form serves no real
>> purpose. If you want to support it, you could symlink a short
>> name to the locale based name (to allow the use of just the
>> country code, if people edit rc.conf by hand, while I'd expect
>> the installer to use the locale based keyboard names).
>
> If we do end up with locale names I don't think there's much value in
> having short name symlinks.  It's just another level of indirection
> that needs to be kept up to date.

Yes, I agree. If the selection of the language (and country,
where required) is from a menu, the locale names are as good
as any other ID.

>> I think this should be implemented in time for 10.1, if at
>> all possible.
>
> Indeed, that is exactly why I wanted to move ahead with the "trivial"
> cases, even if they turned out not to be so.  I'm sorry for the
> conflict that caused with your work in progress.

Well, nothing has been lost ;-)

I had wanted to commit the keymaps named after locales, today,
but held back the commit to wait for your reply and further
comments. It's already near midnight, here - so I'll do the
commits tomorrow, to avoid making silly mistakes (and it has
been shown to be bad practice to go to bed immediately after
a commit ;-)

>> Most users will either use the installer (and will thus
>> never see the locale IDs)
>
> I think we agree that for these users it makes very little difference
> what the keymap name actually is, since they won't see it.
>
>> or they'll manually edit rc.conf and will know their way.
>
> And in this case I think the country codes are often the way these
> users think of a layout, with a few cases where more specific names
> are needed. For example, I wouldn't think of a US English keyboard,
> but just a US keyboard, and similarly for a French keyboard. I would
> not expect to look for a Canadian English keyboard, but would look for
> a Canadian French or Canadian Bilingual keyboard.

Please look at the TAR file I prepared. I rank the symmetry
in the format of the names higher than the shorter names.
And in fact, keyboard layouts are often specific to a country,
and not to a language. The 2-letter names hide the difference
for the simple case ("fr" is really sufficient if "fr_FR" is
meant), but if you look at syscons/keymaps there are examples
of keymap files named after the language code and others named
after the country code.

>> And then it's easier to mechanically
>> put the locale ID in to the keyboard selection variable,
>> instead of thinking about (or looking up) whether this is
>> a country that does not need the full locale ID to select
>> a keymap.
>
> But then we either need to provide symlinks for all locale names, or
> the user needs to determine if their locale is one which has a keymap
> or not. And there may be ambiguities in the "default" symlink mapping;
> for instance, there are arguments to be made to symlink en_CA to
> either en_US or fr_CA.

Well, I do not have an easy answer to this. But being explicit
in the names allows to provide easily identified correct keymaps.

>> In Europe, you'll often need the locale name,
>> not only the country.
>
> We don't seem to have many cases of this in the existing syscons
> keymaps, but you certainly understand this better than I do; perhaps
> this will be an issue when adding more keymaps.

Look at the locale names in share/locales. There are quite a
number that are of the form "xx_XX" with no other locale sharing
the country or locale part. But there are quite a number where
languages and countries are in a n:m relation and some where
the language and country IDs are different (e.g. "da_DK"). We
are used to identify countries with ISO country codes (most
probably because of their use in DNS addresses), but as I said,
not all 2-letter keymap names where derived from the country
code and I can see how that happened.

Using locale names adds a few characters to the ID, but makes
it really clear what is meant.

>> I really think we'll regret using anything but locale names
>> for keymaps, and I'd want to rename those that you committed
>> under 2-letter ISO names. Is that acceptable to you?
>
> The worry I have with using locale names is that it implies there is a
> 1:1 mapping, which is sometimes true and sometimes not.

Do you know about cases where this is the case?

I've seen locales where a "Traditional" and "modern" layout
exist, but that's easily added (like the .acc." marker) to the
keymap name.

The keymap named after the locale should be a good first try
for a freshly installed system (I hope ...).

Regards, STefan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Brandon Allbery
On Thu, Aug 14, 2014 at 5:40 PM, Stefan Esser <[hidden email]> wrote:

> codes, but in a few cases the language code was used. I do not
> know why "iw" is used for he_IL (hebrew / Israel), since "iw"
> does match neither "he" nor "il" ...
>

Sounds like a questionable transliteration of the language name (ivrit)...
the questionable part being that it's vet, not vav. (Sort of the reverse of
Svenska == sv ~~ Swedish.)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Keymap definitions for VT / NEWCONS

Patrick Powell
In reply to this post by Stefan Eßer
On 08/14/14 14:40, Stefan Esser wrote:
> The existing 2-letter names are inconsistent: most are country codes,
> but in a few cases the language code was used. I do not know why "iw"
> is used for he_IL (hebrew / Israel), since "iw" does match neither
> "he" nor "il" ...
Somebody with a bad sense of humor and who loved making puns? iw == IbreW?


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12