Bug 1225991

Let's check if there are any errors in the logs.

Please attach y2logs generated with the supplied 'save_y2logs' script. Notice that you don't have to do the installation again for that; the logs still contain the installation, even if there already was a log rotation.

See also
  
https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug,_and_now_I_am_asked_to_"attach_y2logs"_(for_package_installation_also_"libzypp_logging")._What_does_that_mean,_and_how_do_I_do_that?

1) Configuration with YasT2:

yast2 language
WARNING: Nokogiri was built against LibXML version 2.9.14, but has dynamically loaded 2.10.3
MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
glx: failed to create drisw screen
failed to load driver: zink

    Primary language Norwegian


yast2 keyboard
WARNING: Nokogiri was built against LibXML version 2.9.14, but has dynamically loaded 2.10.3
MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
glx: failed to create drisw screen
failed to load driver: zink

System Keyboard Configuration Norwegian

Test: ;'[ 
where it should be: øæå


2) Configuration with Gnome settings:

Region og språk 
Konto og pålogging: Norsk bokmål

Tastatur Norwegian (first) 
         English (US) (second) 

Tastatur Norwegian f;rst English US under

Created attachment 875323 [details]
y2logs

During installation:

(from macro_inst_initial.ycp)

>> UI::ChangeWidget( `id ("Y2Country::Widgets::KeyboardSelectionCombo"),
>>                   `Value, "english-us" );	// YComboBox "Keyboard Layout"


y2log:

>> 00:06:46 <1> [Ruby] bin/y2start(<main>):22 y2base called with ["installation", "--arg", "initial", "qt", "--noborder", "--auto-fonts", "--fullscreen"]
...
...
>> 20:07:31 <1> [Ruby] modules/Keyboard.rb(GetKeyboardForLanguage):92 Suggest keyboard english-us for language en_US
>> 20:07:31 <1> [Ruby] modules/Keyboard.rb(Set):158 set to english-us
>> 20:07:31 <1> [Ruby] lib/cheetah.rb(record_commands):160 Executing "/usr/sbin/xkbctrl us".
>> 20:07:31 <1>    $[
>> 20:07:31 <1>       "XkbLayout"    : "us",
>> 20:07:31 <1>       "XkbModel"     : "microsoftpro",
>> 20:07:31 <1>       "XkbOptions"   : "terminate:ctrl_alt_bksp",
>> 20:07:31 <1>       "Apply"        : "-layout us -model microsoftpro -option terminate:ctrl_alt_bksp"
>> 20:07:31 <1>    ]
>> 20:07:31 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0
>> 20:07:31 <1> [Ruby] lib/cheetah.rb(record_commands):160 Executing "/usr/bin/setxkbmap -layout us -model microsoftpro -option terminate:ctrl_alt_bksp".
>> 20:07:31 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0
...
...
>> 00:31:40 <1> [librpmDb] RpmDb.cc(doInstallPackage):1705 RpmDb::installPackage(
>>   /mnt/var/cache/zypp/packages/openSUSE-Leap-15.6-1/x86_64/kbd-2.4.0-150400.5.6.1.x86_64.rpm,0x0000040c)
>> 00:31:40 <1> [zypp::exec++] forkspawnengine.cc(start):274 Executing[C] 'rpm' '--root' '/mnt' '--dbpath' '/var/lib/rpm'
>>   '-U' '--percent' '--noglob' '--force' '--nodeps' '--noposttrans' '--'
>>   '/mnt/var/cache/zypp/packages/openSUSE-Leap-15.6-1/x86_64/kbd-2.4.0-150400.5.6.1.x86_64.rpm'


So, the installation language was English, and the US keyboard layout was suggested accordingly and not changed, so the system was installed with the US keyboard layout.

But the 'kbd-2.4.0' package was installed (and kbd-legacy as well), so the infrastructure for a different keyboard layout was there.

Later in the installed system:

