Hi! > > And while I would personally hate it, you can imagine a use case where > > you'd like a keypress to have a visual effect around the key you > > pressed. A kind of force feedback, if you will. I don't actually know, > > and correct me if I'm wrong, but feels like implementing that outside of > > the input subsystem would be non-trivial. > > Actually I think it does not belong to the input subsystem as it is, > where the goal is to deliver keystrokes and gestures to userspace. The > "force feedback" kind of fits, but not really practical, again because > of lack of geometry info. It is also not really essential to be fully > and automatically handled by the kernel. So I think the best way is > > to So that's actually big question. If the common usage is "run bad apple demo on keyboard" than pretty clearly it should be display. If the common usage is "computer is asking yes/no question, so highlight yes and no buttons", then there are good arguments why input should handle that (as it does capslock led, for example). Actually I could imagine "real" use when shift / control /alt backlight would indicate sticky-shift keys for handicapped. It seems they are making mice with backlit buttons. If the main use is highlight this key whereever it is, then it should be input. But I suspect may use is just fancy colors and it should be display. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
