Hi!The common usage is "make keyboard look flashy", for some a fixed color scheme is enough, other ones might probably enable one of the built in modes. Most people I think will be satisfied with these 2 options, albeit both of your suggestions sound cool.
So that's actually big question.And while I would personally hate it, you can imagine a use case whereActually I think it does not belong to the input subsystem as it is,
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.
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
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