Czech keyboard issues

Snork

Snork

Hello there,

I've been wanting to try out FreeBSD for a while now but I've ran into a problem when it comes to setting up the keyboard layout. When I choose the czech keyboard (qwertz with accent keys) I have the following problems -
1) The only accent letters that appear are the áíéú keys, although only the lowercase version. Using caps-lock to produce to uppercase version produces the lowercase version again.
2) The rest of the accent keys (ěščřžýů) produce a question mark instead in both lowercase and uppercase.
3) Keybindings of the form "AlrGr+letter" - such as pressing AltGr+f being [, AltGr+g being ] etc. - produce only the letter. That is AltGr+f gives f instead.
4) Then there's the rather strange fact that when choosing the czech keyboard during the installation you still have the US layout and have to press left Alt+Shift to get the czech layout.

Initially I though that the sh shell had a problem displaying the errors so I installed csh instead but the problem is still there as well. Here is my locale output :

Code: 
LANG = C.UTF-8
LC_CTYPE = "C.UTF-8"
LC_COLLATE = "C.UTF-8"
LC_TIME = "C.UTF-8"
LC_NUMERIC = "C.UTF-8"
LC_MONETARY = "C.UTF-8"
LC_MESSAGES = "C.UTF-8"
LC_ALL =

And I'm running the 13.1 Release version of FreeBSD. From the following post that was made 7 years ago https://forums.freebsd.org/threads/localization-czech-letters.55686/#post-316537 it looks like the exact same problem as I have but there isn't an explicit solution as far as I can tell.

I should point out that I'm new to FreeBSD and not exactly a hardcore linux user so I'm lost and confused on how to solve this issue. I also should mention that I'm running FreeBSD in a virtual machine to try it out first. Any help will be appreciated with some clear instructions. Thank you in advance
 
Snork said:
I'll try to look into my /etc/login.conf file and perhaps my ~/.cshrc as well.
Click to expand...
So even after changing my /etc/login.conf to look like this -
Code: 
czech|Czech users accounts:\
    charset=UTF-8:\
    lang=cs_CZ.UTF-8:\

the problem stays the same. Although this time the output of locale is cs_CZ.UTF-8 except LC_ALL which stays empty.
I have also added setenv LANG cs_CZ.UTF-8 in my .cshrc file although that didn't work either.
 
Snork said:
and perhaps my ~/.cshrc
Click to expand...
sorry if I'm asking something that might look obvious - what shell are you running on? You might need to look at ~/.shrc or /etc/profile for env variables being set.

EDIT: probably should add /etc/csh.* files, since you pointed at csh as well.
 
Snork said:
So even after changing my /etc/login.conf to look like this -
Rich (BB code): 
czech|Czech users accounts:\
    charset=UTF-8:\
    lang=cs_CZ.UTF-8:\
the problem stays the same.
Click to expand...
There are colons missing in front of the "charset" and "lang" variables.

If the "lang" environment variable is the last line then there must not be a backslash ( \ ) after the colon ( : ).

Also I suggest to integrate the "default" login class:
Code: 
czech|Czech users accounts:\
    :charset=UTF-8:\
    :lang=cs_CZ.UTF-8:\
    :tc=default:
As Erichans has already mentioned, cap_mkdb(1) must be run after editing /etc/login.conf.

Furthermore, the user must be set to the "czech" login class to take effect, otherwise the "default:" login class will be used.

For new users created by adduser(8) in "Login class". For existing users execute as root chpass(1) <user> and set "Class:"
 
All this login.conf discussion is nice, but completely unrelated to the OP problem, more so #6 already says that locale is set properly.

Snork said:
System console. Haven't installed X and a DE yet.
Click to expand...
Check /usr/share/vt/keymaps/cz.kbd contents, it documents how exactly to input different characters, which could be different from the way you are used to (tried it and most of the characters work).
 
And it looks like there is an obvious bug in handling the accent "unicode" sequences in kbdcontrol - where it should output wide character code > 255, it outputs only the last byte ( kbcontrol -d agrees). E.g. for cz keymap:
Code: 
$ kbdcontrol -d
...
  dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
             ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
             ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
             ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
             ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
             ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
             ( 'y' 253 )
...
while in the keymap file it is:
Code: 
  dacu 0xb4    ( 0xb4   0xb4    ) ( 'S'    0x015a  ) ( 'Z'    0x0179  ) ( 's'    0x015b  )
               ( 'z'    0x017a  ) ( 'R'    0x0154  ) ( 'A'    0xc1    ) ( 'L'    0x0139  )
               ( 'C'    0x0106  ) ( 'E'    0xc9    ) ( 'I'    0xcd    ) ( 'N'    0x0143  )
               ( 'O'    0xd3    ) ( 'U'    0xda    ) ( 'Y'    0xdd    ) ( 'r'    0x0155  )
               ( 'a'    0xe1    ) ( 'l'    0x013a  ) ( 'c'    0x0107  ) ( 'e'    0xe9    )
               ( 'i'    0xed    ) ( 'n'    0x0144  ) ( 'o'    0xf3    ) ( 'u'    0xfa    )
               ( 'y'    0xfd    )

