http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c1 --- Comment #1 from Jean-Claude Dole --- Correction, please read : 1°) The led is on (numlock on) but Numlock functionality is "Numlock off"; clicking the numlock key set Numlock functionality to "Numlock on" without modifying the numlock led which stay on. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c3 --- Comment #3 from Jean-Claude Dole --- Hello ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c5 Christos Gourdoupis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |xrigou@otenet.gr --- Comment #5 from Christos Gourdoupis --- This is truly a bug, and sddm, kde or X are irrelevant. I read somewhere that the feature was dropped because it was causing trouble in laptops lacking numpads. Some of us are still using desktops and even more astonishingly the virtual terminal. A work around is to add the following to boot.local (which btw is also deprecated) for tty in /dev/tty[1-9]*; do setleds -D +num < $tty done -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c7 Peter Gumbrell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter@renault4.plus.com --- Comment #7 from Peter Gumbrell --- I too ran into this after upgrading to Leap but eventually found the solution to add the numlock line in sddm.conf. Surely, however, if laptop users are the reason for this change, they would only have to configure numlock off in the appropriate place? And if the decision is nonetheless to leave it off, there should at least be the working functionality to turn it back on either in the DE or through YaST (perhaps the better solution), not via an obscure config file that most users don't know about. Is it the YaST functionality side that's broken or the interpretation by sddm? This change breaks what I believe to have been the default behaviour in all previous versions of openSUSE (at least as far back as I can recall) and there's not even so much as a mention in the Release Notes. For anybody used to logging in using the numpad for entering characters it's a pain in the bum. FWIW, I use a laptop, an old Dell model, but it has relatively sophisticated functions in the BIOS as to how to handle the numlock. I'm assuming many modern laptops do away with such sophistication in the name of simplification :( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c9 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sndirsch@suse.com, | |werner@suse.com --- Comment #9 from Stefan Dirsch --- Stumbled across this when reading opensuse-factory ML today. Seems the feature has simply been dropped from kbd boot/init scripts. :-( In old kbd.init, which no longer exists: . /etc/sysconfig/keyboard [...] # Note: The file /var/run/numlock-on is used in ~/.xinitrc # to reflect the correct numlock state choosen by the # user even under X11 # if test "$KBD_NUMLOCK" = "yes"; then touch /var/run/numlock-on elif test "$KBD_NUMLOCK" = "no"; then rm -f /var/run/numlock-on elif test "$KBD_NUMLOCK" = "bios"; then if test -x /usr/sbin/hwinfo ; then /usr/sbin/hwinfo --bios | \ while read line ; do case "$line" in Num\ Lock:\ on) touch /var/run/numlock-on ;; Num\ Lock:\ off) rm -f /var/run/numlock-on ;; Caps\ Lock:) break esac done else echo "no /usr/sbin -> Numlock off." rm -f /var/run/numlock-on fi fi The snippet, which run numlockx still exists in /etc/X11/xdm/Xsetup. # # Enable Numlock if set # if test -r /var/run/numlock-on && type numlockx >/dev/null 2>&1; then numlockx on fi And KBD_NUMLOCK="bios" is still in /etc/sysconfig/keyboard. I can't say for which reasons this feature has been dropped. Adding Werner. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 Björn Voigt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjoernv@arcor.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c17 --- Comment #17 from Felix Miata --- (In reply to Stefan Dirsch from comment #16)

So how is this related to the kernel?

What but the kernel could be kicking NUM off when the BIOS has turned it on before the kernel loaded and init began? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c22 --- Comment #22 from Takashi Iwai --- After looking at the patch again, I think we can revive the system patch with simplification: if "yes" or "no" is given, it overrides the NUMLOCK led. If any other values including "bios" is given, ignore it. I guess this will satisfy most of users demands. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c24 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | --- Comment #24 from Stefan Dirsch --- Now that we figured out that the patch 'handle-numlock-value-in-etc-sysconfig-keyboard.patch' has erroneously been removed, can we please have this patch back? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c25 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(thomas.blume@suse | |.com) --- Comment #25 from Franck Bui --- No that's not what I meant: it's not been removed erroneously since the plan was to move those bits to the kbd package. Thomas, is that correct ? If so could you reassign this to Stanislav ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c27 --- Comment #27 from Franck Bui --- (In reply to Stefan Dirsch from comment #26)

He made his work by creating the patch for systemd, that one wants simply back ...

No you got it wrong again. The plan (when the git repo for systemd was created) was to move it back *again* to the kbd package, at least that was my understanding as systemd doesn't seem to be the right place to put all keyboard customizations though. The reason why it hasn't been done is unclear to me.

I'm aware, that you want to remove any SUSE-specific patch from our systemd package ...

