Results 1 to 6 of 6

Thread: Numlock again :-(

  1. #1

    Default Numlock again :-(

    I have a variant on what seems to be a recurring issue. I use two KDE sessions, with one user on F7 and a different user on F8. For user 1 I have set numlock on. However then the session for user two on F8 always starts with numlock off, despite setting the KDE setting to on, and the keyboard setting in YAST to on. Does anyone know how I can start multiple graphical sessions with all the numlocks stating "on"?

    Cheers
    Fred

  2. #2
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,578

    Default Re: Numlock again :-(

    AFAIK, this is a SSDM issue.
    BTW, some of us are experiencing a "usually Num-Lock indicated as being off" issue when we login to a KDE Plasma 5 session.
    Can't remember if there are KDE KF5 and/or SDDM Bug reports raised against these issues.

  3. #3

    Default Re: Numlock again :-(

    Quote Originally Posted by dcurtisfra View Post
    AFAIK, this is a SSDM issue.
    No, it's not.
    SDDM is not involved when switching VTs, and actually it doesn't touch the NumLock state at all by default.

    It may help to make SDDM explicitly turn on NumLock in /etc/sddm.conf though:
    Code:
    [General]
    Numlock=on
    See also "man sddm.conf".

    Can't remember if there are KDE KF5 and/or SDDM Bug reports raised against these issues.
    Sure, I even remember one filed by *you* on KDE's bugzilla...
    But IMHO it's neither a bug in KF5 nor Plasma nor SDDM.

    Btw, YaST's setting has no effect, as the SUSE-specific patch that evaluated that option got removed from systemd in Leap 42.1.
    Will be back in 15.0 though, as a separate kbdsettings.service.
    https://bugzilla.opensuse.org/show_bug.cgi?id=1010880
    Last edited by wolfi323; 18-Apr-2018 at 00:12.

  4. #4
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,578

    Question Re: Numlock again :-(

    Quote Originally Posted by fredsie View Post
    I use two KDE sessions, with one user on F7 and a different user on F8.
    Quote Originally Posted by wolfi323 View Post
    SDDM is not involved when switching VTs, and actually it doesn't touch the NumLock state at all by default.
    Looking at the process tree on this system, the parent process of "sddm" is "systemd" and there're 2 child processes of "sddm": "X" and "sddm-helper".
    My "startkde" process is a child of "sddm-helper".
    My "kdeinit5" process is a child of "systemd" and my "ksmserver" process is a child of "kdeinit5".

    If I start a new, parallel, user session, the "sddm" process starts 2 new child processes: "X" and "sddm-helper" -- both user "root".
    The new "sddm-helper" process has a new child "startkde" process for the "new" parallel (Test) user session.
    There's also a new "kdeinit5" process for the "new" parallel (Test) user session with a new "ksmserver" process for that user.

    • And, I'm noticing that, since the parallel session has been started, the "Num-Lock" lamp on the keyboard repeatedly "turns off" -- after I've turned it on again …


    So, the 64-dollar question: who, or what, is managing the switching between the two KDE Session Managers?

  5. #5

    Default Re: Numlock again :-(

    Quote Originally Posted by dcurtisfra View Post
    So, the 64-dollar question: who, or what, is managing the switching between the two KDE Session Managers?
    Xorg and/or systemd, I'd say, although the kernel or udev may be involved here as well.

    Btw, I see the same behaviour as you once mentioned (i.e. the NumLock LED turns off when I press Shift, although NumLock itself is still on) with kdm , another indication that it's not SDDM's "fault"...
    Last edited by wolfi323; 19-Apr-2018 at 06:11.

  6. #6

    Default Re: Numlock again :-(

    Quote Originally Posted by wolfi323 View Post
    Xorg and/or systemd, I'd say, although the kernel or udev may be involved here as well.
    PS, see also the latest comment in https://bugzilla.opensuse.org/show_bug.cgi?id=1017294 :
    In normal situation, kbd always sets LED together with NumLock status change.

    I am not sure what is the source of the problem. It could be kernel, kbd, X or even systemd or boot process or splash screen implementation. It could be bad setting of LEDs mask.

    To debug the problem in the lowese level, you should check /sys/class/leds in the inconsistent state. Is trigger properly set to kbd-numlock? Does brightness correspond with the current LED state?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •