Bug 942896 - YaST should set unicode console font to fit new unicode keymaps for Latin alphabets
YaST should set unicode console font to fit new unicode keymaps for Latin alp...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Ancor Gonzalez Sosa
Jiri Srain
:
Depends on:
Blocks: 997402
  Show dependency treegraph
 
Reported: 2015-08-24 12:31 UTC by Mindaugas Baranauskas
Modified: 2021-03-02 16:45 UTC (History)
12 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
This patch should fix it. (405 bytes, patch)
2015-08-24 15:31 UTC, Stefan Dirsch
Details | Diff
journalctl -u systemd-vconsole-setup.service > fr.txt (6.01 KB, text/plain)
2015-10-29 21:57 UTC, Mindaugas Baranauskas
Details
journalctl -u systemd-vconsole-setup.service > lt.txt (7.59 KB, text/plain)
2015-10-29 22:22 UTC, Mindaugas Baranauskas
Details
journalctl -u systemd-vconsole-setup.service > lt-triv.txt (9.18 KB, text/plain)
2015-10-29 22:41 UTC, Mindaugas Baranauskas
Details
journalctl -u systemd-vconsole-setup.service > lt-.txt (12.66 KB, text/plain)
2015-10-29 22:53 UTC, Mindaugas Baranauskas
Details
journalctl -u systemd-vconsole-setup.service > lt-none.txt (16.07 KB, text/plain)
2015-10-29 23:05 UTC, Mindaugas Baranauskas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mindaugas Baranauskas 2015-08-24 12:31:33 UTC
As https://features.opensuse.org/318355 is in progress,
openSUSE will use console keymaps, that are convert from X keyboard layouts.

Console keymaps are highly dependent on settings in /etc/sysconfig/console.

New converted layout requires to set these values of variables:
CONSOLE_UNICODEMAP=""
CONSOLE_SCREENMAP=""
CONSOLE_MAGIC=""
CONSOLE_ENCODING="UTF-8"

