[Bug 1006779] New: keyboard layout resets on system upgrade
http://bugzilla.suse.com/show_bug.cgi?id=1006779 Bug ID: 1006779 Summary: keyboard layout resets on system upgrade Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs@forge.provo.novell.com Reporter: msuchanek@suse.com QA Contact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- Blocker: --- I set my X keyboard layout in my login script. The layout would reset mysteriously. I seems that system upgrades trigger the reset. As there is no system-wide way to specify layout this is quite problematic. My WM keyboard shortcuts get remapped. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c1
Stefan Dirsch
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c2
Michal Suchanek
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c3
--- Comment #3 from Stefan Dirsch
Why is there /etc/sysconfig/keyboard and /etc/vconsole.conf?
The former is the deprecated one. ;-)
Which is used when?
The former is preferred, probably due to not break system updates (IIRC) in order to update /etc/X11/xorg.conf.d/00-keyboard.conf if required during displaymanager startup time before Xserver gets started.
And since both are limited to crude keyboard descriptions using the TV keymap files how do I specify xkb options in those?
You don't. This is what you can select during installation. Mainly one possible keyboard layout per language. No way to specify special xkb options here.
I run Xorg desktop. There is no daemon fucking with my keyboard settings and I do not want system scripts to do that either if they cannot set up all xkb options I specify.
It's up to the *desktop* to provide any special keyboard layout settings. Feel free to blame your desktop, but not the Xorg component. Sorry, but there is no Xorg desktop, unless you specify twm a desktop. And I doubt twm messes around with keyboard settings.
My WM keyboard shortcuts get remapped. This sounds to me like you're using a real desktop.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c4
--- Comment #4 from Michal Suchanek
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c5
Stefan Dirsch
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c9
Michal Suchanek
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c10
Stefan Dirsch
http://bugzilla.suse.com/show_bug.cgi?id=1006779
Zhao Qiang 赵强
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c11
Michal Suchanek
Ok. Could you verify if
udevadm trigger --subsystem-match=input --action=change
is responsible for that issue? Run it as root during your desktop runs as if it would be running during a package update.
That indeed cause the issue
We're using it in most xf86-input-<driver> packages. I've added it due to boo#592193. It was considered to be safe at that time. Sigh.
I would be safe if you could set complete keymap in the system settings. As things are the command resets your keymap to the limited options supported by the SUSE configuration scripts which breaks more complex keymaps, obviously. FWIW Debian has configuration scripts that allow setting complete keymap in udev settings and compile the XKB keymap into a Linux console keymap avoiding both this issue and discrepancy between X11 and console. Of course, this works flawlessly only for single user systems because there are only one udev settings. For multiuser systems you would probably need to write some sort of xinputd that runs in user session and takes care of settings for newly added and changed devices. This is one more component that each 'big' desktop implements as part of the environment without any code sharing whatsoever leaving out less bloated environments like icewm. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c12
Stefan Dirsch
(In reply to Stefan Dirsch from comment #10)
Ok. Could you verify if
udevadm trigger --subsystem-match=input --action=change
is responsible for that issue? Run it as root during your desktop runs as if it would be running during a package update.
That indeed cause the issue
Ok. Means I should stop doing this, reopen boo#592193 and make others unhappy again?
We're using it in most xf86-input-<driver> packages. I've added it due to boo#592193. It was considered to be safe at that time. Sigh.
I would be safe if you could set complete keymap in the system settings.
It only covers keyboard mapping for Linux console. X11 keybaord layout is different from that.
As things are the command resets your keymap to the limited options supported by the SUSE configuration scripts which breaks more complex keymaps, obviously.
Parse error. Sorry, I really can't understand this sentence. :-(
FWIW Debian has configuration scripts that allow setting complete keymap in udev settings and compile the XKB keymap into a Linux console keymap avoiding both this issue and discrepancy between X11 and console.
With sle15/TW we generate Linux console keyboard layouts from the X11 ones, so things should be consistent with sle15/TW.
Of course, this works flawlessly only for single user systems because there are only one udev settings.
Well it just works for the default user, which is fine.
For multiuser systems you would probably need to write some sort of xinputd that runs in user session and takes care of settings for newly added and changed devices. This is one more component that each 'big' desktop implements as part of the environment without any code sharing whatsoever leaving out less bloated environments like icewm.
Sure, things are not so easy then. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c13
--- Comment #13 from Michal Suchanek
(In reply to Michal Suchanek from comment #11)
(In reply to Stefan Dirsch from comment #10)
Ok. Could you verify if
udevadm trigger --subsystem-match=input --action=change
is responsible for that issue? Run it as root during your desktop runs as if it would be running during a package update.
That indeed cause the issue
Ok. Means I should stop doing this, reopen boo#592193 and make others unhappy again?
We're using it in most xf86-input-<driver> packages. I've added it due to boo#592193. It was considered to be safe at that time. Sigh.
I would be safe if you could set complete keymap in the system settings.
It only covers keyboard mapping for Linux console. X11 keybaord layout is different from that.
Why does it reset keyboard map for X11 if it cannot set it up then?
As things are the command resets your keymap to the limited options supported by the SUSE configuration scripts which breaks more complex keymaps, obviously.
Parse error. Sorry, I really can't understand this sentence. :-(
What do you not understand? If the maximum complexity of keymap you can set up is 'us' then pc+us+cz(ucw):2+inet(evdev)+terminate(ctrl_alt_bksp)+group(rwin_switch)+group(menu_switch)+ctrl(nocaps)+ctrl(swap_lwin_lctl) is reduced to pc+us+inet(evdev)+terminate(ctrl_alt_bksp).
FWIW Debian has configuration scripts that allow setting complete keymap in udev settings and compile the XKB keymap into a Linux console keymap avoiding both this issue and discrepancy between X11 and console.
With sle15/TW we generate Linux console keyboard layouts from the X11 ones, so things should be consistent with sle15/TW.
I will try looking at the settings in TW then.
Of course, this works flawlessly only for single user systems because there are only one udev settings.
Well it just works for the default user, which is fine.
It does not work for me because the settings do not allow me to configure complete keymap. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c14
--- Comment #14 from Stefan Dirsch
I would be safe if you could set complete keymap in the system settings.
It only covers keyboard mapping for Linux console. X11 keybaord layout is different from that.
Why does it reset keyboard map for X11 if it cannot set it up then?
I don't think system settings reset X11 keyboard settings. It just sets Linux console mapping, which then maps to a X11 default. Or are you now talking about the udevadm trigger? I guess it just resets the keyboard complete to standard "us" layout.
As things are the command resets your keymap to the limited options supported by the SUSE configuration scripts which breaks more complex keymaps, obviously.
Parse error. Sorry, I really can't understand this sentence. :-(
What do you not understand?
Setting commas would have helped a lot. "As things are *,* the command resets your keymap ... scripts *,* which ... Or just use shorter and simpler sentences. Luckily a collegue was able to help me here ...
If the maximum complexity of keymap you can set up is 'us' then pc+us+cz(ucw): 2+inet(evdev)+terminate(ctrl_alt_bksp)+group(rwin_switch)+group(menu_switch)+ ctrl(nocaps)+ctrl(swap_lwin_lctl) is reduced to pc+us+inet(evdev)+terminate(ctrl_alt_bksp).
Yes.
FWIW Debian has configuration scripts that allow setting complete keymap in udev settings and compile the XKB keymap into a Linux console keymap avoiding both this issue and discrepancy between X11 and console.
With sle15/TW we generate Linux console keyboard layouts from the X11 ones, so things should be consistent with sle15/TW.
I will try looking at the settings in TW then.
Ok. I'm sure it won't help you much though with your special setup though.
Of course, this works flawlessly only for single user systems because there are only one udev settings.
Well it just works for the default user, which is fine.
It does not work for me because the settings do not allow me to configure complete keymap.
Ok. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c15
Michal Suchanek
(In reply to Michal Suchanek from comment #13)
I would be safe if you could set complete keymap in the system settings.
It only covers keyboard mapping for Linux console. X11 keybaord layout is different from that.
Why does it reset keyboard map for X11 if it cannot set it up then?
I don't think system settings reset X11 keyboard settings. It just sets Linux console mapping, which then maps to a X11 default. Or are you now talking about the udevadm trigger? I guess it just resets the keyboard complete to standard "us" layout.
So that's exactly the problem. I have set up my X11 keymap and during upgrade it is reset to 'us'. I don't really care if it's the language configured in keyboard settings or 'us' always. It is not the keymap I had before the upgrade so it breaks my X11 session. Again, Debian has keyboard configuration scripts that allow setting any X11 keymap including options so the hook can preserve the keymap I set up for the system - it works for the default user at least. Or you can just reset the console keymap only if that is the purpose of calling the hook. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c16
Stefan Dirsch
http://bugzilla.suse.com/show_bug.cgi?id=1006779
Stefan Dirsch
http://bugzilla.suse.com/show_bug.cgi?id=1006779
http://bugzilla.suse.com/show_bug.cgi?id=1006779#c17
Stefan Dirsch
Ok. Seems the now one and only xf86-input-libinput driver doesn't come with this
udevadm trigger ...
in %post. And apparently nobody misses it. So the issue will be gone with TW/sle15 at least.
Well, it's still being used by -evdev and -wacom driver packages, which we still ship with sle15/leap15/TW and are installed by default due to needed touchscreen and better tablet support. Most likely you can uninstall these on your hardware and be happy though. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1006779
Stefan Dirsch
participants (1)
-
bugzilla_noreply@novell.com