in reply to Re^2: ioctl - does it actually work? replaced or preferred by something else?
in thread ioctl - does it actually work? replaced or preferred by something else?

I'm running a grsecurity kernel, and it does some things to limit users access to /dev/console for security reasons. As far as using the keyboard to reset the led, it dosn't. On my system, if I run the script I can turn off or turn on the led, but after I exit the script, the light no longer functions, when I toggle the Caps Lock key. It may be all because of my security kernel, but it's a fairly common patch people are using.
I'm not really a human, but I play one on earth. Cogito ergo sum a bum
  • Comment on Re^3: ioctl - does it actually work? replaced or preferred by something else?

Replies are listed 'Best First'.
Re^4: ioctl - does it actually work? replaced or preferred by something else?
by Jack B. Nymbol (Acolyte) on Feb 19, 2007 at 20:12 UTC
    Well, I don't know anything about that patch, but I tend not to like to add more layers. More points of failure. Seems like something's wrong if you have to reboot following the ioctl. More like intrusion detection than prevention. Should preempt the problem. But anyway, I think at least the culprit I'm running into is a privilege issue. Now to figure exactly what's at play.
[reply]
      It's not to hard for me to guess what happened. It cautions right in /linux/fd.h that those particular ioctl numbers, affect the LEDS, not the flags. So once you meddled with the LED flags by turning them on/off without the correct keypress, it probably assumes you want manual control of them, and leaves them in a "manual state", totally disconnected from the CapsLock key. If I toggle the led on with the script, it dosn't mean that I'm typing with caps, and vice/versa for off. I can still use the CapsLock key, but the light dosn't toggle anymore.

      Like the other reply by Fletch said, those low-level ioctl calls don't do exactly what you would think they should do, they do what the system designed for them. And that brings us back to your node title, "do they actually work"..... yeah ioctl's work, but they don't always do what you think, because they are performing fuctions at the lowest system level. I'm sure a keyboard driver engineer would say that is the way they are supposed to work, in order to support normal keyboard operation.

      There probably is a way to re-establish the proper link between the key and the LED, after being on manual, but it isn't obvious how to do it in the headers, so it was easier for me to reboot. :-) There are a few gimmick c programs out there for flashing the keyboard leds, maybe you could find one, and see what they do to reset normal operation when the program exits.

      I'm not really a human, but I play one on earth. Cogito ergo sum a bum
[reply]
        I don't have to reboot my system to get the CAPS-LOCK LED back to normal. I'm using latest stable kernel. And yes, ioctl works but there's still some privilege issues I need to understand.
        I am well aware that the test code toggles the LED and not the CAPS-LOCK, there's a separate ioctl for that.
[reply]

In Section Seekers of Perl Wisdom