Am 19.01.24 um 23:14 schrieb Pavel Machek:
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).
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.
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