also CONSOLE_FONT must be changed to one, that is UTF-8 and covers as many characters.
Fedora seems to use eurlatgr console font, that covers LatArCyrHeb and plus provides more special characters (according to https://fedoraproject.org/wiki/Changes/NewDefaultConsoleFont ). openSUSE has eurlatgr console font as file:///usr/share/kbd/consolefonts/eurlatgr.psfu.gz
I tested it and it seems the best one! Even ←↓↑→ characters are displayed in console with this font. We also can set for most layouts:
/etc/sysconfig/console CONSOLE_FONT="eurlatgr"
EurLatGr provides greater coverage for Latin and Greek characters, but at the cost of Arabic, Cyrillic and Hebrew characters being dropped. So we can use LatArCyrHeb-16 (or LatArCyrHeb-14) font for layouts with Arabic, Cyrillic and Hebrew characters.
Comment 1 Josef Reidinger 2015-08-24 13:55:44 UTC
ancor please check, thanks
Comment 5 Stefan Dirsch 2015-09-14 09:20:36 UTC
Indeed RH switched to "eurlatgr" meanwhile. Exceptions where they use "latarcyrheb-sun16" instead are:

- russian (cyrillic characters)
- hebrew
- arabic


See https://github.com/mike-fabian/langtable for more details.
Check langtable.py and data/languages.xml.
Comment 6 Stefan Dirsch 2015-10-21 12:39:54 UTC
Ancor, could you please look into this? Thanks!
Comment 7 Ancor Gonzalez Sosa 2015-10-23 08:48:15 UTC
Well, actually the console font is managed by the "Language" option in YaST, not by the "Keyboard layout" one. And I actually think it's correct to define the font based on the language and not on the keyboard layout.

We have a single yast2-country package that provides 3 YaST clients:

 - keyboard (a.k.a. "System Keyboard Layout")
 - language (a.k.a. "Language)
 - timezone (a.k.a. "Date and Time")

As said, I thing that the console font belongs to the second one, as it is right now. When changing the language you can ask YaST to adjust your keyboard according to the new language. But you can also use only the keyboard client to change the layout without affecting the language (and, thus, the console font).

About the mapping. YaST uses the file /usr/share/YaST2/data/consolefonts.ycp. As you can see there, our mapping is way more complex than

"latarcyrheb-sun16 for Russian, Hebrew and Arabic; eurlatgr for everything else"

I would happily simplify our mapping if all the parties agree that it's the correct thing to do. Just one note about it, we don't have a file called latarcyrheb-sun16.psfu.gz in our kbd package, so you'll have to point me to the right one.
Comment 8 Mindaugas Baranauskas 2015-10-23 09:05:48 UTC
(In reply to Ancor Gonzalez Sosa from comment #7)
> Just one note about it, we don't have a file called
> latarcyrheb-sun16.psfu.gz in our kbd package, so you'll have to point me to
> the right one.


> rpm -q -l kbd | grep -i latarcyrheb # openSUSE Tumbleweed
/usr/share/kbd/consolefonts/LatArCyrHeb-08.psfu.gz
/usr/share/kbd/consolefonts/LatArCyrHeb-14.psfu.gz
/usr/share/kbd/consolefonts/LatArCyrHeb-16+.psfu.gz
/usr/share/kbd/consolefonts/LatArCyrHeb-16.psfu.gz
/usr/share/kbd/consolefonts/LatArCyrHeb-19.psfu.gz
Comment 9 Stefan Dirsch 2015-10-23 10:50:44 UTC
I agree that console font should depend on the language, not on the keyboard layout.

> About the mapping. YaST uses the file /usr/share/YaST2/data/consolefonts.ycp. > As you can see there, our mapping is way more complex than
> "latarcyrheb-sun16 for Russian, Hebrew and Arabic; eurlatgr for everything
> else"
> I would happily simplify our mapping if all the parties agree that it's the 
> correct thing to do.

What are "all" parties. I'm adding our font expert at least here. Petr, can you share your thoughs here?
Comment 10 Ancor Gonzalez Sosa 2015-10-23 11:03:46 UTC
(In reply to Stefan Dirsch from comment #9)
> What are "all" parties.

I don't know. Whoever that would yield to us if we do the change without asking him/her. :-)
Comment 11 Stefan Dirsch 2015-10-23 12:16:45 UTC
(In reply to Ancor Gonzalez Sosa from comment #10)
> (In reply to Stefan Dirsch from comment #9)
> > What are "all" parties.
> 
> I don't know. Whoever that would yield to us if we do the change without
> asking him/her. :-)

Which again means we need to do the change and then wait for complains. ;-)
BTW, I don't understand the meaning of unicode map/screen map/console magic
cols in /usr/share/YaST2/data/consolefonts.ycp.
Comment 12 Mindaugas Baranauskas 2015-10-23 12:31:25 UTC
If you open /etc/sysconfig/console , you see:



## Type:	string
## Default:	""
#
# Most programs output 8 bit characters, so you need a table to
# translate those characters into unicode. That one can be specified
# here. (/usr/share/kbd/consoletrans/)
# (Note: If your console is in utf-8 mode you don't need this.)
# If your code does not use a unicode mapping at all (because you
# e.g. explicitly specified UNICODEMAP="none") you may circumvent
# the translation via unicode, but load a map which directly maps
# 8 bit output of your program to a font position.
#
CONSOLE_SCREENMAP=""



## Type:	string
## Default:	""
#
# for some fonts the console has to be initialized with CONSOLE_MAGIC.
# CONSOLE_MAGIC can be empty or have the values "(B", ")B", "(K" or ")K".
# Normally not needed (automatically handled by setfont).
#
CONSOLE_MAGIC=""
Comment 13 Petr Gajdos 2015-10-26 08:14:43 UTC
Unfortunately, I do not know kbd, adding its maintainer. Standa, do you have any thoughts?
Comment 15 Stanislav Brabec 2015-10-26 14:34:27 UTC
Picking a proper keymap, unimap and font is a very sensitive issue: kbd package contains lot of fonts with mistakes, missing unicode mapping, obscure keymaps.

Mapping of X keyboard to console will solve one part of the problem.

Looking at /usr/share/doc/packages/kbd/fonts/README.eurlatgr, eurlatgr seems to be a superior font that should be well usable.

If it is truem I guess it is possible to try to switch to eurlatr in all languages where it makes sense.


Regarding the change of fonts for Cyrillic, we have to check the font coverage before the switch. Some of the fonts in kbd contain only Russian characters, and they are missing characters used in Ukrainian or Bulgarian.
Comment 16 Ancor Gonzalez Sosa 2015-10-28 14:13:53 UTC
I created this pull request for you guys to review
https://github.com/yast/yast-country/pull/61/files

The part that needs review is the consolefonts.ycp. The fix in the keyboard mapping belongs to another bug (and it's already verified) and the changes in the ruby code are just for legibility (no change in behavior).

But the consolefonts.ycp part is tricky because I have no clue about the proper values for screen map and console magic. The pull request assumes that console magic is not needed for eurlatgr and that the "trivial" mapping can be used always, independently of the variant of the language being used. That's only wild guessing (and dreaming about map simplification), I need somebody understanding that mapping magic to point me in the right direction.

I was not brave enough to touch Cyrillic languages.
Comment 17 Stefan Dirsch 2015-10-28 16:10:16 UTC
Unfortunately I don't know anything about this screen map and console magic. It's a pity, that you aren't brave enough to touch Cyrillic languages. :-(
Comment 18 Ancor Gonzalez Sosa 2015-10-28 16:12:13 UTC
(In reply to Stefan Dirsch from comment #17)
> It's a pity, that you aren't brave enough to touch Cyrillic languages. :-(

Step by step. Let's see how the latin thing works first. ;-)
Comment 19 Mindaugas Baranauskas 2015-10-28 16:27:25 UTC
For Lithuanian I earler tested using eurlatgr and confirm it as best.

In proposed configuration I more doubt about if it is safe to remove *_XX and *_XX.UTF ... But I am not specialist also here. I can help with testing.

To have more confidence, we can always check Fedora / Red Hat source, as they already use  them...
Comment 21 Mindaugas Baranauskas 2015-10-28 20:12:13 UTC
Seems that these mystic parameters applays only for old fonts, that don't support unicode.

From setfont man page:
The correspondence between the glyphs in the font and Unicode values is described by a Unicode mapping table.  Many fonts have  a  Unicode        mapping  table included in the font file, and an explicit table can be indicated using the -u option. The program setfont will load such a        Unicode mapping table, unless a -u none argument is given. 

Old fonts do not have Unicode mapping info, and in order to handle them there are direct-to-font maps (also loaded using -m) that  give  a correspondence  between  user  bytes  and font positions.  The most common correspondence is the one given in the file trivial (where user byte values are used directly as font positions).

--

Seems, that some information about using setfont parameters are detailed in obsoleted mapscrn command. From its man page:

The  mapscrn  command is obsolete - its function is now built-in into setfont.  However, for backwards compatibility it is still available as a separate command.

The mapscrn command loads a user defined output character mapping table into the console driver. The console driver may be later put  into use  user-defined  mapping  table mode by outputting a special escape sequence to the console device.  This sequence is <esc>(K for the G0 character set and <esc>)K for the G1 character set.  When the -o option is given, the old map is saved in map.orig.
Comment 22 Mindaugas Baranauskas 2015-10-28 20:22:37 UTC
I hope we will switch to unicode console for all locales, we set new unicode fonts, so CONSOLE_UNICODEMAP, CONSOLE_SCREENMAP, CONSOLE_MAGIC parameters could be set to empty (but I doubt if we must drop it: maybe some persons would like intentionally change this parameters...)
Comment 23 Mindaugas Baranauskas 2015-10-28 20:42:04 UTC
To make clearer – this bug was opened becauce of this:
then using converted from X keymaps to console, your pressed letter in keyboard will be correctly displayed, then you use correct console font configuration. New console keymaps support unicode, so they bahaves nice with unicode fonts. Existing old console font configurations no longer fit well at least for converted Lithuanian console keyboard: you type diacritic character, but see some strange symbols. Unicode compatible console keymap + good unicode font resolves problemas!
Comment 24 Ancor Gonzalez Sosa 2015-10-29 14:51:45 UTC
(In reply to Mindaugas Baranauskas from comment #22)
> I hope we will switch to unicode console for all locales, we set new unicode
> fonts, so CONSOLE_UNICODEMAP, CONSOLE_SCREENMAP, CONSOLE_MAGIC parameters
> could be set to empty (but I doubt if we must drop it: maybe some persons
> would like intentionally change this parameters...)

Ok, I updated the pull request. Now none of the three esoteric parameters is used for eurlatgr.psfu
https://github.com/yast/yast-country/pull/61

(In reply to Mindaugas Baranauskas from comment #19)
> In proposed configuration I more doubt about if it is safe to remove *_XX
> and *_XX.UTF ... But I am not specialist also here. I can help with testing.

The two letters code is used as a fallback in the YaST code if a more detailed code (like xx_XX.UTF) is not found in consolefonts.ycp. Thus, if we are going to use exactly the same configuration for "es", "es_ES", "es_ES.UTF" and "es_ES@euro" it's simple harmless (and more compact) to remove all but the first.

Of course, when testing we need to test with utf and non-utf configurations and with different countries. For that, you need to click on "details" on the YaST language mode and play with the settings there.

I did some experiments with the proposed pull request in Spanish and everything looks fine with es_ES@euro and es_ES.UTF. Even en_US allowed me to use Spanish characters. But Spanish is not a very challenging language, we only have a few difficult characters.

More testing is welcome. Unless somebody has something against, I'll try to get the pull request into Factory on Tuesday (public holiday on Monday). Then we can wait for people screaming and/or proceed with non latin languages.
Comment 25 Mindaugas Baranauskas 2015-10-29 21:57:42 UTC
Created attachment 653848 [details]
journalctl -u systemd-vconsole-setup.service > fr.txt



Just installed fresh openSUSE TW for testing.
Changes system according https://github.com/yast/yast-country/pull/61 .

# localectl
   System Locale: LANG=POSIX
                  LC_CTYPE=fr_FR.UTF-8
       VC Keymap: lt
      X11 Layout: lt
       X11 Model: pc105
     X11 Options: terminate:ctrl_alt_bksp


# cat /etc/vconsole.conf
KEYMAP=lt

Then I write 'ą', I get 'Ä│', then I press backspace, only last symbol '│' removes.

Then opened YaST and changed language to French. 
Reboot.
While booting I see message twice:

systemd[1]: Failed to start Setup Virtual Console.


# localectl
   System Locale: LANG=POSIX
                  LC_CTYPE=fr_FR.UTF-8
       VC Keymap: lt
      X11 Layout: lt
       X11 Model: pc105
     X11 Options: terminate:ctrl_alt_bksp


Then I write 'ą', I get 'ÄÅ', then I press backspace, only last symbol removes.
Comment 26 Mindaugas Baranauskas 2015-10-29 22:00:12 UTC
Incorrect place of localectl output was in last message: the first output must contain lt_LT, not fr_FR
Comment 27 Mindaugas Baranauskas 2015-10-29 22:06:16 UTC
/etc/sysconfig/console variables are as expected:

CONSOLE_FONT="eurlatgr.psfu"
CONSOLE_UNICODEMAP=""
CONSOLE_SCREENMAP="none"
CONSOLE_ENCODING="UTF-8"

I change back language via YaST to Lithuanian.

/etc/sysconfig/console variables remain the same.
Comment 28 Mindaugas Baranauskas 2015-10-29 22:20:21 UTC
Before reboot I tried to type in console, but result is same.
Executing 'setfont eurlatgr' did not changed anything.

After reboot I again see same twice error/warning about "Failed to start Setup Virtual Console" in boot screen:


[    2.667500] systemd-fstab-generator[88]: Failed to create mount unit file /ru
[    2.705565] systemd[1]: systemd-journald.socket: Job systemd-journald.socket/
[    2.821444] systemd[1]: Failed to start Setup Virtual Console.
[FAILED] Failed to start Setup Virtual Console.
See 'systemctl status systemd-vconsole-setup.service' for details.
[  OK  ] Started dracut pre-trigger hook.
         Starting udev Coldplug all Devices...
[  OK  ] Started udev Coldplug all Devices.
         Starting Show Plymouth Boot Screen...
         Starting dracut initqueue hook...
[    2.881441] mmc0: Unknown controller version (3). You may experience problems
[    6.268492] systemd-fstab-generator[353]: Failed to create mount unit file /run/systemd/generator/sysroot.mount, as it already exists. Duplicate entry in /etc/fstab?
[    6.401987] systemd[1]: Failed to start Setup Virtual Console.



# systemctl status systemd-vconsole-setup.service
● systemd-vconsole-setup.service - Setup Virtual Console
   Loaded: loaded (/usr/lib/systemd/system/systemd-vconsole-setup.service; static; vendor preset: disabled)
   Active: active (exited) since Pn 2015-10-30 00:07:41 EET; 6min ago
     Docs: man:systemd-vconsole-setup.service(8)
           man:vconsole.conf(5)
 Main PID: 451 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-vconsole-setup.service

Spa 30 00:07:41 nohostname systemd[1]: Started Setup Virtual Console.


Though then I press 'ą', I get 'ą'!
Comment 29 Mindaugas Baranauskas 2015-10-29 22:22:51 UTC
Created attachment 653853 [details]
journalctl -u systemd-vconsole-setup.service > lt.txt
Comment 30 Mindaugas Baranauskas 2015-10-29 22:39:20 UTC
I set CONSOLE_SCREENMAP="trivial".
mkinitrd
reboot

I see the same boot message, but now almost all is in yellow color, word [  OK  ] is in red color, only last 3 lines are in white. Backgourd of word FAILED is blue.

Then I enter 'ą', I get 'ìÅ'
Comment 31 Mindaugas Baranauskas 2015-10-29 22:41:28 UTC
Created attachment 653856 [details]
journalctl -u systemd-vconsole-setup.service > lt-triv.txt
Comment 32 Mindaugas Baranauskas 2015-10-29 22:53:04 UTC
Created attachment 653858 [details]
journalctl -u systemd-vconsole-setup.service > lt-.txt

Then I set

CONSOLE_SCREENMAP=""

mkinitrd
reboot

colors of messages same as with trivial.
Pressing 'ą' produces 'ÄÅ' 

In journalctl you see in addition:


Spa 30 00:45:53 nohostname systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE
Spa 30 00:45:53 nohostname systemd[1]: Failed to start Setup Virtual Console.
Spa 30 00:45:53 nohostname systemd[1]: systemd-vconsole-setup.service: Unit entered failed state.
Spa 30 00:45:53 nohostname systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'.
Comment 33 Mindaugas Baranauskas 2015-10-29 23:04:56 UTC
I set again
CONSOLE_SCREENMAP="none"


mkinitrd
reboot

I still see the same colorfull boot message...

Though then I press 'ą', I get 'ą'!
Comment 34 Mindaugas Baranauskas 2015-10-29 23:05:41 UTC
Created attachment 653860 [details]
journalctl -u systemd-vconsole-setup.service > lt-none.txt
Comment 35 Mindaugas Baranauskas 2015-10-30 23:16:18 UTC
A bit more testing with after fresh installed TW 2015-10-22 in VirtualBox.

Changing language via YaST don't re-create initrd image, but rebuilding of initrd is mandatory to take effect of changed CONSOLE_UNICODEMAP variable.

I started to change keyboards via YaST (after each change, I reboot):
* Lithuanian - good (but there is warnings "Failed to start Setup Virtual Console" maybe because of unknown keysym 'quotedblbase' in "lt" keyboard speciffically.)
* English (US) seems good.
* Canadian (multiling; ca-multix) - then typing à, ç or è - two symbols displayed: Ã and some non-letter symbol
* Purtugal - pressing ç - show ç - correct
* Slovak - ščťžýáíéňäúô - English keyboard in console, but pressing Right Alt + diacritic letter returns à and some non-letter symbol (vconsole-setup module warning in in systemd log: cannot open include file linux-keys-bare.inc)
* Slovenian - ž đ š ć - correct (but there is warnings "Failed to start Setup Virtual Console" maybe because of unknown keysym 'Omega' and 'omega' in "si" keyboard speciffically.)


At least with English (US) keyboard, Canadian (multiling)- I don't get any warnings/errors about vconsole while booting. For some other languages I don't remember well...
Comment 36 Stanislav Brabec 2015-11-02 16:38:47 UTC
Mindaugas Baranauskas:

The parameter for Unicode map is a bit more complicated.

Very old fonts and fonts in ancient formats don't contain any Unicode map. They contain just up to 256 characters, and it is expected, that the locale has the same character map. If it is not true, Unicode map has to be passed.

Newer fonts still support only up to 256 characters, but they embed a map between positions in font and Unicode characters. If this map is present, the font can be loaded without specifying Unicode map. The map inside the font is used.

New fonts support more thab 256 characters, and they embed a map between positions in font and Unicode characters. If the font is loaded without specifying Unicode map, the map inside the font is used.


Regarding your test: Are you aware of a race condition that could affect your tests? See bug 904214.

As far as I understand, fonts are correct even in Canadian and Slovak, but the keymap is bad. It could be the mentioned bug.


Regarding the patch:
https://github.com/yast/yast-country/pull/61/files

You included Serbian locale (sr_RS.UTF-8), which uses Cyrillic. Serbian should definitely use font supporting Cyrillic. (In difference to sr@Latin locale, which uses Latin alphabet.)

Regarding Japanese: It seems to be OK. It used lat9w before (=ISO-8859-15).
Comment 37 Mindaugas Baranauskas 2015-11-16 09:07:20 UTC
But bug 904214 is marked as fixed few time ago, online updates already provided for users. Can we continue?
Comment 38 Stefan Dirsch 2016-01-12 09:48:18 UTC
(In reply to Mindaugas Baranauskas from comment #37)
> But bug 904214 is marked as fixed few time ago, online updates already
> provided for users. Can we continue?

Good question. Ancor/Stanislav, what do you think?
Comment 39 Stanislav Brabec 2016-01-13 14:44:39 UTC
This bug apparently discusses two different problems:

1. Invalid console setup (bug 904214).

This looks apparently fixed.


2. Use more universal fonts with larger coverage.

This is a question for YaST team: kbd just contains fonts, YaST defines language -> default console font mapping.


I don't know, whether 2. is done. I am all for simplification of this mapping, using few good fonts with good coverage.


By the way: If you want to look inside kbd fonts, study the coverage, presence of Unicode map etc., you can use this package:

https://build.opensuse.org/package/show?project=graphics&package=psftools
Comment 40 Ancor Gonzalez Sosa 2016-01-13 15:11:11 UTC
(In reply to Stanislav Brabec from comment #39)
> This bug apparently discusses two different problems:

I was trying to restart work on this bug just right now.

> 1. Invalid console setup (bug 904214).
> 
> This looks apparently fixed.

Yes, according to the original bug report, https://build.opensuse.org/request/show/333777 fixed that bug for Tumbleweed quite some time ago. So it should not be affecting the tests.

> 2. Use more universal fonts with larger coverage.
> 
> This is a question for YaST team: kbd just contains fonts, YaST defines
> language -> default console font mapping.
>
> I don't know, whether 2. is done. I am all for simplification of this
> mapping, using few good fonts with good coverage.

That's what the patch referenced above (this one) tries to achieve
https://github.com/yast/yast-country/pull/61/files
But Mindaugas tried the patch and found some issues.
Comment 41 Ancor Gonzalez Sosa 2016-01-13 15:12:55 UTC
(In reply to Mindaugas Baranauskas from comment #35)
> Changing language via YaST don't re-create initrd image, but rebuilding of
> initrd is mandatory to take effect of changed CONSOLE_UNICODEMAP variable.

I'll run some manual tests now and I will add the initrd regeneration and a pop-up telling the user than a reboot is necessary in order to apply the changes if I conclude that effectively that's needed.

(In reply to Stanislav Brabec from comment #36)
> Regarding the patch:
> https://github.com/yast/yast-country/pull/61/files
> 
> You included Serbian locale (sr_RS.UTF-8), which uses Cyrillic. Serbian
> should definitely use font supporting Cyrillic. (In difference to sr@Latin
> locale, which uses Latin alphabet.)

In the patch, I didn't modify anything affecting sr_RS.UTF-8 or sr. I just modified sr_RS@latin which, by definition, uses latin. I'll take care of Cyrillic in future, once we have solved all the issues with latin.
Comment 42 Ancor Gonzalez Sosa 2016-01-13 16:16:17 UTC
Some notes about Mindaugas tests (comments from #25 to #33).

In short it looks like font eurlatgr works nicely as long as CONSOLE_SCREENMAP is set to "none" and it fails in any other case. Isn't it? That's expected, I'd say.

I don't know why you are regenerating initrd and restarting after every change in CONSOLE_SCREENMAP. According to my experiments, restarting systemd-vconsole-setup.service is enough to apply that change.

The biggest problem seems to be that you need to restart systemd-vconsole-setup.service manually because it fails during system startup (so the settings are not applied initially).
Comment 43 Ancor Gonzalez Sosa 2016-01-13 17:49:55 UTC
(In reply to Mindaugas Baranauskas from comment #35)
> A bit more testing with after fresh installed TW 2015-10-22 in VirtualBox.

I did the same tests in real hardware (yes, I'm that brave :-) )

> Changing language via YaST don't re-create initrd image, but rebuilding of
> initrd is mandatory to take effect of changed CONSOLE_UNICODEMAP variable.

As stated in a previous comment, I'm not sure that's actually needed.

> I started to change keyboards via YaST (after each change, I reboot):
> * Lithuanian - good (but there is warnings "Failed to start Setup Virtual
> Console" maybe because of unknown keysym 'quotedblbase' in "lt" keyboard
> speciffically.)
> * English (US) seems good.
> * Canadian (multiling; ca-multix) - then typing à, ç or è - two symbols
> displayed: Ã and some non-letter symbol
> * Purtugal - pressing ç - show ç - correct
> * Slovak - ščťžýáíéňäúô - English keyboard in console, but pressing Right
> Alt + diacritic letter returns à and some non-letter symbol (vconsole-setup
> module warning in in systemd log: cannot open include file
> linux-keys-bare.inc)
> * Slovenian - ž đ š ć - correct (but there is warnings "Failed to start
> Setup Virtual Console" maybe because of unknown keysym 'Omega' and 'omega'
> in "si" keyboard speciffically.)

All the languages are working correctly for me. I'm not getting any vconsole-setup error on startup. My logs look completely sane in that regard.

For the cases in which you experience errors. Does restarting systemd-vconsole-setup help?

> At least with English (US) keyboard, Canadian (multiling)- I don't get any
> warnings/errors about vconsole while booting. For some other languages I
> don't remember well...

The Canadian case is surprising. If there are no systemd-vconsole-setup errors, you should have get eurlatgr and CONSOLE_SCREENMAP=none. And that combination should "just work"(TM). Maybe related to bug#960307? Can you try running this?
  loadkeys ca
Comment 44 Ancor Gonzalez Sosa 2016-01-13 17:57:25 UTC
Some questions to the systemd maintainers

1) What can be the reason for the errors in systemd-vconsole-setup during startup reported by Mindaugas?

2) Which font and screenmap do you get if systemd-vconsole-setup fails? Just the previous used ones (that would hopefully be "eurlatgr" and "none" in most cases) or maybe some default legacy ones (that would probably mean a font not supporting utf8 properly)?
Comment 45 Mindaugas Baranauskas 2016-01-14 09:08:36 UTC
(In reply to Ancor Gonzalez Sosa from comment #43)

I run test in fresh install of TW 2016-01-10 snapshot, applying patches.

Yes, it seems re-creating of initrd after changing language is not necessary.

I newer get any warnings, if I use 
> systemctl stop  systemd-vconsole-setup
> systemctl start systemd-vconsole-setup
But these commands (If I run manually after changing primary language in YaST from Lithuania to Greek) did not affected displaying of typed symbols in console; but simple reboot did affected.

I get warnings at boot, they are different from TW 2015-10-22 snapshot:

With Lithuanian (lt.map.gz):

systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Setup Virtual Console.
systemd[1]: systemd-vconsole-setup.service: Unit entered failed state.
systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'.
systemd-vconsole-setup[92]: cannot open file lt
systemd[1]: Starting Setup Virtual Console...
systemd-vconsole-setup[557]: cannot open file lt
systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Setup Virtual Console.
systemd[1]: systemd-vconsole-setup.service: Unit entered failed state.
systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'.
systemd[1]: Started Setup Virtual Console.

With Sloval (qwertZ) I get strange symbols instead of some letters and warnings at boot:

systemd-vconsole-setup[89]: cannot open include file linux-keys-bare.inc
systemd-vconsole-setup[89]: syntax error, unexpected ERROR
systemd[1]: Starting Setup Virtual Console...
systemd-vconsole-setup[537]: cannot open include file linux-keys-bare.inc
systemd-vconsole-setup[537]: syntax error, unexpected ERROR
systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Setup Virtual Console.
systemd[1]: systemd-vconsole-setup.service: Unit entered failed state.
systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'.
systemd[1]: Started Setup Virtual Console.

Problem Sloval (qwertZ) is maybe because YaST keyboard module Sloval keyboard links with LEGACY (not converted from X keyboards) sk-qwertz.map.gz

With Sloval (qwertY): warnings same as Sloval (qwertZ), but keyboard seems to correctly type and display ščťžýáí... Used sk-qwerty.map.gz is converted from X keyboards.

There is no warnings using: English (US), Canadian (Multilingual), French (Canada).

Others keyboards remains to be tested...

> The Canadian case is surprising. If there are no systemd-vconsole-setup
> errors, you should have get eurlatgr and CONSOLE_SCREENMAP=none. And that
> combination should "just work"(TM). Maybe related to bug#960307? Can you try
> running this?
>   loadkeys ca

If I configured to use Lithuanian language and run `loadkeys ca` in console, keyboard changes to https://bugzilla.suse.com/attachment.cgi?id=660602 and I can succelfully type ¸ + c and result is correct ç
Comment 46 Mindaugas Baranauskas 2016-01-14 09:12:08 UTC
Thought I see "systemd[1]: Failed to start Setup Virtual Console." and "systemd-vconsole-setup: cannot open file lt", I can successfully use Lithuanian keyboard
Comment 47 Mindaugas Baranauskas 2016-01-14 09:38:56 UTC
Regarding notifications about missing files (e.g. "cannot open file lt", "cannot open include file linux-keys-bare.inc"): I suggest they are not included in initrd.

--
Tested two Czech layouts:

1. There is no warning with "Czech", but typing in console displays some strange symbols instead of some letters – maybe because YaST links to legaly KEYMAP=cz-us-qwertz

2. There is no warning with "Czech (QWERTY)" also, but also  some strange symbols instead of some letters – maybe because YaST links to legaly (KEYMAP=cz-lat2-us)

We will need to check, whether  every YaST Keyboard module entry use converted layouts.
Comment 48 Stanislav Brabec 2016-01-14 15:44:00 UTC
Comment 42, Ancor Gonzalez Sosa:

> Some notes about Mindaugas tests (comments from #25 to #33).
>
> In short it looks like font eurlatgr works nicely as long as CONSOLE_SCREENMAP
> is set to "none" and it fails in any other case. Isn't it? That's expected,
> I'd say.

Well, these fonts have its own embedded map. CONSOLE_SCREENMAP is intended for 256-characters fonts without the map. It could work, if you will provide exactly the same map as the font contains. But such map does not exist as a separate file. (There is no reason for it.) If you pick a different one, you will break it.

sudo zypper ar http://download.opensuse.org/repositories/graphics/openSUSE_Tumbleweed/graphics.repo
sudo zypper in psftools
zcat /usr/share/kbd/consolefonts/eurlatgr.psfu.gz | psf2txt | less

> I don't know why you are regenerating initrd and restarting after every change
> in CONSOLE_SCREENMAP. According to my experiments, restarting
> systemd-vconsole-setup.service is enough to apply that change.
>
> The biggest problem seems to be that you need to restart
> systemd-vconsole-setup.service manually because it fails during system
> startup (so the settings are not applied initially).

If I understand correctly, systemd-vconsole-setup.service is started very early in the boot sequence, when system runs from initrd.
Comment 49 Stefan Dirsch 2016-03-02 13:59:49 UTC
Guys, what are the remaining issue here? What are the questions to systemd maintainers exactly?
Comment 50 Liudas Ališauskas 2016-05-15 20:12:33 UTC
Hello everyone.

The error 'systemd-vconsole-setup[557]: cannot open file lt' is caused by missing correct keymap file in /boot/initrd file.

Here are few findings that could help with solution:

1. Listing available keymaps for lithuanian language:

--
[~] localectl list-keymaps | grep "^lt"                                                                                                                                    
lt
lt-ibm
lt-lekp
lt-lekpa
lt-std
lt-us
lt.baltic
lt.l4
lt.std
--

we have several options. Listing keymap files:

--
[~] find /usr/share/kbd/keymaps -name "lt*"                                                                                                                                
/usr/share/kbd/keymaps/xkb/lt-ibm.map.gz
/usr/share/kbd/keymaps/xkb/lt-lekp.map.gz
/usr/share/kbd/keymaps/xkb/lt-lekpa.map.gz
/usr/share/kbd/keymaps/xkb/lt-std.map.gz
/usr/share/kbd/keymaps/xkb/lt-us.map.gz
/usr/share/kbd/keymaps/xkb/lt.map.gz
/usr/share/kbd/keymaps/legacy/i386/azerty/lt.std.map.gz
/usr/share/kbd/keymaps/legacy/i386/qwerty/lt.baltic.map.gz
/usr/share/kbd/keymaps/legacy/i386/qwerty/lt.l4.map.gz
/usr/share/kbd/keymaps/legacy/i386/qwerty/lt.map.gz
--

2. Choosing Lithuanian as default language in Yast2 -> Languages, and selecting "Adapt Keyboard Layout to Lithuanian" writes "KEYMAP=lt" option into /etc/vconsole.conf file

--
[~] cat /etc/vconsole.conf                                                                                                                                                 
KEYMAP=lt
--

and 'mkinitrd' command is executed which generates /boot/initrd file (initramfs) with keymap file against KEYMAP=lt option.

3. Extracting keymap file from generated initrd file shows that possibly wrong file () is included:

--
initrd/usr/share/kbd/keymaps/legacy/i386/azerty/lt.std.map
--

4. That why we have error "systemd-vconsole-setup[xx]: cannot open file lt" - systemd-vconsole-setup.servise tries load missing file.

5. If we change "KEYMAP=lt" option to "KEYMAP=lt-us" in /etc/vconsole.conf file

--
[~] cat /etc/vconsole.conf                                                                                                                                                 
KEYMAP=lt-us
--

and run command 'mkinitrd' manually - now initrd contains correct file:

--
initrd/usr/share/kbd/keymaps/xkb/lt.map
--

and no systemd-vconsole-setup.servise errors on "missing files".

6. Conclution:

- mkinitrd command inserts incorrect keymap file from /usr/share/kbd/keymaps/* folder into initramfs file while reading /etc/vconsole.conf option KEYMAP=lt;
- due to this systemd-vconsole-setup.servise tries load missing file and we have error (root file system is not loaded yet);
- later (when system is loaded) if we run 'systemctl restart systemd-vconsole-setup.service' manually we have no error because file system is mounted and we have correct file available in /usr/share/kbd/keymaps/* folder;

we should look deeper why mkinitrd takes incorrect keymap file lt.std.map.gz instead of lt.map.gz and inserts it info initramfs file. It could be parser pattern lt[dot].

7. I have tried run 'mkinitrd' with KEYMAP=lt option while moved /usr/share/kbd/keymaps/legacy/ folder away - correct keymap file is transferred into initramfs and no error from systemd-vconsole-setup.servise.

Hope this will be useful.
Comment 51 Fabian Vogt 2016-06-16 12:46:37 UTC
> [~] find /usr/share/kbd/keymaps -name "lt*"                                 
[...]
> - mkinitrd command inserts incorrect keymap file from
> /usr/share/kbd/keymaps/* folder into initramfs file while reading
> /etc/vconsole.conf option KEYMAP=lt;
[...]
> we should look deeper why mkinitrd takes incorrect keymap file lt.std.map.gz
> instead of lt.map.gz and inserts it info initramfs file. It could be parser
> pattern lt[dot].

This is exactly what happens in /usr/lib/dracut/modules.d/10i18n/module-setup.sh:
https://github.com/dracutdevs/dracut/blob/master/modules.d/10i18n/module-setup.sh#L34
adding dracut maintainer to CC.

I guess that it should rather be

find ${kbddir}/keymaps -type f -name ${MAP} -o -name ${MAP}.map -o -name ${MAP}.map.\* | head -n1

AFAICS theres a potential similiar bug in the find call a few lines later as well.
Comment 52 Ancor Gonzalez Sosa 2016-06-17 10:39:15 UTC
After reading all the comments again.

Some facts, correct me if I'm wrong:

a) During boot, keyboard and console fonts are applied by systemd-vconsole-setup.service

b) Changing the keyboard map implies updating the KEYMAP variable in /etc/vconsole.conf and regenerating initrd. That's what YaST does.

c) In (open)SUSE, changing the console font implies updating /etc/sysconfig/console. That's what YaST does.

d) Just for you to know (and because I'm sure it will bite us at some point), in other systems the console fonts are controlled via a FONT variable in /etc/vconsole.conf instead of using /etc/sysconfig/console. That's more consistent with the keyboard management but out of the scope for now.


These are my conclusions about the current status if this bug:

1) The new mappings proposed in https://github.com/yast/yast-country/pull/61/files are mainly ok. Which means that using YaST with that patch sets the right values in /etc/sysconfig/console (i.e. eurlatgr with no modifier for most languages)

2) systemd-vconsole-setup.service should then read those values and apply them.

 2.a) YaST should restart the service after changing the values to immediately apply the changes. That is not happening, but I can fix it.

 2.b) On a system start, systemd-vconsole-setup.service will be run in a very early stage and apply the changes.

3) If we also change the keyboard map, then /etc/vconsole.conf is changed and initrd is regenerated. That's fine... in theory.

4) Due to a bug in dracut, the initrd generated in (3) is getting broken (keymap not included in the image) which is causing systemd-vconsole-setup.service execution to fail which means the console fonts are never applied.


So in order to completely fix the bug we need to fix dracut and, as a bonus track, ensure YaST restarts systemd-vconsole-setup.service after changing the font.

Anybody reader disagrees with my conclusions?  If not, I will submit the new mappings right away and will start implementing the systemd-vconsole-setup.service restart.

Should we open a separate bug report for dracut?
Comment 53 Ludwig Nussel 2016-06-17 11:03:03 UTC
(In reply to Ancor Gonzalez Sosa from comment #52)
> After reading all the comments again.

Thanks!

> [...]
> d) Just for you to know (and because I'm sure it will bite us at some
> point), in other systems the console fonts are controlled via a FONT
> variable in /etc/vconsole.conf instead of using /etc/sysconfig/console.
> That's more consistent with the keyboard management but out of the scope for
> now.

Ack. At least it should be one place, no matter which.

> Should we open a separate bug report for dracut?

Yes please. This bug is crowded enough :-)
Comment 54 Fabian Vogt 2016-06-17 11:06:05 UTC
(In reply to Ancor Gonzalez Sosa from comment #52)
> After reading all the comments again.
> 
> Some facts, correct me if I'm wrong:
> 
> a) During boot, keyboard and console fonts are applied by
> systemd-vconsole-setup.service
> 
> b) Changing the keyboard map implies updating the KEYMAP variable in
> /etc/vconsole.conf and regenerating initrd. That's what YaST does.

The keymap can also be set in /etc/sysconfig/keyboard.

> c) In (open)SUSE, changing the console font implies updating
> /etc/sysconfig/console. That's what YaST does.
> 
> d) Just for you to know (and because I'm sure it will bite us at some
> point), in other systems the console fonts are controlled via a FONT
> variable in /etc/vconsole.conf instead of using /etc/sysconfig/console.
> That's more consistent with the keyboard management but out of the scope for
> now.

/etc/vconsole.conf is read by systemd-vconsole-setup as well.
Values in there overwrite values set in /etc/sysconfig/{keyboard,console}.
For reference: https://github.com/openSUSE/systemd/blob/openSUSE-Factory/src/vconsole/vconsole-setup.c#L419

> These are my conclusions about the current status if this bug:
> 
[...]
> 
>  2.b) On a system start, systemd-vconsole-setup.service will be run in a
> very early stage and apply the changes.

During initrd, usually only one vconsole is active, tty1.
systemd-vconsole-setup during initrd only sets up tty1,
while the other ttys are set up by a udev rule calling systemd-vconsole-setup
only for the new vconsole.
For the dracut bug, that means that even if the initrd had the wrong file,
tty2-ttyX should have the right keymap set already.

> 3) If we also change the keyboard map, then /etc/vconsole.conf is changed
> and initrd is regenerated. That's fine... in theory.
> 
> 4) Due to a bug in dracut, the initrd generated in (3) is getting broken
> (keymap not included in the image) which is causing
> systemd-vconsole-setup.service execution to fail which means the console
> fonts are never applied.
> 
> 
> So in order to completely fix the bug we need to fix dracut and, as a bonus
> track, ensure YaST restarts systemd-vconsole-setup.service after changing
> the font.
> 
> Anybody reader disagrees with my conclusions?  If not, I will submit the new
> mappings right away and will start implementing the
> systemd-vconsole-setup.service restart.
>
> Should we open a separate bug report for dracut?

I guess the issue in dracut is a bit too far from the original issue here, so yes please.
I'll make a patch for dracut meanwhile and submit it with the right bug reference then.
Comment 55 Fabian Vogt 2016-06-17 11:44:07 UTC
Bug in dracut should be fixed, testing welcome: https://build.opensuse.org/package/show/home:favogt:branches:Base:System/dracut

I'll just use this bug for submission now.
Comment 56 Stefan Dirsch 2016-08-08 10:58:58 UTC
(In reply to Fabian Vogt from comment #55)
> Bug in dracut should be fixed, testing welcome:
> https://build.opensuse.org/package/show/home:favogt:branches:Base:System/
> dracut
> 
> I'll just use this bug for submission now.

Please go ahead! Anything else still missing here?
Comment 57 Fabian Vogt 2016-08-08 11:25:25 UTC
(In reply to Stefan Dirsch from comment #56)
> (In reply to Fabian Vogt from comment #55)
> > Bug in dracut should be fixed, testing welcome:
> > https://build.opensuse.org/package/show/home:favogt:branches:Base:System/
> > dracut
> > 
> > I'll just use this bug for submission now.
> 
> Please go ahead! Anything else still missing here?

The fix is in TW for a couple of weeks now: https://build.opensuse.org/request/show/406416
Somehow the bot did not add a comment here.
Comment 58 Bernhard Wiedemann 2016-08-26 16:00:35 UTC
This is an autogenerated message for OBS integration:
This bug (942896) was mentioned in
https://build.opensuse.org/request/show/423138 42.2 / yast2-country
Comment 59 Mindaugas Baranauskas 2016-08-27 17:25:13 UTC
I tested fresh install of latest openSUSE TW.
There is no longer problems with Lithuanian :)

I suggested to try some other language and selected Slovak in YaST. Strange, that in KDE (while typing keys of upper line) I get +ľščťžýáíé=, but in console I get +µ¹è»¾ýáíé=. Seems that we should check some languages more robustly...
Comment 60 Mindaugas Baranauskas 2016-08-27 18:03:00 UTC
I suggest this is because "Slovak" points (by keyboard_raw.ycp) to legacy keyboard layout (/usr/share/kbd/keymaps/legacy/i386/qwertz/sk-qwertz.map.gz), it should use some converted layout.

I checked keyboard_raw.ycp and found, that some other YaST keyboards points to outdated layouts also:

"czech":
/usr/share/kbd/keymaps/legacy/i386/qwertz/cz-us-qwertz.map.gz

"czech-qwerty":
/usr/share/kbd/keymaps/legacy/i386/qwerty/cz-lat2-us.map.gz

"portugese-br":
/usr/share/kbd/keymaps/legacy/i386/qwerty/br-abnt2.map.gz

"dvorak":
/usr/share/kbd/keymaps/legacy/i386/dvorak/dvorak.map.gz

Some languages with symlinks:

"arabic":
/usr/share/kbd/keymaps/legacy/i386/qwerty/arabic.map.gz ->
/usr/share/kbd/keymaps/legacy/i386/qwerty/us.map.gz

"khmer":
/usr/share/kbd/keymaps/legacy/i386/qwerty/khmer.map.gz ->
/usr/share/kbd/keymaps/legacy/i386/qwerty/us.map.gz 

These also, but seems they will not use eurlatgr:

"greek":
/usr/share/kbd/keymaps/legacy/i386/qwerty/gr.map.gz

"russian":
/usr/share/kbd/keymaps/legacy/i386/qwerty/ruwin_alt-UTF-8.map.gz

"serbian":
/usr/share/kbd/keymaps/legacy/i386/qwerty/sr-cy.map.gz

"ukrainian":
/usr/share/kbd/keymaps/legacy/i386/qwerty/ua-utf.map.gz

"tajik":
/usr/share/kbd/keymaps/legacy/i386/qwerty/tj_alt-UTF8.map.gz
Comment 61 Mindaugas Baranauskas 2016-08-28 10:05:59 UTC
According /usr/share/systemd/kbd-model-map , I suggest new keymaps should be:

"czech":
cz.map.gz

"czech-qwerty":
cz-qwerty.map.gz

"portugese-br":
br-nativo.map.gz

"dvorak":
us-dvorak.map.gz
or
us-dvorak-alt-intl.map.gz

I a bit played and I see, that both using Czech new console layout, I can use AltGr to enter some symbols from US keyboard (like @#&*), i.e. without withing keyboards!
Note, that I am not user of these keyboards and real users should test!
Comment 62 Mindaugas Baranauskas 2016-08-29 05:58:35 UTC
and "Slovak" should point to:
sk.map.gz

I suggest these keyboards (and "slovak-qwerty") no longer need 
"compose" : "latin2"
in /usr/share/YaST2/data/keyboard_raw.ycp
Comment 63 Mindaugas Baranauskas 2016-08-29 12:37:28 UTC
OK, created new pull request:
https://github.com/yast/yast-country/pull/84
Comment 64 Marcelo Junior 2016-08-31 02:22:11 UTC
(In reply to Mindaugas Baranauskas from comment #63)
> OK, created new pull request:
> https://github.com/yast/yast-country/pull/84

I made a pull request in your pull request!

https://github.com/embar-/yast-country/pull/1

br-nativo.map.gz is a Dvorak layout (Almost no one uses)

A keyboard "portugese-br" should use the layout br.map.gz and a
keyboard "brazilian-dvorak" or "portuguese-br-devotak" should use
br-nativo.map.gz
Comment 65 Mindaugas Baranauskas 2016-08-31 10:12:31 UTC
(In reply to Marcelo Junior from comment #64)
> I made a pull request in your pull request!

Thanks, patch included in patch
Comment 66 Ancor Gonzalez Sosa 2016-09-12 11:16:18 UTC
The patch breaks automated tests. I will take a look and (hopefully) fix the problem.
Comment 67 Ancor Gonzalez Sosa 2016-09-12 12:28:57 UTC
I fixed the problems with the original pull request. I created a separate one to avoid too much branching in git history and delay in the merge process. Please check.
https://github.com/yast/yast-country/pull/85

On the other hand, I would like to use either fate#318355 either separate bug reports to track errors in the new keymap definitions (and related pull requests).

This bug should be about fonts (you now, using "eurlatgr" and all that) and has become a hotchpotch of keymaps, dracut, fonts and whatsnot.

Thanks.
Comment 68 Ancor Gonzalez Sosa 2016-09-12 13:52:57 UTC
Submit request for the mentioned pull request https://build.opensuse.org/request/show/427014
Comment 69 Mindaugas Baranauskas 2016-09-12 14:28:23 UTC
Yes, bug encompass many components. I agree, some needed separate bugs. Problem was (and perhaps maybe still _is_ for some keyboards/languages) that YaST assign font by locale, but in reality font should match by keyboard layout. As openSUSE now provides converted layouts (they use unicode), we can simply switch to unicode fonts.

Now remaining tasks is to check Greek, Cyrillic and Turkish layouts: 
- whether we can change font to eurlatgr for Greek;
- whether we can change font to (more up-to-date?) LatArCyrHeb-14, LatArCyrHeb-16+ or LatArCyrHeb-16 for Cyrillic in consolefonts.ycp;
- whether we need to change some console keyboards in keyboard_raw.ycp (especially if old kbd keyboard's names also exist as new/converted console keyboards);
- whether we should leave as is.
Comment 70 Mindaugas Baranauskas 2016-09-12 15:48:05 UTC
Greek seems not have converted console keyboard layout (at least now in openSUSE) – only legacy provided (strange)... So we should leave as is now. (How Fedora and other distros resolved this?)

All Cyrillic layouts now use UniCyr_8x16.psf font, but this font seems to be compatible with cp866, cp1251, iso8859-5 and koi8-r (according http://www.tldp.org/HOWTO/Belarusian-HOWTO/x28.html) and not compatible with unicode per se. But openSUSE seems don't provide converted layouts for Russian, Ukrainian, Serbian, Bulgarian, Tajik. So we should leave as is now.

Turkish console is now associated with tr.map.gz (converted/unicode) keyboard and iso09.f16n font. We need test, whether such combination results in incorrectly displayed symbols. As Turkish use Latin alphabet, I suggest we can switch to eurlatgr.
Comment 71 Mindaugas Baranauskas 2016-09-12 16:04:31 UTC
I suggest, that after finishing with Turkish, we could close this bug.
Comment 72 Mindaugas Baranauskas 2016-09-12 18:30:11 UTC
I played with Turkish keyboard in console in openSUSE TW.
Same good results after switching to either iso09.f16n or either eurlatgr 
with critical letters
ğ ü ş i ı ö ç Ğ Ü Ş İ I Ö Ç 
(when I type new text).
(e.g. http://www.dsi-keyboards.com/wp-content/uploads/2015/03/KA-TurkishQ-20844.jpg)

New patch https://github.com/yast/yast-country/pull/86
Comment 73 Mindaugas Baranauskas 2016-09-12 19:14:00 UTC
I see that exist request to include switching to eurlatgr 
(for all languages with latin alphabet) into openSUSE Leap 42.2:
https://build.opensuse.org/request/show/423138

If we push these changes for openSUSE Leap 42.2, we must upgrade kbd package!
Current openSUSE Leap 42.2 beta1 provides kbd 1.15.5, but
eurlatg font introduced only in kbd 2.0.2.
(openSUSE Tumbleweed provides kbd 2.0.3)
Comment 74 Ancor Gonzalez Sosa 2016-09-13 07:36:47 UTC
Turkish pull request submitted to Tumbleweed as
https://build.opensuse.org/request/show/427205
Comment 75 Ancor Gonzalez Sosa 2016-09-13 08:01:49 UTC
Submit request superseded  to fix a detected typo in changelog. New SR
https://build.opensuse.org/request/show/427211
Comment 76 Mindaugas Baranauskas 2016-09-13 11:38:34 UTC
Closing as now all languages/keyboards with Latin alphabets (currently supported by YaST) use eurlatgr with yast2-country 3.1.32.

Ideally [as other bugs/features], there is still place to continue: 
- enable converting some non-Latin keyboards in kbd and change fonts (and perhaps preconfiguring swiching between native and US QWERTY in console?);
- generate (or at least append) consolefonts.ycp file with all converted from X Latin keyboards automatically during build of yast2-country.
Comment 77 Bernhard Wiedemann 2016-09-15 16:01:00 UTC
This is an autogenerated message for OBS integration:
This bug (942896) was mentioned in
https://build.opensuse.org/request/show/427961 42.2 / yast2-country
Comment 78 Swamp Workflow Management 2017-03-03 20:12:18 UTC
SUSE-RU-2017:0604-1: An update that has 9 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1009508,1016004,1020082,1022094,942896,942899,960307,968183,981008
CVE References: 
Sources used:
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    yast2-country-3.1.35-9.11.1
SUSE Linux Enterprise Server 12-SP2 (src):    yast2-country-3.1.35-9.11.1
SUSE Linux Enterprise Desktop 12-SP2 (src):    yast2-country-3.1.35-9.11.1