>> 10:39:32 <1> [Ruby] bin/y2start(<main>):22 y2base called with ["keyboard", "qt", "-name", "YaST2", "-icon", "yast"]
...
...
>> 10:39:33 <1> [Ruby] lib/cheetah.rb(record_commands):160 
>>              Executing "localectl status".
>> 10:39:33 <1>    System Locale: LANG=nb_NO.UTF-8
>> 10:39:33 <1>        VC Keymap: no
>> 10:39:33 <1>       X11 Layout: no
>> 10:39:33 <1>        X11 Model: pc105
>> 10:39:33 <1>      X11 Options: terminate:ctrl_alt_bksp
>> 10:39:33 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0

(This is the last one of repeated invocations of "yast2 keyboard")

The 'no' keyboard layout was selected, and 'localectl' confirmed it.
This looks okay from the YaST side.

First invocation of "yast2 keyboard":

>> 00:56:13 <1> [Ruby] bin/y2start(<main>):22 y2base called with ["keyboard", "qt", "-name", "YaST2", "-icon", "yast"]
...
...
>> 00:56:13 <1> [Ruby] lib/cheetah.rb(record_commands):160 Executing "localectl status".
>> 00:56:13 <1>    System Locale: LANG=en_US.UTF-8
>> 00:56:13 <1>        VC Keymap: us
>> 00:56:13 <1>       X11 Layout: us
>> 00:56:13 <1>        X11 Model: pc105+inet
>> 00:56:13 <1>      X11 Options: terminate:ctrl_alt_bksp
>> 00:56:13 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0
>>
>> 00:56:23 <1> [Ruby] lib/cheetah.rb(record_commands):160 Executing "/usr/sbin/xkbctrl no".
>> 00:56:23 <1>    $[
>> 00:56:23 <1>       "XkbLayout"    : "no",
>> 00:56:23 <1>       "XkbModel"     : "microsoftpro",
>> 00:56:23 <1>       "XkbOptions"   : "terminate:ctrl_alt_bksp",
>> 00:56:23 <1>       "Apply"        : "-layout no -model microsoftpro -option terminate:ctrl_alt_bksp"
>> 00:56:23 <1>    ]
>> 00:56:23 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0
>>
>> 00:56:23 <1> [Ruby] lib/cheetah.rb(record_commands):160
>>              Executing "/usr/bin/setxkbmap -layout no -model microsoftpro -option terminate:ctrl_alt_bksp".
>> 00:56:23 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0
>>
>> 00:56:26 <1> [Ruby] lib/cheetah.rb(record_commands):160
>>              Executing "localectl set-keymap no".
>> 00:56:26 <1> [Ruby] lib/cheetah.rb(record_status):180 Status: 0

This is where the keyboard was switched from 'en_US' to 'no'.

From the 'journalctl-b' file of the attached y2logs:

>> Jun 05 14:03:22 localhost.localdomain systemd-localed[1313]:
>>   The virtual console keymap 'no' is converted to X11 keyboard layout 'no'
>>   model 'pc105' variant '' options 'terminate:ctrl_alt_bksp'
...
...
>> Jun 05 12:04:31 localhost.localdomain systemd[1]:
>>   systemd-localed.service: Deactivated successfully.

Yes, the messages are really in that order, despite the timestamps.

I am not sure about the significance of that second message "systemd-localed.service: Deactivated successfully". I hope it means that the service has done its duty and is now finished.

But the first message looks like the 'no' keyboard was correctly configured.

Created attachment 875331 [details]
Screenshot: Testing keyboard layouts

I just booted into a Leap 15.6 installation running in a VirtualBox VM.

