From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name Date: Thu, 4 Apr 2019 22:20:42 +0200 Message-ID: <20190404202042.GF29984@amd> References: <20190404185919.GB27340@amd> <20190404191931.GA29984@amd> <20190404200658.GD29984@amd> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R6sEYoIZpp9JErk7" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Dmitry Torokhov Cc: Nick Crews , Guenter Roeck , Enric Balletbo i Serra , Benson Leung , linux-leds@vger.kernel.org, Jacek Anaszewski , Alexandre Belloni , Alessandro Zummo , linux-rtc@vger.kernel.org, linux-kernel , Duncan Laurie , Simon Glass List-Id: linux-leds@vger.kernel.org --R6sEYoIZpp9JErk7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu 2019-04-04 13:13:34, Dmitry Torokhov wrote: > On Thu, Apr 4, 2019 at 1:06 PM Pavel Machek wrote: > > > > Hi! > > > > > > > It is *function* and maybe color that userspace is interested in,= and > > > > > here we have proper standardization in form of "kbd_backlight". D= evice > > > > > name is, well, device name. It should uniquely identify the devic= e led > > > > > is attached to, but otherwise is rarely interesting. If userspace= is > > > > > really concerned what kind of keyboard backlight it is it should > > > > > investigate parent device(s) and see what they end up with. > > > > > > > > That does not work. Userspace wants to know if it is internal keybo= ard > > > > or USB keyboard, not what kind of i2c controller the LED is connect= ed > > > > to. > > > > > > Why does userspace want to know it? > > > > For example to turn off backlight on internal keyboard when the lid is = closed. >=20 > Would you not want to turn off external as well? Not really. If I'm using machine with lid closed, external monitor and USB keyboard attached, I want to control backlight of USB keyboard, but backlight of internal keyboard can stay off. > 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. > > > > grep for platform::mic_mute . > > > > > > > > (And platform is even pretty good match for how the LED is connected > > > > in your case). > > > > > > Until we get a secondary interface that is also "platform"... > > > > How would that happen? >=20 > It won't happen on Wilco, but you can't imagine that several blocks > get reused in the same device and they end up clashing? In the end, there will be just one internal keyboard backlight, right? Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --R6sEYoIZpp9JErk7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlymZxoACgkQMOfwapXb+vLn5QCfSbNvjo91bsUzD0yC/OdKMe60 gKoAnjqsLnPZ538cfiN5/TCl3hIXhsG7 =Dr/v -----END PGP SIGNATURE----- --R6sEYoIZpp9JErk7--