Check e.g. the 'C' character, keymap says 0x0106, kbdcontrol has it as just 006 (last byte).

EDIT: apparently this is only the output issue in kbdcontrol, the accent values are read correctly, but then again, sys/sys/kbio.h has the following definition -- note the u_char for accent values (we want 2 bytes, at least, here instead), so it's broken anyway, and it could possibly explain the '?' from the OP:
Code: 
struct acc_t {
    u_char        accchar;
    u_char        map[NUM_ACCENTCHARS][2];
};
 
cmoerz said:
sorry if I'm asking something that might look obvious - what shell are you running on? You might need to look at ~/.shrc or /etc/profile for env variables being set.

EDIT: probably should add /etc/csh.* files, since you pointed at csh as well.
Click to expand...
I'm currently using the csh shell.
 
yuripv79 said:
And it looks like there is an obvious bug in handling the accent "unicode" sequences in kbdcontrol - where it should output wide character code > 255, it outputs only the last byte ( kbcontrol -d agrees). E.g. for cz keymap:
Code: 
$ kbdcontrol -d
...
  dacu  180  ( 180 180 ) ( 'S' 'Z' ) ( 'Z' 'y' ) ( 's' '[' )
             ( 'z' 'z' ) ( 'R' 'T' ) ( 'A' 193 ) ( 'L' '9' )
             ( 'C' 006 ) ( 'E' 201 ) ( 'I' 205 ) ( 'N' 'C' )
             ( 'O' 211 ) ( 'U' 218 ) ( 'Y' 221 ) ( 'r' 'U' )
             ( 'a' 225 ) ( 'l' ':' ) ( 'c' 007 ) ( 'e' 233 )
             ( 'i' 237 ) ( 'n' 'D' ) ( 'o' 243 ) ( 'u' 250 )
             ( 'y' 253 )
...
while in the keymap file it is:
Code: 
  dacu 0xb4    ( 0xb4   0xb4    ) ( 'S'    0x015a  ) ( 'Z'    0x0179  ) ( 's'    0x015b  )
               ( 'z'    0x017a  ) ( 'R'    0x0154  ) ( 'A'    0xc1    ) ( 'L'    0x0139  )
               ( 'C'    0x0106  ) ( 'E'    0xc9    ) ( 'I'    0xcd    ) ( 'N'    0x0143  )
               ( 'O'    0xd3    ) ( 'U'    0xda    ) ( 'Y'    0xdd    ) ( 'r'    0x0155  )
               ( 'a'    0xe1    ) ( 'l'    0x013a  ) ( 'c'    0x0107  ) ( 'e'    0xe9    )
               ( 'i'    0xed    ) ( 'n'    0x0144  ) ( 'o'    0xf3    ) ( 'u'    0xfa    )
               ( 'y'    0xfd    )

Check e.g. the 'C' character, keymap says 0x0106, kbdcontrol has it as just 006 (last byte).

EDIT: apparently this is only the output issue in kbdcontrol, the accent values are read correctly, but then again, sys/sys/kbio.h has the following definition -- note the u_char for accent values (we want 2 bytes, at least, here instead), so it's broken anyway, and it could possibly explain the '?' from the OP:
Code: 
struct acc_t {
    u_char        accchar;
    u_char        map[NUM_ACCENTCHARS][2];
};
Click to expand...
Thank you a lot for that. Unfortunately my C programming skills are very limited so I'm not exactly sure if this is something I can fix by myself. Is there something that can be done about this?
 
