On 5/4/19 0:42, Guenter Roeck wrote:
On Thu, Apr 4, 2019 at 3:05 PM Pavel Machek <pavel@xxxxxx> wrote:
On Thu 2019-04-04 14:48:35, Dmitry Torokhov wrote:
On Thu, Apr 4, 2019 at 1:42 PM Pavel Machek <pavel@xxxxxx> wrote:
And what to do if internal keyboard is not platform but USB? Like
Google "Whiskers"? (I am not sure why you decided to drop my mention
of internal USB keyboards completely off your reply).
I don't have answers for everything. Even if you have USB keyboard, you'll
likely still have backlight connected to embedded controller. If not,
then maybe you have exception userland needs to know about.
Still better than making everything an exception.
You do not need to make everything exception. You just need to look
beyond the name, and see how the device is connected. And then apply
your exceptions for "weird" devices.
"Where it is connected" is not interesting to the userland. "Is it
backlight for internal keyboard" is the right question. It may be
connected to embedded controller or some kind of controller over
i2c... my shell scripts should not need to know about architecture of
every notebook out there.
Then your scripts will be failing for some setups.
Well, yes. Do you want to guess what "lp5523:kb3" is?
Oh, please. The discussion is about the driver name part, which you
want to overload with some string to mean "internal", which in turn
is, if anything, part of the functionality.
With "platform", you'll at some point have two
"platform::kbd_backlight" entries. Remind me to send you a "told you
so" when that happens.
But I don't see why I should do additional work when its trivial for
kernel to just name the LED in an useful way.
"platform::kbd_backlight" has no disadvantages compared to
"wilco::kbd_backlight" ... so lets just use it.
It has disadvantages because it promises more than it can deliver IMO.
If device name != "platform::kbd_backlight" it does not mean that it
is not internal keyboard.
My promise is if "platform::kbd_backlight" exists, it is backlight for
internal keyboard. (And second half is "if it is easy for kernel, we
name backlight for internal keyboard platform::kbd_backlight").
And you still have not resolved how you will
handle cases when there is more than one deice that can be considered
internal and may have a backlight.
Is that realistic? How would that device look like?
Maybe is something "weird" in the PC/laptop world but in the Embedded world is
not as weird as you think. I worked on devices that has two internal backlights,
one to lit the qwerty keyboard and the other one to lit the numeric pad. We used
the device field to differentiate both.
Taking this to the extreme you can also think in a device where every key has
its own LED backlight, this happens for example in this device . The device
can lit only specific keys giving to the user a word prediction experience (i.e
After press a key, only the keys that match with a possible word are lit on)