All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: alsa-devel@alsa-project.org,
	"Ayman Bagabas" <ayman.bagabas@gmail.com>,
	"Takashi Iwai" <tiwai@suse.de>,
	platform-driver-x86@vger.kernel.org,
	"Hui Wang" <hui.wang@canonical.com>,
	ibm-acpi-devel@lists.sourceforge.net,
	"Pali Rohár" <pali.rohar@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	linux-leds@vger.kernel.org
Subject: Well-known LED names was Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Date: Sat, 1 Dec 2018 15:41:01 +0100	[thread overview]
Message-ID: <20181201144101.GD31631@amd> (raw)
In-Reply-To: <5f8eece3-95af-7866-d7d0-02cc3cb695ca@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3337 bytes --]

Hi!

> >>> If external USB keyboard is identified as "input7" device, then
> >>> "input7::mute" is a good name for mute key. But "sys::mute" does not say
> >>> anything to which device or hardware it belongs nor does not solve
> >>> problem that which device/driver/subsystem should have privilege to take
> >>> this "sys" name.
> >>
> >> How about just "platform" for the LEDs being part of the device
> >> on which the system is running?
> > 
> > "platform" works for me.
> > 
> > Are we in agreement that this name will be used for all similar LEDs,
> > as long as they are on the "main box" of the device, no matter if they
> > are connected using acpi, gpio, i2c, ...?
> 
> One doubt: say we have hdd activity LED on the "main box" - it
> would be named "platform::disk".
> 
> Now, we add external USB disk. Previously we were considering
> the naming for disk LEDs in the form e.g. "sdb::disk".
> 
> If so, there would be discrepancy between internal and external disk
> LED names. Similarly in case of eth/adsl/wlan/camera LEDs.

Well, it really depends if the "plaform::disk" is for all the disks,
or if it is for sda. In the second case, it might be better to name it
sda::disk...

Anyway... I believe we should start documenting good and bad LEDs, so
that patch authors know what is there, and can try to be consistent,
and so that userland knows what names to probe for.

What about following? Any other LEDs worth mentioning?

commit c56708addf9c312cefd760bca218a0545258b217
Author: Pavel <pavel@ucw.cz>
Date:   Sat Dec 1 15:32:13 2018 +0100

leds: Add list of well-known LED names
    
Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt
new file mode 100644
index 0000000..9a262db
--- /dev/null
+++ b/Documentation/leds/well-known-leds.txt
@@ -0,0 +1,42 @@
+-*- org -*-
+
+It is somehow important to provide consistent interface to the
+userland. LED devices have one problem there, and that is naming of
+directories in /sys/class/leds. It would be nice if userland would
+just know right "name" for given LED function, but situation got more
+complex.
+
+Anyway, if backwards compatibility is not an issue, new code should
+use one of the "good" names from this list, and you should extend the
+list where applicable.
+
+Bad names are listed, too, in case you are writing application that
+wants to use particular feature, you should probe for good name first
+but then try the bad ones, too".
+
+* Keyboards
+
+Good: "input*:*:capslock"
+Good: "input*:*:scrolllock"
+Good: "input*:*:numlock"
+
+Set of common keyboard LEDs, going back to PC AT or so.
+
+Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
+Bad: "lp5523:kb{1,2,3,4,5,6,7}" (Nokia N900)
+
+Keyboard frontlight/backlight.
+
+* Sound subsystem
+
+Good: "platform:*:mute"
+Good: "platform:*:micmute"
+
+LEDs on notebook body, indicating that sound input / output is muted.
+
+* System notification
+
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+
+Phones usually have multi-color status LED.



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2018-12-01 14:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 17:11 [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it) Takashi Iwai
2018-11-26 17:11 ` [PATCH 2/6] platform/x86: dell-laptop: Add micmute LED trigger support Takashi Iwai
2018-11-26 17:11 ` [PATCH 3/6] platform/x86: thinkpad_acpi: Add audio mute LED classdev support Takashi Iwai
2018-11-26 23:04   ` Andy Shevchenko
2018-11-27 11:04     ` Takashi Iwai
2018-11-26 17:11 ` [PATCH 5/6] platform/x86: dell-laptop: Drop superfluous exported function Takashi Iwai
     [not found] ` <20181126171126.20280-1-tiwai-l3A5Bk7waGM@public.gmane.org>
2018-11-26 17:11   ` [PATCH 1/6] leds: trigger: Introduce audio mute LED trigger Takashi Iwai
     [not found]     ` <20181126171126.20280-2-tiwai-l3A5Bk7waGM@public.gmane.org>
2018-11-26 20:59       ` Jacek Anaszewski
2018-11-27 11:04         ` Takashi Iwai
2018-11-26 22:58     ` Andy Shevchenko
2018-11-27 11:04       ` Takashi Iwai
2018-11-26 17:11   ` [PATCH 4/6] ALSA: hda - Support led audio trigger Takashi Iwai
2018-11-26 17:11   ` [PATCH 6/6] platform/x86: thinkpad_acpi: Drop superfluous exported function Takashi Iwai
2018-11-26 23:09 ` [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it) Andy Shevchenko
2018-11-27 11:05   ` Takashi Iwai
2018-11-27  8:44 ` Pavel Machek
2018-11-27 11:06   ` Takashi Iwai
2018-11-28 11:18   ` Pali Rohár
2018-11-28 11:38     ` Takashi Iwai
2018-11-28 12:25       ` Pavel Machek
2018-11-28 12:58         ` Takashi Iwai
2018-11-28 13:40           ` Andy Shevchenko
2018-11-28 19:58         ` Jacek Anaszewski
2018-11-28 20:34           ` Pavel Machek
2018-11-28 20:46             ` Pali Rohár
2018-11-28 21:00               ` Jacek Anaszewski
2018-11-28 21:22                 ` Pavel Machek
2018-11-29 21:23                   ` Jacek Anaszewski
2018-11-29 21:56                     ` Takashi Iwai
2018-11-30 10:42                     ` Andy Shevchenko
2018-12-01 14:41                     ` Pavel Machek [this message]
2018-12-08 21:59                       ` Well-known LED names was " Jacek Anaszewski
2018-11-28 21:01               ` Pavel Machek
2018-11-27 10:26 ` [ibm-acpi-devel] " Henrique de Moraes Holschuh
2018-11-27 11:11   ` Takashi Iwai
2018-11-28 11:14 ` Pali Rohár
2018-11-28 11:30   ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181201144101.GD31631@amd \
    --to=pavel@ucw.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ayman.bagabas@gmail.com \
    --cc=hui.wang@canonical.com \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.