When X starts NumLock being enabled

Discussion in 'Desktop / X' started by Oleg, Jul 29, 2014.

  1. Oleg

    Oleg New Member

    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Hello Friends.
    Please, help me out.

    System RHEL 6.4. Linux kernel - 2.4.32.

    We have strange problem. When X starts Numlock is being enabled, but in console mode it disable. When I switch to console mode Numlock is become OFF, when I back to X mode , Numlock is become on. How I can do, that Numlock is always OFF???


    Please, don't suggest me numlockx utility. It absent in this linux distribution.
    Please, don't suggest me this bash script, because it is for console mode. We need X mode.

    for tty in /dev/tty[1-6]; do
    /usr/bin/setleds -D +num < $tty




    Please, don't suggest this code


    #include <X11/extensions/XTest.h>
    #include <X11/keysym.h>

    int main(void)
    {
    Display* disp = XOpenDisplay(NULL);
    if (disp == NULL) return 1;
    XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, XK_Num_Lock),
    True, CurrentTime);
    XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, XK_Num_Lock),
    False, CurrentTime );
    XCloseDisplay(disp);
    return 0;
    }

    I compile it, it don't work. Please, help.
    P.S. This behavoir observed both under root and under ordinary user.
  2. Oleg

    Oleg New Member

    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    But..........stop. I have some news.

    When I create new user and invoke 'startx' Numlock don't switch to ON state, it remain in OFF state.

    It need to me. How to find out what difference between ROOT and NEW_USER settings.
  3. JasKinasis

    JasKinasis Member

    Messages:
    69
    Likes Received:
    33
    Trophy Points:
    18
    If this is only happening when you are running X, I'd imagine it's an option in whatever GUI/desktop environment you're using that is causing the problem.

    Best bet would be to log in as root and fire up whatever Desktop you are using - I assume it's Gnome; and take a look at the keyboard options/settings in the system settings. Perhaps there is an option somewhere to turn the num-lock on when the Desktop is started. That would be my first port of call. Make sure the num-lock is turned off from there. Perhaps someone altered the keyboard settings for root (either on purpose or accidentally!)

    Otherwise, I am aware that the xset command can be used to turn special keys like num lock, caps lock, etc. on and off when X is running. Something like this (if memory serves):
    Code:
    xset led named "Num Lock" on
    - This should turn the num lock on.

    or to turn it off:
    Code:
    xset led named "Num Lock" off
    So there could be a config file somewhere which is using xset to set the state of the num-lock key. But there are a couple of other ways of using xset to turn those keys on/off too. So your config file might be using slightly different syntax. Either way, it can be done with xset, so you might want to consider grepping through the root users home directory (/root) to see if the root user has any config files which use xset. There might be a .xinitrc file, or .xsession file or something like that which is using xset to turn the num-lock on when a new X session is started.
    Code:
    grep -R xset /root/
    That might yield some clue! Take a look at any instances of xset that are returned by grep and see if any of them are doing anything with the keyboard. (the man pages for xset should help with this) If you find something that is turning the num-lock on, you can simply change it to explicitly turn it off.

    If that does not help, you could try doing the same for the new users home directory in case there is a file in the new users config that is explicitly turning num-lock off using xset! If you find a setting in new users directory which is turning num-lock off, you can replicate this setting in the appropriate config file for root!

    If that still doesn't help, we know that the problem only affects root and doesn't affect new users. So it must be some local setting that is different for root and they must be using something other than xset (if you were unable to find any instances of xset in either users configs). So, to determine the differences between the new user and root, you'd have to diff the new users home directory against the root users home dir and take a closer look at any hidden/config files that are listed as different.

    To diff /root/ and /home/newuser/ and write the results to a text file, you could do this:
    Code:
    diff -q -r /root /home/newuser > DiffResults.txt
    This will create a text file which lists all files that are different and also lists files that only exist in one directory and not the other. The -q option suppresses diffs normal output and will just tell you which files are different. The -r option causes the diff to be performed recursively (in case the config file causing the problem is in a hidden sub-directory)

    Next, use a text editor or grep to search through DiffResults.txt to see which files differ. In particular, make note of any hidden config files (filenames beginning with a . ), or files in hidden directories that differ and then compare those files.

    You are going to be looking for config files that have something to do with X or Gnome (or whatever desktop you are using if it is something other than Gnome), anything that doesn't have anything to do with X/Gnome can be ignored.

    Once you have a list of suspect files that differ in both users home directories, you need to diff each of those files to see if you can find a block of code/script which does something to alter the keyboard settings.

    e.g. If both users .xinitrc files are listed as different, diff them like this:
    "diff /root/.xinitrc /home/newuser/.xinitrc"

    Or visually diff the files with a text editor, e.g. for vim users:
    vim -d /root/.xinitrc /home/newuser/.xinitrc

    Consult the manual for your favourite text editor to determine whether it has any kind of diff functionality!


    If you still don't find anything, it could be a config file that exists in one users home directory, that doesn't exist in the others. So again, look at DiffResults.txt and make note of any unique config files and then take a look at them (with a text editor or grep) to determine if any of them are doing something with the keyboard settings for X/Gnome.

    For unique files the text file output by the original diff command will say something like:
    Only in /path/to/file: filename.ext

    So for example, if it finds a .xinitrc file in /home/newuser/ that isn't in /root/, the output will say:
    Only in /home/newuser : .xinitrc

    If none of that works, I'm afraid I'm pretty much out of ideas!
    Last edited: Jul 30, 2014

Share This Page