Bug 897803

Please provide YaST logs, see http://en.opensuse.org/openSUSE:Bugreport_YaST.

Created attachment 607685 [details]
YaST2 Logs

Please attach also your /etc/sysconfig/keyboard.

Created attachment 608972 [details]
mcatanzaro y2logs

I can reproduce this reliably when installing using the GNOME live CD (openSUSE 13.2 build 0011): I selected the Dvorak keyboard layout at install time, but the installed system was set to qwerty. Note that this bug makes it almost impossible to log into the installed system if autologin is disabled: only the qwerty layout is enabled, but the user cannot possibly know this as gdm only indicates the active keyboard layout if at least two layouts are enabled on the system.

This bug does NOT occur when using the install DVD (also build 0011) instead of the live CD.

Furthermore, localectl seems to be broken, which makes it very difficult to fix the keyboard layout by switching to a VT. 'localectl set-keymap dvorak' should change both the VT and X11 keymap to dvorak unless the --no-convert flag is passed, but in openSUSE it only affects the VT keymap. This may be a separate bug, but I suspect it is related.

If autologin is enabled when installing (as in these attached logs) then you don't have to worry about logging in. The Region & Language panel in System Settings (gnome-control-center) correctly indicates the keyboard layout is English (US) instead of Dvorak, and you can change it to Dvorak successfully from this panel, but changes in this panel are not reflected in localectl or /etc/sysconfig/keyboard! Furthermore, if you then change the keyboard layout back to qwerty using the YaST panel, the changes will take effect and will be reflected in localectl but not System Settings.

Guess: It looks like there is a problem with the SUSE-specific logic that presumably exists to teach localed to read /etc/sysconfig/keyboard instead of the upstream location /etc/locale.conf.

Created attachment 608973 [details]
/etc/sysconfig/keyboard

After installation, the VT keymap is Dvorak but the X11 keymap incorrectly set to qwerty. Changing the keymap to Dvorak in System Settings results in no changes to /etc/sysconfig/keyboard.

As for michael Catanzaro's case:

YaST calls 
/bin/loadkeys dvorak.map.gz and 
/usr/bin/setxkbmap -model microsoftpro -layout dvorak

And it saves dvorak to /etc/sysconfig/keyboard as well.

Seems to me, YaST does all that it should and some other system part is not able to use this information. Stefan?

Jiri, would be nice if you used the needinfo feature instead of reassigning ;)