Not sure what you insinuate here but yes we try to minimize the number of specific patches for obvious reasons. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c30 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #30 from Stanislav Brabec --- The testing repository implementing new kbdsettings.service into kbd: https://build.opensuse.org/project/show/home:sbrabec:branches:kbd-numlock (OBS looks broken just now (unresolvables in all repos), you have to wait for the build.) Thomas Blume: I added Type=oneshot to kbdsettings.service Franck Bui: I found that you removed sysconfig variable KEYTABLE saying "Drop from some fill-up templates, a couple of sysconfig variables no more read by systemd (fate#319454)". But the current vconsole-setup.c still reads this variable, and /usr/bin/kbd reads it as well. Is the dropping intended change or mistake? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c39 --- Comment #39 from Dr. Werner Fink --- I'd like to mention that thew service kbdsettings.service should always be called short after systemd-vconsole-setup.service and *before* or *after* plymouth as otherwise it will not work. Could be solved by using After=systemd-vconsole-setup.service together with PartOf=systemd-vconsole-setup.service Also I suggest to add in [Unit] section ConditionPathExists=/dev/tty0 as well as in the [Service] section RemainAfterExit=yes -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c42 --- Comment #42 from Wolfgang Bauer --- And some minor nitpicks: The comment for KBD_NUMLOCK in /etc/sysconfig/keyboard says this: # NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting) Which IMHO would imply that an empty setting should be the same as "bios". But AFAICS, the script will just do nothing in this case. Probably a good idea to either change the script or the comment I think. And there's a typo in line 30: echo "Valume ${!conf} invalid for $conf" ^^^^^^ -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c44 --- Comment #44 from Wolfgang Bauer --- (In reply to Stefan Dirsch from comment #43)

(In reply to Wolfgang Bauer from comment #42)

...

And some minor nitpicks:

The comment for KBD_NUMLOCK in /etc/sysconfig/keyboard says this: # NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)

Which IMHO would imply that an empty setting should be the same as "bios".

But AFAICS, the script will just do nothing in this case. Probably a good idea to either change the script or the comment I think.

And there's a typo in line 30: echo "Valume ${!conf} invalid for $conf" ^^^^^^

Now you lost me. Which script are you talking about now?

kbdsettings in the new kbd package in home:sbrabec:branches:kbd-numlock. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c46 --- Comment #46 from Wolfgang Bauer --- (In reply to Stefan Dirsch from comment #45)

Hmm. Isn't KBD_NUMLOCK now completely ignored?

No. kbdsettings does this: for i in NUM SCR CAPS; do conf=$(eval echo KBD_${i}LOCK) [ -z ${!conf} ] && continue ... I.e. it reads the values of KBD_NUMLOCK, KBD_SCRLOCK and KBD_CAPSLOCK and acts upon each (unless it's empty). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c48 --- Comment #48 from Stanislav Brabec --- Wolfgang Bauer: comment 41: Good hint. I forgot that /var/run/numlock-on is needed by X. comment 42: Both fixed. We indeed don't have to handle empty string. Package with those 3 fixes is available in the same repository (see comment 40). Leap 15 builds are ready, Factory builds will take some time. (But binaries should be compatible.) I guess it is ready for submit to Factory now. I am still unsure whether behavior of Scroll Lock is a bug or standard behavior. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c50 --- Comment #50 from Stefan Dirsch --- Seems so. And /run/numlock-on should be removed ("rm -f /run/numlock-on"), if the setting is "off" or "unknown". Otherwise it will still be enabled even if the user changes the setting in the BIOS. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c52 --- Comment #52 from Stanislav Brabec --- Wolfgang Bauer, comment 49: Thanks for the fix. Stefan Dirsch, comment 50, comment 51: Yes, it should be removed. But not because user can change setting in BIOS (/run is in ramdisk). It should be removed because user can change setting in sysconfig editor. Such change triggers kbdsettings.service, and change should be applied immediately. Both issues are fixed now. But here is a problem: sysconfig file contains ## ServiceRestart: kbdsettings Looking at y2log, it seems to ignore oneshot services by design. Ladislav, is there any way to trigger oneshot service from sysconfig editor? 2018-01-11 18:23:06 <1> goblin(6495) [Ruby] modules/Progress.rb:344 Progress::New(Ukládá se nastavení systémové konfigurace, 6, ["Zapsat nové nastavení", "Aktivovat změny"]) 2018-01-11 18:23:06 <1> goblin(6495) [Ruby] yast2/systemctl.rb:32 systemctl show kbdsettings.service --property=Id --property=MainPID --property=Description --property=LoadState --property=ActiveState --property=SubState --property=UnitFileState --property=FragmentPath 2018-01-11 18:23:07 <1> goblin(6495) [Ruby] clients/sysconfig.rb:134 Sysconfig module finished -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1010880 http://bugzilla.opensuse.org/show_bug.cgi?id=1010880#c59 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #59 from Felix Miata --- Is a new bug needed to get this into 42.3 and 15.0? On my American Megatrends F8 UEFI KabyLake, NUM state on/yes is only working in TW20180105. -- You are receiving this mail because: You are on the CC list for the bug.