Messages in this thread | | | Date | Fri, 11 Apr 2014 08:12:02 +0200 | From | Samuel Thibault <> | Subject | Re: [PATCH] Route keyboard LEDs through the generic LEDs layer. |
| |
Hello,
I'm sorry this went out with a few mistakes.
Samuel Thibault, le Wed 09 Apr 2014 01:33:06 +0200, a écrit : > Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a écrit : > > It is not about the VT, I am talking about pure input core. If I > > repurpose CapsLock LED for my WiFi indicator I do not want to go into > > other programs and teach them that they should stay away from trying to > > control this LED. > > Err, but even without talking about repurposing Capslock LED for WiFi... > How is managed the conflict between the normal capslock behavior and > other programs' action on the underlying input device? I don't think > this patch does not introduce the problem.
I of course meant "I don't think this patch introduces the problem".
> How to decide which one to prioritize? > > Is it just because console-setup happens to repurpose the capslock LED > key that applications should suddenly not have capslock LED control > at all? That's contradictory with the use case you have given.
Oops, not the use case you have given, but a typical use-case of wanting to use a program which does nice things with the capslock LED, and then having to teach console-setup not to repurpose the capslock LED.
> That > leads me into believing that we should not try to push a hard rule, and > just let the user manage what accesses it. We could indeed make the VT > always take priority, but then that would probably break some existing > applications.
Such as the example above, with the capslock LED.
Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |