# Quoting Denis Oliver Kropp ([EMAIL PROTECTED]): > > I will apply it, but I will move the LEDState stuff from directfb.h into > > the keyboard driver. Application developers should not deal with LEDs ;) > > While applying the patch and looking through it again I'm unsure > if applications should be able to set/get LED status. At least > it would introduce inconsistency.
Well, it would be nice to be able to modify the LED status, while not really necessary, I guess (Blinkenlights! ;). I was thinking of maybe adding that later when I put the led stuff in directfb.h, but didnt come back to it. As for inconsistency, we could mimic what the kernel does in that respect, have a toggle for whether the leds display the lock state, or whether they are controlled by API calls wrapping the ioctls that set the led state. > Or should it influence the lock modifiers? I dont think applications should be able to touch the lock flags themselves directly. This should stay within the input device drivers. I cant think of a situation where modifying them directly would be needed for application programs. There's another problem which dfb shares with X. The state of the led's (but not the lock flags) is not restored after the directfb vt is left. This can leave the leds in a state that does not reflect the state of the flags. till -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
