lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 5 Apr 2019 00:05:09 +0200
From: Pavel Machek <pavel@....cz>
To: Dmitry Torokhov <dtor@...gle.com>
Cc: Nick Crews <ncrews@...omium.org>,
Guenter Roeck <groeck@...gle.com>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Benson Leung <bleung@...omium.org>, linux-leds@...r.kernel.org,
Jacek Anaszewski <jacek.anaszewski@...il.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
linux-rtc@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>,
Duncan Laurie <dlaurie@...omium.org>,
Simon Glass <sjg@...gle.com>
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@....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
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists