Saturday, February 19, 2011

Setting NumLock on startup, how hard can it be?

So there was some code in kcmmisc which was inherited into keyboard daemon which sets the numlock state at KDE startup. Well the code had some ifdefs but it wasn't too bad and it was working (for me that is). Though users started reporting problems. As I could not find what's really wrong and latest numlockx (from which originally code was borrowed) was working I just reborrowed from the latest numlockx version. Seems to have helped... for a while...
New bug reports started to come in, with various degree of problems, including numlockx not working for everybody either (https://bugs.kde.org/show_bug.cgi?id=256255).

Some of those problems were caused by another programs reusing or controlling NumLock state/LED but some seems to be real with no obvious reason and thus no fix.

The summary? Well 300-lines program (numlockx) to simply set a flag for keyboard modifier and a LED might be one of those reasons why Wayland would eventually deprecate x.org

P.S. if anybody knows how to reliably set NumLock please speak up, 'cause I am giving up on this bug :)
Posted by at
Labels: ,

6 comments:

  1. Djuro DrljacaFebruary 20, 2011 at 8:22 AM

    I have this problem with openSUSE 11.3 and KDE 4.5, but I think it is the same as in older openSUSE and KDE versions.

    Isn't there a flag in the "input system" (probably X.org) and you just set the LED according to that flag?

    ReplyDelete
  2. peteteFebruary 20, 2011 at 12:10 PM

    Can't you just choose the default numlock state in the BIOS?

    ReplyDelete
  3. Djuro DrljacaFebruary 20, 2011 at 12:15 PM

    Forgot to mention ... this usually happens when I suspen my PC to RAM and probably my keyboard messes the internal state of NumLock or the driver or even KDE does something wrong with this state...

    ReplyDelete
  4. Andriy RysinFebruary 21, 2011 at 4:51 AM

    Djuro, there's a functions to set the flag but it's done via one of the two x.org extensions and obviously none of them work reliably.

    petete, I guess you could, but it won't be user-specific, and who's changing the bios settings nowadays? Not the regular users anyway

    ReplyDelete
  5. jeromegFebruary 21, 2011 at 7:33 AM

    I had the same problem for xfce4-settings-helper, it turned out to be a X.org bug which is still open at the moment (https://bugs.freedesktop.org/show_bug.cgi?id=16145).

    I switched the code to use xkblib, it's pretty simple (less than 10 lines) and we did not have any complaint yet.

    ReplyDelete
  6. Andriy RysinFebruary 21, 2011 at 4:10 PM

    jeromeg, thanks for the link to the x.org bug
    Though I am a bit confused as to why xkblib would help - kde keyboard daemon uses numlockx code which tries xkb first and only if it's absent or unsuccessful then it'll try XTEST. And xkblib is pretty much same thing using xkb protocol just separated into another lib for easy reuse. If you were using XTEST before then it would make sense that switching to xkb will be more robust.
    But in kde bug people reporting problems even with numlockx which uses xkb...

    ReplyDelete

Subscribe to: Post Comments (Atom)