# Quoting Denis Oliver Kropp ([EMAIL PROTECTED]): > > Also, I understand that while the shift key being pressed results in a > > change of kb_table, caps-lock requires individual action depending on > > the key being pressed (numbers remain numbers for example and are not > > shifted). The question is, should this modification be done within DFB, > > or should I modifiy the ascii values I get from dfb depending on the > > state of the caps/num lock keys at the application level? > > I think adding three modifiers and translating keys depending on them > in the input driver (keyboard.c already does it for shift) is the right way. > It should also handle keyboard LEDs. > > This way the app gets the *-lock press/release events and gets the proper > key/ascii value with modifier bits for *-lock. > > > If you want me to, I can add the three modifier keys (num, caps, scroll) > > and look into led handling. > > Go ahead if you agree or tell me what would be better for users/developers ;)
In principle, yes, I think it would be better to handle this within dfb. I'll add the modifier handling for the lock keys in keyboard.c and look into the led thing. One problem with this though, I really do not know what caps does with keys that are not on my keyboards ;). If anyone could point me in the direction of documentation on this kind of stuff, I'd appreciate it. What do I do with an a that has a � for example, is the capitalized version of that simply an A? Things like that. Cheers, Till -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
