[opensuse] 42.3 bad NUMLOCK state in vttys in UEFI (Kaby Lake aka newer than 42.3) only
https://bugzilla.opensuse.org/show_bug.cgi?id=1010880 systemd: NUMLOCK configuration not taken into account due to mistakenly removed patch 'handle-numlock-value-in-etc-sysconfig-keyboard.patch' original description: NUMLOCK configuration not taken into account "FIXED" (as of Feb 2018) for 15.0 and TW, but undetermined state for 42.3 originally reported November 2016 against 42.2 running 4.4 kernel This bug was mostly untouched for its first year from filing, with no evidence of being worked on by any dev during that period. First NEEDINFO was applied after release of 42.3. I'm trying to figure out whether my Kaby Lake, which post-dates the original release of kernel 4.4 by quite some months, is a victim of this bug, or some other bug that may be a software regression and thus fixable for 42.3. All my hardware is desktop x86 PC with BIOS set to NUM ON at boot and full US 101 or newer keyboard. I'm a touch typist heavily dependent on the NUM pad at all times. All my hardware was considerably older than the 4.4 kernel until December, when I bought my UEFI Kaby Lake and installed 42.3, 15.0a, TW, and Debian 9. NUM behaves in 15.0x and TW as it has in all openSUSE versions since at least 10.2 if not older. In 42.3 on Kaby Lake (and Debian 9), I always have to turn NUM ON manually in the ttys (and in IceWM) regardless of the /etc/sysconfig/keyboard KBD_NUMLOCK='yes' or ='bios' setting. Sync between actual NUM state and NUM LED state does not seem to be at issue. I have many 42.3 installations. None have a problem maintaining BIOS and /etc/sysconfig NUM ON status, except my Kaby Lake. But, my Kaby Lake is my only hardware using UEFI firmware (or GPT). So, my experience could be either UEFI-related or Kaby Lake-related (late model hardware) and not related to /etc/sysconfig/keyboard/bug 1010880. Like 42.3, Debian with its 4.9 kernel also turns NUM off very early in boot. I've yet to discover how Debian ever decides whether to sync NUM state with BIOS or user intent, but like openSUSE on older hardware, NUM state is kept ON. Do other UEFI users have this problem with 42.3? Need or should I file a regression bug for this? The way I read 1010880, my problem is distinguishable, but I could be reading it wrong. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 24 Mar 2018 00:44:41 -0400 Felix Miata <mrmazda@earthlink.net> wrote:
NUM behaves in 15.0x and TW as it has in all openSUSE versions since at least 10.2 if not older. In 42.3 on Kaby Lake (and Debian 9), I always have to turn NUM ON manually in the ttys (and in IceWM) regardless of the /etc/sysconfig/keyboard KBD_NUMLOCK='yes' or ='bios' setting. Sync between actual NUM state and NUM LED state does not seem to be at issue.
Do other UEFI users have this problem with 42.3?
Excuse the heavy cut of your original message but I'm in travel but thought I could confirm couple of things: Kaby Lake (Dell), UEFI, 42.3, xfce. I don't use vttys much except when problems need fixing but, yes, I boot with numlock ON in GUI and when I switch to vtty numlock is initially OFF and must be manually turned on. Unlike your report, though, this DOES mess with the NUM LOCK LED on my machine; when switching back to GUI the LED goes OFF but the NUM LOCK is actually still on. HTH. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Felix Miata
-
listreader