From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B492CC4360F for ; Thu, 4 Apr 2019 20:26:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C93F20855 for ; Thu, 4 Apr 2019 20:26:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="K8Iaaphp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729863AbfDDU0t (ORCPT ); Thu, 4 Apr 2019 16:26:49 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:36110 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729626AbfDDU0s (ORCPT ); Thu, 4 Apr 2019 16:26:48 -0400 Received: by mail-lf1-f65.google.com with SMTP id d18so2782080lfn.3 for ; Thu, 04 Apr 2019 13:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dp1Y9Dv5GK630BR2v0clibblX4rr7K4ynMZz4d+Iw/8=; b=K8IaaphpikRsNexVl3wgZLY/JMVAKJ5G67c8zuE2BC6Uf9275KJvoN7xkhJ4z/MRN7 MbvfkeCVogYxyRuU9QWbibGKatbH8RB5d3UPo1G/7UJePlMY/H6lDxc+QESATdB5lfr6 dSdLuNxXGQhc1TtbaDSCBDwXgNzb5t5bBpYq2QCcnDD+J/h0Fq/VG5a3r9hphrETRq40 RmJMPpOZsU0U8zV9vWVfSvHcYIqHfj8AR/Ju64CGxwiIfb4GOrsIKRIfsRLYzOS5pxAO nab8OW6cK6U5pu+5TyiQcgCAv1TE4V5A/JvPY7i4iFDNbZ6WCMWyNfq1y7D+00bLK7Iw ySuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dp1Y9Dv5GK630BR2v0clibblX4rr7K4ynMZz4d+Iw/8=; b=cse2WLSy19h5pqk3+Svs968ZK9GK3v4U39XuRRi15znF94xkHEmcibyqjKqhakozhA CUwAraOTg3WlHvV3aB5pMHCnw1WAdhQ/L49PDiEsbPgJhJUAq40EAnuKdO7YF69raAu9 +ScKuLyFy0QkENbQAEQUAJ9kn/LahFebLl9qBZ8aCHl+MDkZkwtQOvNxxOo6fG6EcBrI y21y/QdiHlOJVwKgvwHBQ3F54ZS+5lDQZpuov2GplCloLZC2j9zp5uoQFJMRYDjzcKV2 zqHQZpj+cWcOHjAu2tHF1dWhIW1rcr8YJOfZwSgvuLgolQuLrQPgAyYS4hPqAfkKrsRF DJzw== X-Gm-Message-State: APjAAAWIkeX3KUlDjcAeL1QY/3FF7uYxPAMXHQiEKSScsb+KQxU0VJtG p3IV9lRyEeYdK98N5LjqYrgAMCVxsE+oM1kyu8eLSw== X-Google-Smtp-Source: APXvYqzA/4XqKeWk3nJEd1+1EoFUCYSaB34T+DGf+lDfFLGDsF4eM0t+zuClKCQ+zwftlC0TUebdXUXuVHX1VnULltk= X-Received: by 2002:ac2:5108:: with SMTP id q8mr3971924lfb.99.1554409606022; Thu, 04 Apr 2019 13:26:46 -0700 (PDT) MIME-Version: 1.0 References: <20190404185919.GB27340@amd> <20190404191931.GA29984@amd> <20190404200658.GD29984@amd> <20190404202042.GF29984@amd> In-Reply-To: <20190404202042.GF29984@amd> From: Dmitry Torokhov Date: Thu, 4 Apr 2019 13:26:35 -0700 Message-ID: Subject: Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name To: Pavel Machek 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-rtc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rtc@vger.kernel.org On Thu, Apr 4, 2019 at 1:20 PM Pavel Machek wrote: > > 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 i= n, and > > > > > > here we have proper standardization in form of "kbd_backlight".= Device > > > > > > name is, well, device name. It should uniquely identify the dev= ice led > > > > > > is attached to, but otherwise is rarely interesting. If userspa= ce is > > > > > > really concerned what kind of keyboard backlight it is it shoul= d > > > > > > investigate parent device(s) and see what they end up with. > > > > > > > > > > That does not work. Userspace wants to know if it is internal key= board > > > > > or USB keyboard, not what kind of i2c controller the LED is conne= cted > > > > > to. > > > > > > > > Why does userspace want to know it? > > > > > > For example to turn off backlight on internal keyboard when the lid i= s closed. > > > > 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'l= l > 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. > > > > > > grep for platform::mic_mute . > > > > > > > > > > (And platform is even pretty good match for how the LED is connec= ted > > > > > in your case). > > > > > > > > Until we get a secondary interface that is also "platform"... > > > > > > How would that happen? > > > > 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? =C2=AF\_(=E3=83=84)_/=C2=AF Maybe. Maybe not. Who knows what HW designers w= ill come up with. Thanks. --=20 Dmitry