Messages in this thread | | | Date | Fri, 5 Apr 2019 00:05:09 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name |
| |
On Thu 2019-04-04 14:48:35, Dmitry Torokhov wrote: > On Thu, Apr 4, 2019 at 1:42 PM Pavel Machek <pavel@ucw.cz> wrote: > > > > Hi! > > > > > > > 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?
> > 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?
Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [unhandled content-type:application/pgp-signature] | |