I tested the same 3 keys repeatedly with different keyboard layouts: The two right to the normal letter keys here:
      
      U  I  O  P  [
    H  J  K  L  ;  '

I started with US (;'[), then Norwegian, Swedish, Danish, and Norwegian again. AFAICS they all worked as expected; see screenshot.

The ISO I used was  openSUSE-Leap-15.6-DVD-x86_64-Build709.1-Media.iso.

Could you try to boot into the installation medium again and try again directly from the first interactive installation dialog (as in this screenshot)? Does it behave differently than what you experienced in the installed system? Does it work here or not?

Of course, don't execute the installation, just test the keyboard and when you are done simply reboot. Your system will not be changed.

First, due to a mid collision I lost my last comment and repeat it here.

After yet another Gnome login, the No keyboard worked. This happened also late last night after some some logins after the initial installation. 
But after a new login today, the US keyboard was back again, and I posted this bug report.

I checked the current keyboard layout with the setxkbmap -query command:

setxkbmap -query
rules:      evdev
model:      pc105
layout:     no,us,us
variant:    ,,
options:    terminate:ctrl_alt_bksp

In case some conditional switching happends between the No (first) and US (second) kb config, I "removed" the US (second) layout from the Gnome keyboard settings.

Then again I checked with the same command which the output:

setxkbmap -query
rules:      evdev
model:      microsoftpro
layout:     no,us
variant:    ,
options:    terminate:ctrl_alt_bksp

To mentione, I have currently a triple boot installation on the same workstation:
LP15.5 + Slowroll + LP15.6, and haven't had issue with the keyboard settings before.

----------------------

So to your two last comments and suggestion.
I booted my openSUSE-Leap-15.6-DVD-x86_64709 USB medium and tested the keyboard configs. Yes, the No layout worked correctly included the special ø æ å keys.

I just went through with the installation (with US keyboard) with a standard software selection, then in GNOME I started a terminal window, and it had the US keyboard.

Starting YaST, I switched to the Norwegian keyboard. In the YaST control center (a very simple Qt-only program, zero YaST code in it) I tried the letters from comment #8, and I had Norwegian.

But in the GNOME terminal it was still US, even when exiting it and starting a fresh one. Same when starting Firefox. Starting an xterm gave me the Norwegian keyboard again.

So it's clearly something in GNOME.

And sure enough, in the GNOME settings (will attach screenshot), there was still only the US keyboard layout configured. But you can add another one (with the "+" button), scroll down for "more" and select one of several Norwegian options.

Created attachment 875335 [details]
GNOME Settings

I don't know if there is an easier way to get to this (happy Xfce user here), but clicking the "network" icon on the top status bar and then on the "settings" icon is one way to do it.

Created attachment 875336 [details]
Screenshot: Added the Norwegian keyboard layout to the GNOME settings

Obviously GNOME uses its own keyboard settings that only affect GNOME applications (which include Firefox) by default, and they override the system-wide settings.

KDE behaves in a similar way, but IIRC they default to the system-wide keyboard settings, not just always US. But this may be a bug in this specific GNOME version.

Created attachment 875337 [details]
Screenshot: GNOME statusbar with keyboard layout switcher

After adding the Norwegian keyboard layout with the GNOME settings, I now have this "no" keyboard switcher in the status bar.

I still find it weird that GNOME does not detect the system-wide keyboard layout setting initially.

Maybe it has to do with installing in English and with a US keyboard layout, and changing this later from within a GNOME session with YaST. At what point would GNOME pick up the system-wide settings? Only upon its first start, when it initializes your personal GNOME configuration files?

The weirdest part was that after changing it with YaST, simple Qt applications like the YaST control center worked correctly (i.e. using the Norwegian keyboard layout), and even ancient X programs like xterm. There seems to be a disconnect (at least in this GNOME version) between GNOME / Gtk applications and the system-wide keyboard settings.


-> Moving to the GNOME maintainers.

Just a side note: Changing the keyboard through YaST Keyboard means that the system keyboard (root, login at console, etc.) is changed. If some user has their own keyboards configured, it's written to their /home(s) and the system settings should not have an effect on it. On a multi-user system, it would not make sense to change a language/keyboard for everyone. Plus YaST must not write to user's /home(s).

For what it is worth;
I also did a login to the Gnome desktop as root user.
Checked and found that both yast2 keyboard and Gnome setting keyboard were set to Norwegian, and no optional US layout was shown.

@Lukas:

True, but I observed that it depends on an application's widget toolkit: Ancient xterm had the Norwegian keyboard, also our Qt-only YaST control center. GNOME (Gtk) applications did not, neither the GNOME terminal nor Firefox.

No matter in which direction this is broken, broken it is. It should be consistent on the same desktop, not different depending on what widget toolkit was used. Users cannot be expected to know the difference, or to care how or why. If it runs on the same desktop, basic things like the keyboard layout should work the same.

(In reply to Stefan Hundhammer from comment #15)
> I still find it weird that GNOME does not detect the system-wide keyboard
> layout setting initially.
> 
> Maybe it has to do with installing in English and with a US keyboard layout,
> and changing this later from within a GNOME session with YaST. 
In my opinion, GNOME's language and keyboard is designed to be changed in gnome-control-center(g-c-c). When administer create new user, he also could assign the language in g-c-c before the user login.

> At what point
> would GNOME pick up the system-wide settings? Only upon its first start,
> when it initializes your personal GNOME configuration files?
In my opinion, GNOME don't pick system-wide setting, in the first start of system installation and new user login after system installation, GNOME is designed to launch gnome-initial-setup(g-i-s) for the user and system to assign their language and keyboard. but in the past several SLE editions, we dropped the g-i-s as the project managers and product managers require.
If you or some other users consider this function necessary, we can try to add the g-i-s back.

> 
> The weirdest part was that after changing it with YaST, simple Qt
> applications like the YaST control center worked correctly (i.e. using the
> Norwegian keyboard layout), and even ancient X programs like xterm. There
> seems to be a disconnect (at least in this GNOME version) between GNOME /
> Gtk applications and the system-wide keyboard settings.
In my opinions, QT has its ideas and designs. but GNOME also has theirs. Different user in GNOME have different settings, GNOME leave the choose right to the user himself. There is no insure that GNOME's behavior should be the same with QT. As above comments, gnome use g-i-s and g-c-c, no relevant with system-wide setting.
Thank you!

I believe that the issue is within 'xdm' package. It contains a script /etc/X11/xdm/keytable, which is executed during display-manager.service start. This script overrides locale settings by issuing 'localectl set-locale us' command.
This is unacceptable behavior, xdm should honor X11-related settings in /etc/vconsole.conf and not override them if those options exist.
However, there is another bug with applications running on top of Xwayland ignoring system keyboard layout, I am not sure what is the case of that.

Please note that for those who need non-latin keyboard layouts this issue might be critical.

(In reply to Terje J. Hanssen from comment #0)
> Neither during fresh installation of Leap 15.6 (GM) or afterwards with YaST2
> or with Gnome Settings, Norwegian configuration doesn't

Based on Stefan's comment11, Yast works;
GNOME don't related to it as I commented on comment19;
Iakov think this is in 'xdm', but xdm is out of this bug's scope as comment0. If Iakov thinks xdm should have this function, please open new bug.
So I will close this bug as 'won't fix'. Thank you everyone.

See also bug #1226387 (duplicate or just very similar?) using KDE Plasma

(In reply to Cliff Zhao from comment #19)
> > At what point
> > would GNOME pick up the system-wide settings? Only upon its first start,
> > when it initializes your personal GNOME configuration files?
>
> In my opinion, GNOME don't pick system-wide setting, in the first start of
> system installation and new user login after system installation, GNOME is
> designed to launch gnome-initial-setup(g-i-s) for the user and system to
> assign their language and keyboard. but in the past several SLE editions, we
> dropped the g-i-s as the project managers and product managers require.

Cliff, do you have a Jira ID at hand for this? It sounds very much like that change is responsible for this observed behavior here in this case, and in that other bug using KDE Plasma.

IMHO this was a big step back in usability. As those two bugs show, users expect (as they should) their configuration that they did during installation to be reflected in their user desktop setup in the installed system.