It should be as simple as the following patch:
Code: 
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;

 struct acc_t {
        u_char          accchar;
-       u_char          map[NUM_ACCENTCHARS][2];
+       int             map[NUM_ACCENTCHARS][2];
 };

 struct accentmap {

With the patch applied and the system rebuilt, I can now input all of the characters according to rules in cz.kbd keymap file.

I have posted a question to current@ mailing list, let's see what they think:

 
yuripv79 said:
It should be as simple as the following patch:
Code: 
diff --git a/sys/sys/kbio.h b/sys/sys/kbio.h
index 7f17bda76c5..fffeb63e226 100644
--- a/sys/sys/kbio.h
+++ b/sys/sys/kbio.h
@@ -200,7 +200,7 @@ typedef struct okeymap okeymap_t;

 struct acc_t {
        u_char          accchar;
-       u_char          map[NUM_ACCENTCHARS][2];
+       int             map[NUM_ACCENTCHARS][2];
 };

 struct accentmap {

With the patch applied and the system rebuilt, I can now input all of the characters according to rules in cz.kbd keymap file.

I have posted a question to current@ mailing list, let's see what they think:

Click to expand...
Just to be sure, in order to rebuild FreeBSD, I'd have to follow the following instructions right?
docs.freebsd.org

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc
docs.freebsd.org docs.freebsd.org
Thank you again a lot, let's wait and see what answer we get.
 
Snork, you are now working in a console (not in X) and I'm wondering if you are using a special font?
Changing your keyboard mapping may be helpful.

I've done some experimenting because I couldn't display any glyphs of the Czech special characters like ě 0x0115 and Ł 0x0141. On my old laptop keyboard and using fonts from x11-fonts/spleen or x11-fonts/terminus-font; using vga graphics mode. Thus, sofar:
  1. Loosely based on this Czech layout, I can type & display a lot of Czech glyphs:
    ěščřžýůáíéú
  2. Can use one combining character ´ 0x00B4:
    áíéú ÁÍÉÚ
  3. Seems like other glyps that are difficult to access through the current layout as defined by /usr/share/vt/keymaps/cz.kbd belong to Unicode Range "Latin Extended-A", however it seems that inserting them cz.kbd will display them correctly, for example with 0x0141:
    Ł
  4. Switcing in and out of "special qwertz" or czech mode is somewhat inconsistant;
  5. When in "special qwertz" or czech mode and then interactively swithing to another keymap (using kbdmap(1)) like US std will almost always give me hung consoles;
  6. Combination of keys, e.g. alt gr mostly don't work; related to the problem mentioned by yuripv79
ad 4 & 5: switching by "have to press left Alt+Shift to get the czech layout." mostly switches correctly (testing with the y/z in "qwerty/quertz") but sometimes requires another go. When in czech layout and interactively switching to e.g. US std. keymap hung consoles forces power cycling on my laptop.

My laptop and the layout given in Czech layout is based on a layout without the "extra key" that German and perhaps some Czech keyboards have as well: the extra key immediately to the left of the Z-key (in querty layout the bottom row of the alphabet characters). If you have one more key there the cz.kbd could give you access to additional selection & display of glyphs that I do not work with my limited laptop keyboard.

First tried to display a few special characters like ě 0x0115: didn't work. Switching focus to de.acc.kbd trying to display special glyphs that German and Czech have in common like ö 0x00F6: that worked. However inserting ě 0x0115 in de.acc.kbd didn't work.

For me, the solution to this problem was installing x11-fonts/spleen and copying /usr/local/share/fonts/spleen/spleen-8x16.fnt to /usr/share/vt/fonts/spleen-8x16.fnt. Rather unsurprising in hindsight because my old laptop would likely not have the appropriate character set and fonts for the glyphs belonging to the Unicode Range "Latin Extended-A". Interactively selecting this font with vidfont(1) and then switching to the czech keymap with kbdmap(1) displayed ě 0x0115 correctly.

Back to cz.kbd: still cannot get the combining keys that should display Ł to work, but inserting 0x017F in the keymap for a direct key (CTRL+1) worked.

Regarding your statement "The rest of the accent keys (ěščřžýů) produce a question mark instead in both lowercase and uppercase": this is probably an indication that there is no font available to display glyphs for characters belonging to the Unicode Range "Latin Extended-A". As a necessary pre-condition there also must be a character set available that supports those characters; that is what the UTF-8 character set is for.

With non-KMS mode (not using my Nvidia graphics card—not supported anymore), vga graphics mode, no login class, my settings:
~/.login_conf
Code: 
me:\
       :charset=UTF-8:\
       :lang=cs_CZ.UTF-8:
For displaying Ł 0x0141 (by pressing CTRL+1) in my cz.kbd :
Code: 
# diff cz.kbd.ORG cz.kbd
149c149
<   130   '+'    '1'    nop    nop    '+'    '1'    nop    nop     O
---
>   130   '+'    '1'    0x0141 nop    '+'    '1'    nop    nop     O

When I have set everything as mentioned, opening cz.kbd in vi displays the glyphs of the characters in the section Accent characters almost everywhere correctly; you should see the same in your browser here: cz.kbd. Also, as expected, a test file with Czech special characters inserted will correctly display with other users with different locale and keymap settings but with an UTF-8 character set.

Curious what further developments will bring.
 
You must log in or register to reply here.
Back
Top