(In reply to Jiri Suchomel from comment #6)
> As for michael Catanzaro's case:
> 
> YaST calls 
> /bin/loadkeys dvorak.map.gz and 
> /usr/bin/setxkbmap -model microsoftpro -layout dvorak
> 
> And it saves dvorak to /etc/sysconfig/keyboard as well.
> 
> Seems to me, YaST does all that it should and some other system part is not
> able to use this information. Stefan?

A configuration set with /usr/bin/setxkbmap is volatile ie. for the running Xserver only. It is written nowhere.
The UI keyboard layout is expected to be done using your desktop UI - we don't write a static X keyboard configuration any more.

(In reply to Jiri Suchomel from comment #6)
> As for michael Catanzaro's case:
> 
> YaST calls 
> /bin/loadkeys dvorak.map.gz and 
> /usr/bin/setxkbmap -model microsoftpro -layout dvorak
> 
> And it saves dvorak to /etc/sysconfig/keyboard as well.
> 
> Seems to me, YaST does all that it should and some other system part is not
> able to use this information. Stefan?

But then why does YaST save "us" instead of "dvorak"?

/etc/sysconfig/keyboard
[...]
KEYTABLE="us.map.gz"
[...]
# The YaST-internal identifier of the attached keyboard.
#
YAST_KEYBOARD="dvorak,pc104"

(In reply to Egbert Eich from comment #7)
> A configuration set with /usr/bin/setxkbmap is volatile ie. for the running
> Xserver only. It is written nowhere.
> The UI keyboard layout is expected to be done using your desktop UI - we
> don't write a static X keyboard configuration any more.

Well, unfortunately we still do. :-( But now we make use of systemd's localectl.
See bnc#861819 for more details.

(In reply to Egbert Eich from comment #7)
> Jiri, would be nice if you used the needinfo feature instead of reassigning
> ;)

I really wanted to reassing it, as I did not (and still don't) see YaST error here.

(In reply to Stefan Dirsch from comment #8)

> But then why does YaST save "us" instead of "dvorak"?
> 
> /etc/sysconfig/keyboard
> [...]
> KEYTABLE="us.map.gz"

It does not. YaST does not write KEYTABLE any more, it writes KEYMAP to /etc/vconsole.conf... or at least it should.

Michael, could you attach /etc/vconsole.conf as well?

(In reply to Jiří Suchomel from comment #10)
> It does not. YaST does not write KEYTABLE any more, it writes KEYMAP to
> /etc/vconsole.conf... or at least it should.

In that case /etc/vconsole.conf:KEYMAP is being used for setting the keyboard layout.

Michael, your turn.

Sorry for the delay; I'll try to respond soon. Not sure why I didn't attach that from the start. (Also note that in comment #4 I mention that localectl seems to be broken.)

My /etc/vconsole.conf is correct, it contains just the line KEYMAP=dvorak and my keyboard layout is properly set on all virtual terminals. Note that as the name of this file implies, it only affects virtual terminals (VC Keymap); it should have no impact on graphical sessions (X11 Variant). X11 Variant is read from /etc/locale.conf, unless there is a SUSE patch I haven't managed to find that changes this. (/etc/locale.conf doesn't exist at all on my system.)

After installing:

michael@linux:~> localectl
   System Locale: LANG=POSIX
                  LC_CTYPE=en_US.UTF-8
       VC Keymap: dvorak
      X11 Layout: us

The expected result would be something closer to this (from Fedora 20), with X11 Variant at the bottom:

$ localectl
   System Locale: LANG=en_US.utf8
                  LC_NUMERIC=en_US.UTF-8
                  LC_TIME=en_US.UTF-8
                  LC_MONETARY=en_US.UTF-8
                  LC_PAPER=en_US.UTF-8
                  LC_MEASUREMENT=en_US.UTF-8
       VC Keymap: us-dvorak
      X11 Layout: us
     X11 Variant: dvorak

Moreover, set-keymap is broken in openSUSE:

michael@linux:~> localectl set-keymap dvorak
michael@linux:~> localectl
   System Locale: LANG=POSIX
                  LC_CTYPE=en_US.UTF-8
       VC Keymap: dvorak
      X11 Layout: us

Since I did not pass --no-convert to localectl, set-keymap should have set both my VC Keymap and X11 Layout, not just my VC Keymap.

I still can see this issue in todays 13.2 build. Is there any chance to get this fixed for release?

From what I see, X Keyboard layout is set in form of:

localectl set-x11-keymap de pc105 nodeadkeys

But I am not sure which files are exactly modified by this command.

Created attachment 613143 [details]
/etc/sysconfig/keyboard KEYTABLE="lt.std.map.gz", but behave as lt.baltic.map.gz

Bug still in openSUSE 13.2 final  version, 
openSUSE does not respect /etc/sysconfig/keyboard KEYTABLE parameter. 

It seems, that for VT now is activated lt.baltic.map layout (QWERTY variant) – default Lithuanian layout by YaST.

With the same configuration in openSUSE 13.1 (and earlier versions), I had ĄŽERTY keyboard layout (as KEYTABLE="lt.std.map.gz") in VT and this layout was automatically transfered to login manager (KDM) and desktop environement (KDE).

See conplains in openSUSE forum also:
http://forums.opensuse.org/showthread.php/502362-Howto-configure-keyboard-for-VT-in-opensuse-13-2

Well, things have changed with the use of localectl. All we can do now is use the layouts, that are provided in the list when running 'localectl list-keymaps'.
I believe we should use this list also for YaST keyboard module.

Also, KEYMAP is now saved to /etc/vconsole.conf. From this keyboard layout is set for Linux console and X11 config is generated - to /etc/X11/xorg.conf.d/00-keyboard.conf, also by localectl.

X11 Variant for localectl is read from /etc/locale.conf?!? WTF? In case this it true, which I seriously doubt(!), it isn't documented anywhere! Check "man locale.conf'!

Ok. Just to make sure I've finally tried reproducing this issue. And I need to say, I cannot. Tried with "german(Switzerland)" and "dvorak". Things are simply set correctly in /etc/X11/xorg.conf.d/00-keyboard.conf afterwards.

This is for "dvorak":

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "dvorak"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "basic"
EndSection

And this for "german(Switzerland)":

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "ch"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "de"
EndSection

Just to mention: I have only seen this issue when installing using the Live media, not the DVD.

Thanks. Could you please try the following?

Use an installed system, log in, start yast, change the keyboard. Test if the changes got applied. Log out, log in again and verify if the changes are still there.

(In reply to Stefan Dirsch from comment #19)
> X11 Variant for localectl is read from /etc/locale.conf?!? WTF? In case this
> it true, which I seriously doubt(!), it isn't documented anywhere! Check
> "man locale.conf'!

Yes, I was wrong, sorry.

(In reply to Marcus Moeller from comment #21)
> Just to mention: I have only seen this issue when installing using the Live
> media, not the DVD.

Yes, DVD installation works fine. And since lives aren't supported anymore, that makes this bug not very serious.

Yes, changing it manually afterwards using latest updates works for me.

(In reply to Jiri Suchomel from comment #10)
> YaST does not write KEYTABLE any more, it writes KEYMAP to
> /etc/vconsole.conf... or at least it should.

I see, it is true. 

But I think, we should 
a) either remove /etc/sysconfig/keyboard:KEYTABLE to not confuse users, or 
b) either YaST should write to both 
  /etc/sysconfig/keyboard:KEYTABLE and 
  /etc/vconsole.conf:KEYMAP
  and 
 b1) somehow track changes in /etc/sysconfig/keyboard:KEYTABLE 
     to modify /etc/vconsole.conf:KEYMAP 
     (e.g. after going to "YaST" > "/etc/sysconfig editor").


(In reply to Stefan Dirsch from comment #18)
> I believe we should use this list also for YaST keyboard module.

I TOTALLY AGREE WITH INCLUSION OF MORE VARIANTS IN YAST!
Maybe for this should open separate bug/wish?

(In reply to Stefan Dirsch from comment #19)
> Also, KEYMAP is now saved to /etc/vconsole.conf. From this keyboard layout
> is set for Linux console and X11 config is generated - to
> /etc/X11/xorg.conf.d/00-keyboard.conf, also by localectl.

I see, it is true. 

(In reply to Stefan Dirsch from comment #22)
> Use an installed system, log in, start yast, change the keyboard. Test if
> the changes got applied. Log out, log in again and verify if the changes are
> still there.

It works as I installed fresh oS 13.2 from DVD. 
But I need layout not provided in YaST keyboard module.

(In reply to Stefan Dirsch from comment #19)
> Also, KEYMAP is now saved to /etc/vconsole.conf. From this keyboard layout
> is set for Linux console and X11 config is generated - to
> /etc/X11/xorg.conf.d/00-keyboard.conf, also by localectl.

I see, it is true, but only if I change keyboard from YaST. 
Manual editing /etc/vconsole.conf and reboot will not change 
/etc/X11/xorg.conf.d/00-keyboard.conf content.

If in YaST Keyboard module I switch to En(US) keyboard layout, but later modify 
/etc/vconsole.conf and write KEYMAP=lt.baltic

After reboot I have En(US) keyboard in VC and in X11

> localectl
   System Locale: LANG=lt_LT.UTF-8
       VC Keymap: lt.baltic
      X11 Layout: us
       X11 Model: microsoftpro
     X11 Variant: basic

I just figured out, that
manual editing in /etc/vconsole.conf does not take effect unless you run
> mkinitrd
> reboot

So I believe LiveCD users also must run mkinitrd to make changes in VC.

mkinitrd creates the initrd. /etc/X11/xorg.conf.d/00-keyboard.conf is generated by /etc/X11/xdm/keytable, which is being run by xdm init script before the displaymanager is being started.

(In reply to Stefan Dirsch from comment #28)
> mkinitrd creates the initrd. /etc/X11/xorg.conf.d/00-keyboard.conf is
> generated by /etc/X11/xdm/keytable, which is being run by xdm init script
> before the displaymanager is being started.

This still doesn't explain the observation:

(In reply to Mindaugas Baranauskas from comment #26)

> I see, it is true, but only if I change keyboard from YaST. 
> Manual editing /etc/vconsole.conf and reboot will not change 
> /etc/X11/xorg.conf.d/00-keyboard.conf content.
> 
> If in YaST Keyboard module I switch to En(US) keyboard layout, but later
> modify 
> /etc/vconsole.conf and write KEYMAP=lt.baltic
> 
> After reboot I have En(US) keyboard in VC and in X11

Mindaugas:

1. Could you please check the timestamps on /etc/vconsole.conf 
   /etc/X11/xorg.conf.d/00-keyboard.conf?
2. Could you provide the full content of /etc/vconsole.conf?
3. Could you run /etc/X11/xdm/keytable by hand and see if 
   /etc/X11/xorg.conf.d/00-keyboard.conf changes?
4. If 3 doesn;t work, try: localectl set-keymap lt.baltic

Now I configured my keyboard layout as lt.std for both VC and X11.

> 1. Could you please check the timestamps on /etc/vconsole.conf 
>    /etc/X11/xorg.conf.d/00-keyboard.conf?

                                                                                  
~> ls -l /etc/vconsole.conf
-rw-r--r-- 1 root root 10   Nov 12 11:31 /etc/vconsole.conf 
                                                            
~> ls -l /etc/X11/xorg.conf.d/00-keyboard.conf 
-rw-r--r-- 1 root root 307  Nov 12 10:03 /etc/X11/xorg.conf.d/00-keyboard.conf                                         

~> ls -l /etc/sysconfig/keyboard                                  
-rw-r--r-- 1 root root 2984 Nov 12 09:58 /etc/sysconfig/keyboard                                                      

Timezone +2

> 2. Could you provide the full content of /etc/vconsole.conf?

~> cat /etc/vconsole.conf
KEYMAP=lt.std

> 3. Could you run /etc/X11/xdm/keytable by hand and see if 
>    /etc/X11/xorg.conf.d/00-keyboard.conf changes?

/etc/X11/xdm/keytable does NOT modify /etc/X11/xorg.conf.d/00-keyboard.conf

Output:
# /etc/X11/xdm/keytable
/etc/vconsole.conf available
KEYMAP: lt.std
Command: localectl set-keymap lt.std 

> 4. If 3 doesn;t work, try: localectl set-keymap lt.baltic

~>localectl set-keymap lt.baltic
rewrite /etc/vconsole.conf content to 
KEYMAP: lt.baltic

> 4. If 3 doesn;t work, try: localectl set-keymap lt.baltic

~>cat /etc/vconsole.conf
KEYMAP=lt.baltic

localectl set-keymap lt.baltic
immediately changes only VC keyboard layout (typing as lt.baltic), 
but /etc/X11/xorg.conf.d/00-keyboard.conf was NOT changed,  X11 behaves as lt.std as before.

P.S. to have lt.std in /etc/X11/xorg.conf.d/00-keyboard.conf, this morning I manually edited it.

and 
localectl set-keymap [LAYOUT]
changes timestamp of /etc/vconsole.conf 
only if [LAYOUT] is different from /etc/vconsole.conf

(In reply to Mindaugas Baranauskas from comment #31)
> > 4. If 3 doesn;t work, try: localectl set-keymap lt.baltic
> 
> ~>cat /etc/vconsole.conf
> KEYMAP=lt.baltic
> 
> localectl set-keymap lt.baltic
> immediately changes only VC keyboard layout (typing as lt.baltic), 
> but /etc/X11/xorg.conf.d/00-keyboard.conf was NOT changed,  X11 behaves as
> lt.std as before.
> 
> P.S. to have lt.std in /etc/X11/xorg.conf.d/00-keyboard.conf, this morning I
> manually edited it.

Could you move away your manually edited /etc/X11/xorg.conf.d/00-keyboard.conf and try again with localectl set-keymap lt.baltic? 
Please check if a new /etc/X11/xorg.conf.d/00-keyboard.conf was created and if this has the correct content.

Yeah, I believe that's the culprit. 'localectl set-keymap [LAYOUT]' doesn't change anything if that's the LAYOUT already specified in /etc/vconsole.conf. So if you edit it manually in order to change it, layout in /etc/X11/xorg.conf.d/00-keyboard.conf won't be adjusted when running 'localectl set-keymap [LAYOUT]' afterwards.

I would call this unexpected or badly/not documented in localectl.

# rm /etc/X11/xorg.conf.d/00-keyboard.conf
# localectl set-keymap lt.baltic
# ls -l /etc/X11/xorg.conf.d/00-keyboard.conf 
ls: cannot access /etc/X11/xorg.conf.d/00-keyboard.conf: No such file or directory

If I comment /etc/X11/xdm/keytable:25 exit 0, 
/etc/X11/xorg.conf.d/00-keyboard.conf will be created and
I will get not 3, but 7 lines in output:

# /etc/X11/xdm/keytable
/etc/vconsole.conf available
KEYMAP: lt.std
Command: localectl set-keymap lt.std 
/etc/sysconfig/keyboard available
KEYTABLE: lt
Command: localectl set-keymap lt
Keyboard layout could not be set


# cat /etc/X11/xorg.conf.d/00-keyboard.conf

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "lt"
        Option "XkbModel" "pc105"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

Notice, that new /etc/X11/xorg.conf.d/00-keyboard.conf content is diferent from generated from from YaST Keyboard module for lt.baltic

YaST generated:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "lt"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "basic"
EndSection


My manual edition was:

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "lt"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "std"
EndSection

Removing /etc/X11/xorg.conf.d/00-keyboard.conf and then running localectl set-keyboard <layout> does not work, since localectl does only adjust this file, but not create it. Also documented badly/not at all. Therefore I create one for "us" in /etc/X11/xdm/keytable, which then is being adjusted by localectl later.

  [...]
  # xorg.conf.d snippet is only written if a valid snippet is already
  # available, so create an us sample if neccessary
  if [ ! -f $systemd_x11conf_file ]; then
    localectl set-x11-keymap us
  fi
  localectl set-keymap $1
  [...]

(In reply to Mindaugas Baranauskas from comment #36)
> If I comment /etc/X11/xdm/keytable:25 exit 0, 

This way you run into the fallback solution *always*.Not a good idea.

The documentation of locatectl could be improved.

The solution for our problem would be to call localectl set-x11-keymap $KEYMAP
*always* in /etc/X11/xdm/keytable. This adjusts the file when the locale has changed (compared to the one previously set in this file).
This is actually what we want, isn't it?

Created attachment 613379 [details]
Moditication of /etc/X11/xdm/keytable


It creates corect x11 keyboard konfiguration for me :)

> cat /etc/vconsole.conf
KEYMAP=lt.std


> /etc/X11/xdm/keytable
/etc/vconsole.conf available
KEYMAP: lt.std
Command: localectl set-x11-keymap  lt microsoftpro std 
Command: localectl set-keymap lt.std

> cat /etc/X11/xorg.conf.d/00-keyboard.conf 

# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "lt"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "std"
EndSection

(In reply to Egbert Eich from comment #39)
> (In reply to Mindaugas Baranauskas from comment #36)
> > If I comment /etc/X11/xdm/keytable:25 exit 0, 
> 
> This way you run into the fallback solution *always*.Not a good idea.

Exactly. Also I'm afraid the fallback code is broken. ".map.gz." needs to be cut off from $KEYTABLE. But this is unrelated.
 
> The documentation of locatectl could be improved.

Definitely!
 
> The solution for our problem would be to call localectl set-x11-keymap
> $KEYMAP *always* in /etc/X11/xdm/keytable. 

No, this won't work, since this is a different $KEYMAP. The mapping from console KEYMAP to the nearset matching X11 KEYMAP is somewhere hidden inside of systemd/localectl. Compare the output of 'localectl list-keymap' and 'localectl list-x11-keymap-layouts'.

What we can do is always run

  localectl set-x11-keymap us

After that 'localectl set-keymap $KEYMAP', since this will also touch the X11 config file. So just remove the condition in /etc/X11/xdm/keytable.

> This adjusts the file when the locale has changed (compared to the one
> previously set in this file). This is actually what we want, isn't it?

Comment on attachment 613379 [details]
Moditication of /etc/X11/xdm/keytable

attcached modification uses 
keyboard_map=/etc/X11/xdm/Keyboard.map 
for keyboard mapping

opts=$(grep -Po "^$1[ ]*:[^:]*:[^:]*:[^:]*:" $keyboard_map | \
     sed -re "s/([^:]*):([^:]*):([^:]*):([^:]*):/\3 \2 \4/" -e "s/[ ]+/ /g")
echo "Command: localectl set-x11-keymap $opts"
localectl set-x11-keymap $opts

Created attachment 613381 [details]
Modification of /etc/X11/xdm/keytable 2

If it reads /etc/sysconfig/keyboard, it also try to remove .map.gz 

...
 if [ ! -z $KEYTABLE ]; then
    KEYTABLE=${KEYTABLE%.gz}
    KEYTABLE=${KEYTABLE%.map}
...

I know how to use the 'diff' tool. ;-) This reintroduces the old sax2 keyboard mapping (Linux console -> X11 keymap) , which is for sure different than the one of localectl. Even if we would consider this, it would trigger new bug reports about different behaviour of localectl and /etc/X11/xdm/keytable script. Also I no longer want to maintain such a keyboard mapping table. We decided to use the upstream systemd/localectl keybaord stuff. Period.

`localectl list-keymaps` seems to just list /usr/share/kbd/keymaps/*/*
I indeed copied one file in /usr/share/kbd/keymaps/ subfolder and I found it in
`localectl list-keymaps` output.

localectl uses /usr/share/systemd/kbd-model-map maping table. It has much less mappings than /etc/X11/xdm/Keyboard.map. E.g. for Lithuania is only 1 mapping in kbd-model-map compared to 4 in /etc/X11/xdm/Keyboard.map

(In reply to Stefan Dirsch from comment #44)
> I know how to use the 'diff' tool. ;-) This reintroduces the old sax2
> keyboard mapping (Linux console -> X11 keymap) , which is for sure different
> than the one of localectl. 

But YaST Keyboard module also uses some internal mapping, very similar to the old sax2!

If I would use localectl for lt, my /etc/X11/xorg.conf.d/00-keyboard.conf would be different from generated from YaST for lt.baltic compare comment #37 and comment #36

So there are nothing better in localectl.





One bad thing in original /etc/X11/xdm/keytable was KEYTABLE=${KEYTABLE%%.*} , but for lt variants is separated with dot!

> localectl list-keymaps |  grep '\.'
defkeymap_V1.0
lt.baltic
lt.l4
lt.std

More testing revealed, that 
localectl set-keymap LAYOUT_VC
generates new /etc/X11/xorg.conf.d/00-keyboard.conf 
if LAYOUT_VC is new and if LAYOUT_VC exist in first column /usr/share/systemd/kbd-model-map


And you can not pass `localectl  set-x11-keymap LAYOUT_VC` as it may be in original /etc/X11/xdm/keytable

Created attachment 613403 [details]
/etc/X11/xdm/keytable try use default systemd keymap with fallback to xdm keymap

This script check 
if systemd has mapping for layout. 
  true  - let `localectl set-keymap $1` to create 00-keyboard.conf
  false - use `localectl set-x11-keymap $opts` 
    where $opts is used from fallback /etc/X11/xdm/Keyboard.map mapping
    or opts='us', if there is no mapping in either systemd or xdm

Created attachment 613405 [details]
/etc/X11/xdm/keytable try use default systemd keymap with fallback to xdm keymap

Created attachment 613408 [details]
/etc/X11/xdm/keytable run `localectl set-x11-keymap $opts` even if systemd mapping exist

because /etc/X11/xorg.conf.d/00-keyboard.conf only sometimes will be overwriten by `localectl set-keymap $1`...

(In reply to Mindaugas Baranauskas from comment #45)
> `localectl list-keymaps` seems to just list /usr/share/kbd/keymaps/*/*
> I indeed copied one file in /usr/share/kbd/keymaps/ subfolder and I found it
> in
> `localectl list-keymaps` output.
> 
> localectl uses /usr/share/systemd/kbd-model-map maping table. It has much
> less mappings than /etc/X11/xdm/Keyboard.map. E.g. for Lithuania is only 1
> mapping in kbd-model-map compared to 4 in /etc/X11/xdm/Keyboard.map

Indeed. Interesting information. Thanks for figuring out.

(In reply to Mindaugas Baranauskas from comment #46)
> (In reply to Stefan Dirsch from comment #44)
> > I know how to use the 'diff' tool. ;-) This reintroduces the old sax2
> > keyboard mapping (Linux console -> X11 keymap) , which is for sure different
> > than the one of localectl. 
> 
> But YaST Keyboard module also uses some internal mapping, very similar to
> the old sax2!

Which is bad and should be changed IMO.

> If I would use localectl for lt, my /etc/X11/xorg.conf.d/00-keyboard.conf
> would be different from generated from YaST for lt.baltic compare comment
> #37 and comment #36
> 
> So there are nothing better in localectl.

Never claimed that, but I would like to see it konsistently handled.

> One bad thing in original /etc/X11/xdm/keytable was KEYTABLE=${KEYTABLE%%.*}
> , but for lt variants is separated with dot!
> 
> > localectl list-keymaps |  grep '\.'
> defkeymap_V1.0
> lt.baltic
> lt.l4
> lt.std

Indeed. My fault. Needs to be fixed. But after all it's only the fallback case.

(In reply to Mindaugas Baranauskas from comment #47)
> More testing revealed, that 
> localectl set-keymap LAYOUT_VC
> generates new /etc/X11/xorg.conf.d/00-keyboard.conf 
> if LAYOUT_VC is new and if LAYOUT_VC exist in first column
> /usr/share/systemd/kbd-model-map

Ah. This explains a lot, e.g. why lt.baltic is being ignored.

> And you can not pass `localectl  set-x11-keymap LAYOUT_VC` as it may be in
> original /etc/X11/xdm/keytable

This isn't done. Only 'localectl set-x11-keymap us' is being used in 'keytable'
script.

(In reply to Mindaugas Baranauskas from comment #48)
> Created attachment 613403 [details]
> /etc/X11/xdm/keytable try use default systemd keymap with fallback to xdm
> keymap
> 
> This script check 
> if systemd has mapping for layout. 
>   true  - let `localectl set-keymap $1` to create 00-keyboard.conf
>   false - use `localectl set-x11-keymap $opts` 
>     where $opts is used from fallback /etc/X11/xdm/Keyboard.map mapping
>     or opts='us', if there is no mapping in either systemd or xdm

Honestly I don't want to see etc/X11/xdm/Keyboard.map to live forever. Try to bring the changes upstream to systemd instead.

This also affects installations from the DVD. In my case it affected a clean install of 13.2 64bit with xfce desktop.

Steps to reproduce (also reprodicible in virtualbox):
1. boot the machine with the dvd installer
2. choose polish as the language in the dvd boot screen, then select install, the locale and keyboard are automatically selected as polish
3. install the system (I used xfce desktop, had root on btrfs and on a different machine in ext4, so the filesystem doesn't affect this)
4. after install, login, open a text editor, try writing any polish specific characters e.g. ąśćół (written as altgr+the corresponding letter, e.g. altgr+a for ą)
- see that this doesn't work
5. open yast, keyboard layouts
- see that the polish layout is selected
6. select a different one (I chose portugese as it's next on the list), confirm
- note that applying the layout takes quite a long time
7. open yast keyboard layouts again, choose polish, confirm
- see in the text editor that the polish characters work correctly
8. shutdown the system & reboot the machine, login again, open a text editor and try to write some polish characters
- see that the polish characters don't work again
9. repeat steps 5-8

Here's a forum topic about this, another used said it affects his GNOME install too: https://forums.opensuse.org/showthread.php/503487-keyboard-layout-is-reset-to-default-on-reboot

I have the same problem in rawhide/xfce. I am using Danish (DK).

Every time I reboot both 'language' and 'keyboard' reset to US. I can change with YaST, and keyboard setting works for the session but not after reboot. Changing language setting require a new login, I tink  (?) , but after enw login settings are not applied.

After a new login YaSt language and keyboard settings display Danish/DK. Also the relevant configuration files say so.  But it seems that they are not used/read as expected.

YaST writes, but to the wrong place or *something* does not read what Yast wrote.


Thanks Buddha, that SuSE's default language and keyboard is not Tibetan! :-)

I have the same problem with KDE. I am using Swiss keyboard.

@Stephan,
you see, you see, openSUSE users still not rarely need legacy keyboard swicthing schema, so please don't veto proposed fallback to xdm solution (then systemd fails) untill next openSUSE release; but before that systemd must carefully add more layouts from legacy /etc/X11/xdm/Keyboard.map mapping in to new /usr/share/systemd/kbd-model-map and SUSE should review 
YaST its own mapping in /usr/share/YaST2/data/keyboard_raw.ycp. 

Thanks, Cyber, for nice example of such confusings!
It seems, that person from Poland (like Cyber) would like to patch /usr/share/systemd/kbd-model-map by renaming "pl2" console layout to "pl", as this is only layout in current mapping. Interestingly, YaST in /usr/share/YaST2/data/keyboard_raw.ycp suggest it shoud be "Pl02"...

I suggest we could provide patch with https://bugzilla.novell.com/attachment.cgi?id=613408 as base, perhaps uncommenting 19 and 47 lines, and in RPM %post or %posttrans section to remove/move current /etc/X11/xorg.conf.d/00-keyboard.conf to force regenarate configuration.

Created xdm RPM package, based on current openSUSE 13.2 updates version.
You can download from
http://download.opensuse.org/repositories/home:/embar-:/branches:/openSUSE:/13.2:/Update/standard/
build service:
https://build.opensuse.org/package/show/home:embar-:branches:openSUSE:13.2:Update/xdm

This is an autogenerated message for OBS integration:
This bug (897803) was mentioned in
https://build.opensuse.org/request/show/266503 13.2 / xdm

Any update, when it will be resoved?

Our guys realy don't want to keep legacy XDM keyboard switching...

I compared legacy XDM and new Systemd schemas. 

I see, that in new schema there is no longer these console keyboards:
amiga-de amiga-us ANSI-dvorak arabic atari-de atari-se atari-uk-falcon atari-us azerty be2-latin1 bg br-abnt br-abnt-alt br-latin1-abnt2 br-latin1-us chinese cn-latin1 cz-lat2-prog cz-lat2-us de_CH-latin1 default defkeymap defkeymap_V1.0 de-lat1-nd de-latin1-en dvorak-l dvorak-r emacs emacs2 es-cp850 et-nodeadkeys gr-pc hebrew khmer korean lt.baltic lt.l4 lt.std mac-be mac-br-abnt2 mac-cz-us-qwertz: mac-de_CH mac-de-latin1 mac-de-latin1-nodeadkeys mac-dk-latin1 mac-dvorak mac-es mac-fi-latin1 mac-fr mac-fr2-ext mac-fr3-ext mac-fr_CH-latin1: mac-fr-latin1 mac-gr mac-hu mac-it mac-jp106 mac-mac-template: mac-no-latin1 mac-Pl02 mac-pt-latin1 mac-ru1 mac-se mac-uk mac-us mac-us-ext mac-us-std nl2 no-latin1 pc110 pl Pl02 pt pt2 pt-latin9 ru1 ru2 ru-cp1251 russian ru_win ruwin_alt-UTF-8 se-latin1 sg-l1-lk450 sg-latin1-lk450 sk-prog-qwerty sk-qwertz sunkeymap sunt4-es sunt5-de-latin1 sunt5-es sunt5-fi-latin1 sunt5-fr-latin1 sunt5-ru taiwanese tralt trf tr_f-latin5 tr_q-latin5 wangbe 

Some of these removed mappings are required by YaST:
arabic chinese cn-latin1 cz-lat2-us es-cp850 khmer korean lt.baltic mac-be mac-br-abnt2 mac-de_CH mac-de-latin1 mac-de-latin1-nodeadkeys mac-dk-latin1 mac-dvorak mac-es mac-fi-latin1 mac-fr-latin1 mac-gr mac-hu mac-it mac-jp106 mac-no-latin1 mac-pt-latin1 mac-se mac-uk mac-us no-latin1 Pl02 ruwin_alt-UTF-8 sk-qwertz sunkeymap sunt4-es sunt5-de-latin1 sunt5-es sunt5-fi-latin1 sunt5-fr-latin1 sunt5-ru taiwanese 

Becides, keyboards, that is in new systemd mapping, but were not in legacy xdm:
bg_bds-utf8 bg_pho-utf8 by dvorak fr-latin9 ie il kazakh ko mk-utf pl2 ro-cedilla ro-std ro-std-cedilla sr-cy sr-latin ua-utf.

So I you use one of removed console keyboards, please provide its name. We need to patch systemd.

In last comment: dvorak is not new in systemd (I forgot to check unique).
Dvorak was in both xdm and systemd mappings, so in this particular case is not related with missing mappings.

Many packages involved in this bug:

xdm
- should not  remove all letters after first dot, 
  otherwise lt.baltic (and lt.std) fails.
  other solution: 
  * rename /usr/share/kbd/keymaps/i386/qwerty/lt.baltic.map.gz 
    to lt-balticmap.gz in "kbd" package,
  * and accordingly change lt.baltic to lt-baltic in 
    /usr/share/YaST2/data/keyboard_raw.ycp file of "yast2-country" package.

yast2-country
- suggested changes in /usr/share/YaST2/data/keyboard_raw.ycp (old > new):
  * korean > ko
  * Pl02   > pl2

systemd
- suggested additions in /systemd/kbd-model-map file:
  arabic 
  chinese 
  cn-latin1 
  cz-lat2-us 
  es-cp850 
  khmer
  lt.baltic (or lt-baltic)
  no-latin1 
  Pl02 
  ruwin_alt-UTF-8 
  sk-qwertz 

?
  * mac-be mac-br-abnt2 mac-de_CH mac-de-latin1 mac-de-latin1-nodeadkeys mac-dk-latin1 mac-dvorak mac-es mac-fi-latin1 mac-fr-latin1 mac-gr mac-hu mac-it mac-jp106 mac-no-latin1 mac-pt-latin1 mac-se mac-uk mac-us
  * sunkeymap sunt4-es sunt5-de-latin1 sunt5-es sunt5-fi-latin1 sunt5-fr-latin1 sunt5-ru taiwanese

One error again in last message Pl02 should be listed in next list

systemd
- suggested additions in /systemd/kbd-model-map file:
  arabic 
  chinese 
  cn-latin1 
  cz-lat2-us 
  es-cp850 
  khmer
  lt.baltic (or lt-baltic)
  no-latin1 
  ruwin_alt-UTF-8 
  sk-qwertz

xdm
- should not  remove all letters after first dot, 
  otherwise lt.baltic (and lt.std) fails.
  other solution: 
  * rename /usr/share/kbd/keymaps/i386/qwerty/lt.baltic.map.gz 
    to lt-balticmap.gz in "kbd" package,
  * and accordingly change lt.baltic to lt-baltic in 
    /usr/share/YaST2/data/keyboard_raw.ycp file of "yast2-country" package.

yast2-country
- suggested changes in /usr/share/YaST2/data/keyboard_raw.ycp (old > new):
  * arabic     > us (?)
  * chinese    > us (?)
  * cn-latin1  > cf (?)
  * cz-lat2-us > cz-lat2
  * es-cp850   > es (?)
  * no-latin1  > no (?)
  * Pl02       > pl2 
  * ruwin_alt-UTF-8 > ru (?)
  * taiwanese > us (?)

systemd
- suggested additions in /usr/share/systemd/kbd-model-map file:
  * khmer
  * lt.baltic (or lt-baltic)
  * sk-qwertz (it is not sk-qwertY!)
- suggested change in /usr/share/systemd/kbd-model-map file:
  * ko > korean (no such file ko.map*)
- suggested remove in /usr/share/systemd/kbd-model-map file:
  * lt (it is us keyboard with two layouts: default us,
        but you can press Alt+Enter to switch to lt-baltic)

?
  * mac-be mac-br-abnt2 mac-de_CH mac-de-latin1 mac-de-latin1-nodeadkeys mac-dk-latin1 mac-dvorak mac-es mac-fi-latin1 mac-fr-latin1 mac-gr mac-hu mac-it mac-jp106 mac-no-latin1 mac-pt-latin1 mac-se mac-uk mac-us
  * sunkeymap sunt4-es sunt5-de-latin1 sunt5-es sunt5-fi-latin1 sunt5-fr-latin1 sunt5-ru

(In reply to Mindaugas Baranauskas from comment #59)

> So I you use one of removed console keyboards, please provide its name. We
> need to patch systemd.

Please keep the "pl" keyboard layout too.

in systemd there is no pl, but is pl2. It is the same?

One suggestion. Maybe systemd fails with dvorak, as it is listed twice in /usr/share/systemd/kbd-model-map?

dvorak			us	pc105		dvorak		terminate:ctrl_alt_bksp
dvorak			us	pc105		dvorak-alt-intl	terminate:ctrl_alt_bksp

I use/have "German (Switzerland)" keyboard. I need to set it for every session and it is lost after reboot.

(In reply to Mindaugas Baranauskas from comment #65)
> in systemd there is no pl, but is pl2. It is the same?

I have no idea, but I check some other distros docs and they set pl2 for polish keyboard layout so I guess it should be ok.

In /usr/share/YaST2/data/keyboard_raw.ycp
German (Switzerland) points to sg-latin1 keymap,
it exist in both legacy xdm and new systemd mappings (as dvorak)...
/etc/vconsole.conf is expected to have KEYMAP=sg-latin1 value.
So every boot /etc/X11/xdm/keytable should to execute 
`localectl set-keymap sg-latin1` should create configuration for graphical X system (/etc/X11/xorg.conf.d/00-keyboard.conf)...
Problem: localectl will not create new configuration, if it's argument is the same, as already stored in /etc/vconsole.conf.  Let's force create new config even in this case!

SO please go to terminal, login as root (`su` command).
Then execute in terminal and post output of:

cat /etc/X11/xorg.conf.d/00-keyboard.conf ; cat /etc/vconsole.conf ;
. /etc/vconsole.conf ;
localectl set-keymap '' ;
cat /etc/X11/xorg.conf.d/00-keyboard.conf ; cat /etc/vconsole.conf ;
localectl set-keymap $KEYMAP ;
cat /etc/X11/xorg.conf.d/00-keyboard.conf ; cat /etc/vconsole.conf ;

I play with VirtualBox. 
In guest installing openSUSE 13.2 from KDE LiveDVD.
In boot meniu I selected Lithuanian language.
For keyboard select German (Switzerland).

After installation, activated was lt keyboard, but not same as Host!
Host system has lt(std) keymap for X and lt.std for console.
Try to get activated keyboard:
> setxkbmap -print | awk -F"+" '/xkb_symbols/ {print $2}'
lt(de)
Strange - there is no such variant de for lt keyboards at all!

> cat /etc/X11/xorg.conf.d/00-keyboard.conf ; 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "lt"
        Option "XkbModel" "pc105"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
> cat /etc/vconsole.conf ;
KEYMAP=sg-latin1

Then I try go to console:
> su
# init 3

Now I type, and I see, that I have QWERTZ keyoard – this is German (Switzerland)! Seems this configuration is came from initrd.

# init 5
I have lithuanian (default, not my prefered "std" variant) again for X.

# /etc/X11/xdm/keytable
/etc/vconsole.conf available
KEYMAP: sg-latin1
Command: localectl set-keymap sg-latin1 

This does not modify anything in /etc/X11/xorg.conf.d/00-keyboard.conf or /etc/vconsole.conf.

# localectl set-keymap sg-latin1
This does not modify anything also.

# rm /etc/X11/xorg.conf.d/00-keyboard.conf
# reboot

After reboot:

> setxkbmap -print | awk -F"+" '/xkb_symbols/ {print $2}'
ch(de_nodeadkeys)
- it is German (Switzerland)!

So, for those, who have dvorak, German (Switzerland) or other keymap, listed in systemd file /usr/share/systemd/kbd-model-map – solution is easy – just remove /etc/X11/xorg.conf.d/00-keyboard.conf and good configuration will be created at next boot!

This is an autogenerated message for OBS integration:
This bug (897803) was mentioned in
https://build.opensuse.org/request/show/281635 13.2 / xdm

Opened bug upstream for systemd https://bugs.freedesktop.org/show_bug.cgi?id=88545 . Try to add more layout requests here.

I did what Mindaugas proposed above and the result is the following. 

before and after of keyboard settings:

xxxxx@linux-xxxxx:~> more /etc/X11/xorg.conf.d/00-keyboard.conf_backup 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "ch"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "de"

after removing 00-keyboard.conf>

xxxxx@linux-xxxxx:~> more /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "ch"
        Option "XkbModel" "pc105"
        Option "XkbVariant" "de_nodeadkeys"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"

But when I enter input in the bash shell for example it is still wrong.

If you want to have console keyboard, you must check 
/etc/vconsole.conf value to be:
KEYMAP=sg-latin1
and, most important, run:
# mkinitrd

Because settings for console keyboard is loaded not from your installed system's /etc/vconsole.conf, but from /etc/vconsole.conf in /boot/initrd* archive.

Quite interesting, that openSUSE has some additional keyboard layouts and configuration for console, that not present upstream! See 
https://build.opensuse.org/package/show/openSUSE:Factory/kbd file suse-add.tar.bz2:
https://build.opensuse.org/source/openSUSE:Factory/kbd/suse-add.tar.bz2

E.g.:
lt.std.map
Pl02.map
br-abnt-alt.map
br-abnt2-old.map
cn-latin1.map
cz-lat2-us.map
ru1_win-utf.map
tj_alt-UTF8.map
us-acentos-old.map
ro-latin2.map

And, as discussed in https://bugs.freedesktop.org/show_bug.cgi?id=88545, Fedora has many more console layouts, converted from X keyboard layouts with script:

# Convert X keyboard layouts to console keymaps
mkdir -p $RPM_BUILD_ROOT/lib/kbd/keymaps/xkb
perl xml2lst.pl < /usr/share/X11/xkb/rules/base.xml > layouts-variants.lst
while read line; do
  XKBLAYOUT=`echo "$line" | cut -d " " -f 1`
  echo "$XKBLAYOUT" >> layouts-list.lst
  XKBVARIANT=`echo "$line" | cut -d " " -f 2`
  ckbcomp "$XKBLAYOUT" "$XKBVARIANT" | gzip > $RPM_BUILD_ROOT/lib/kbd/keymaps/xkb/"$XKBLAYOUT"-"$XKBVARIANT".map.gz
done < layouts-variants.lst

# Convert X keyboard layouts (plain, no variant)
cat layouts-list.lst | sort -u >> layouts-list-uniq.lst
while read line; do
  ckbcomp "$line" | gzip > $RPM_BUILD_ROOT/lib/kbd/keymaps/xkb/"$line".map.gz
done < layouts-list-uniq.lst

Full spec file: https://apps.fedoraproject.org/packages/kbd/sources/spec/

Fedora moved upstream layouts to /usr/lib/kbd/keymaps/legacy/ .

This is an autogenerated message for OBS integration:
This bug (897803) was mentioned in
https://build.opensuse.org/request/show/281654 13.2 / xdm

Indeed, I much prefer Fedora way. 
Because there is a lot of problems to configurate console modes and fonts...

E.g. in openSUSE console keyboards in not very useful (at least for Lithuanian) by default configuration, because some letters are shown incorrectly, until you manually load correct parameters for kbd_mode and setfont. Indeed, I can not found right font for lt.baltic (thought, it is default for Lithuania in openSUSE; lt.map and lt.std.map works with `kbd_mode -u; setfont lat4-16 ` ; lt.l4 works with `kbd_mode -a; echo -ne '\\033\\045@\\033(K'\015" ; loadkeys lt.l4 ; setfont lat4a-16 ` (except: š, ū, ž letters are show as strange symbols)).

Created attachment 619916 [details]
/usr/share/systemd/kbd-model-map with pc10* keymaps, that is used by YaST

As we and other distribution (at least Fedora) will not have same console keyboards, that means, that we must have openSUSE specific patched 
/usr/share/systemd/kbd-model-map of systemd.

So for quick solution for openSUSE 13.2:
* patched xdm package (submit provided)
  - modify /etc/X11/xdm/keytable 
     to don't truncate too much *.map.gz names with dot.
  - rpm post script:
    - move away /etc/X11/xorg.conf.d/00-keyboard.conf 
    - run /etc/X11/xdm/keytable
* patched systemd 
  - add more layouts to /usr/share/systemd/kbd-model-map
    (I attached now updated file, but don't want patch systemd it myself)
* some rpm package's post script
  - run mkinitrd to store updated  /etc/vconsole.conf in /boot/initrd* archive.

Next openSUSE release must rewrite YaST keyboard module, perhaps also use Fedora way to convert X keymaps to console keymaps, use another /usr/share/systemd/kbd-model-map.

systemd patch provided:
https://build.opensuse.org/request/show/281998

systemd post sript itseft recreate initrd.

Feature request for next release:
https://features.opensuse.org/318355

Adding systemd-maintainers

Hmmm ... this is a duplicated of bsc#910643.  Therefore I'll not accept the submit request #281998 as this is also required for all suse versions.


Beside this I've run grep, sort and diff with the supposed changes from bsc#910643:

@@ -3,3 +2,2 @@
-arabic            ara,us      pc105          -          terminate:ctrl_alt_bksp,grp:shift_toggle
-cn-latin1      ca  pc105      multix          terminate:ctrl_alt_bksp
-cz-lat2-us      cz,us      pc105          qwerty,basic    terminate:ctrl_alt_bksp,grp:shift_toggle
+cn-latin1              ca      pc105           -               terminate:ctrl_alt_bksp
+cz-lat2-us             cz      pc105           qwerty          terminate:ctrl_alt_bksp
@@ -7 +5 @@
-khmer            us,kh      pc105          -          terminate:ctrl_alt_bksp,grp:alt_shift_toggle
+khmer                  kh,us   pc105           -               terminate:ctrl_alt_bksp
@@ -9,0 +8 @@
+lt.std                 lt      pc105           std             terminate:ctrl_alt_bksp
@@ -11,2 +10,2 @@
-ruwin_alt-UTF-8          us,ru   pc105      ,winkeys    terminate:ctrl_alt_bksp,grp:ctrl_shift_toggle,grp_led:scroll
-sk-qwertz      sk,us      pc105          -          terminate:ctrl_alt_bksp,grp:shift_toggle
+ruwin_alt-UTF-8                ru,us   pc105           -               terminate:ctrl_alt_bksp,grp:shifts_toggle,grp_led:scroll
+sk-qwertz              sk      pc105           -               terminate:ctrl_alt_bksp

... I guess that khmer requires grp:alt_shift_toggle to switch between kh nad use layout. Also I wonder about sk-qwertz as there is no second layout as well as for cz-lat2-us.  For cn-latin1 I'd like to know what the difference between multix and pc105 is.  And arabic is missed.

Adding Ancor Gonzalez Sosa to Carbon Copy

I can not see any info about bsc#910643; then I try to enter, I see:
"Bugzilla – Access Denied. You are not authorized to access bug #910643".

OKey, we can use SUSE solution to patch /usr/share/systemd/kbd-model-map from systemd, if they are resonable. 
My provided variant is based on /etc/X11/xdm/Keyboard.map mapping.

Let's add arabic.

For cn-latin1: "multix" is "xvariant", not replacement of "xmodel" "pc105".
If you run `localectl list-x11-keymap-variants ca`, you see, that "multix" is legal argument. It means French (Canada) "Canadian multilingual" variant.

Khmer: yes, "grp:alt_shift_toggle" enable to change between layouts as dokumented http://www.x.org/releases/X11R7.6/doc/xorg-docs/input/XKB-Config.html#id2520758
You can always test yourseft:
`setxkbmap -model pc105 -layout kh,us   -option "grp:alt_shift_toggle" `

sk: I try  both
`setxkbmap -model pc105 -layout sk,us   -option "grp:shift_toggle"`
`setxkbmap -model pc105 -layout sk      -option "" `
But I am not sure, if there is difference between them.

cz: I try both
` setxkbmap -model pc105 -layout cz -variant qwerty  -option "" `
` setxkbmap -model pc105 -layout cz,us -variant qwerty,basic  -option "grp:shift_toggle" `
For me it behave the same, or maybe I don't know there should be difference. 

It would be better, if in this mail list would person, who use sk and cz keyboards.

To conclude: I accept SUSE patched variant.
I also wish to include lt.std keymap, because it works for my daily usage, though it is not in list in YaST keyboards.

And again I see, that this is just temporal solution – next openSUSE (and SUSE) release must to rewrite YaST keyboard module, I hope (open)SUSE will use Fedora way to don't use original kbd console keymaps and use converted from X – this could allow to create very precize /usr/share/systemd/kbd-model-map table for systemd.

(In reply to Mindaugas Baranauskas from comment #84)

Thanks for your feedback, you'll find the systemd at

     https://build.opensuse.org/project/show/Base:System:Legacy

including the patch

OK,

But in https://build.opensuse.org/package/rdiff/Base:System:Legacy/systemd?linkrev=base&rev=2 I see line, that is copy-pasted from above and not corrected:
PATCH-FIX-SUSE systemd-add-user-keep.patch (bnc#903009)

And in ".changes" file, why is boo#897803 instead of bnc#897803 ?

(In reply to Mindaugas Baranauskas from comment #86)

Thanks for spotting!

the boo is bugzilla.opensuse.org
    bsc is bugzilla.suse.com
    bnc is bugzilla.novell.com

openSUSE-RU-2015:0143-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 897803
CVE References: 
Sources used:
openSUSE 13.2 (src):    xdm-1.1.11-3.8.1

Ech... "Systemd" update must came before "xdm" update as mentioned! 
Otherwise systemd update will not change /etc/X11/xorg.conf.d/00-keyboard.conf;
or "systemd" update should do same thing in %post as last "xdm"...

*** Bug 914972 has been marked as a duplicate of this bug. ***

openSUSE-RU-2015:0214-1: An update that has 16 recommended fixes can now be installed.

Category: recommended (important)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,906709,907318,907393,908476,910643,912030
CVE References: 
Sources used:
openSUSE 13.2 (src):    systemd-210-25.12.1, systemd-mini-210-25.12.1

Closing as both xdm and systemd updates released.

SUSE-RU-2015:0638-1: An update that has 21 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,905550,906709,907318,907393,908476,910315,910643,911347,912030,916420,918118
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2
SUSE Linux Enterprise Server 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2
SUSE Linux Enterprise Desktop 12 (src):    aaa_base-13.2+git20140911.61c1681-3.1, systemd-210-55.2

openSUSE-RU-2015:1969-1: An update that has 21 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 897799,897803,898233,901481,902240,902901,903009,903963,904517,904828,905550,906709,907318,907393,908476,910315,910643,911347,912030,916420,918118
CVE References: 
Sources used:
openSUSE Leap 42.1 (src):    aaa_base-13.2+git20140911.61c1681-7.1

openSUSE-RU-2016:0320-1: An update that has 146 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 737690,742774,750845,818044,838475,841544,849870,852015,852021,852232,853293,854884,856389,856392,856858,857204,858864,859072,859365,860574,860937,861316,861489,863217,864745,864904,865834,866732,866933,867128,867663,867664,867840,868019,868230,868439,868931,869142,869603,872929,873432,873444,874665,875502,876587,876694,877021,877674,878525,880438,880732,881125,881559,881942,882393,882714,883565,884271,884403,885232,885288,886211,886599,886852,888178,888215,888612,889297,889357,890977,892096,892162,892300,893797,895087,896664,897799,897801,897803,898233,898240,898432,900558,901481,902240,902901,903009,903963,904214,904517,904828,905550,906709,906900,907318,907393,908476,909358,910643,911347,912030,912334,913517,916420,918118,919095,920195,921831,921898,921920,926169,927250,927457,928265,931388,932284,933365,933512,933521,933533,934077,934901,937512,937900,938908,939571,940264,941576,944132,944799,945282,947212,948458,948555,948705,949574,949683,949739,950510,951265,951663,953241,954336,954781,955635,961576
CVE References: 
Sources used:
openSUSE 13.1 (src):    systemd-210-40.1, systemd-mini-210-40.1