[alsa-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Takashi Iwai
tiwai at suse.de
Thu Nov 29 22:56:40 CET 2018
On Thu, 29 Nov 2018 22:23:31 +0100,
Jacek Anaszewski wrote:
>
> On 11/28/2018 10:22 PM, Pavel Machek wrote:
> > 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.
>
> Regarding sound devices - how would we name micmute LED for USB
> microphone? I suppose that it is possible to discover some unique
> identifier in runtime - this is a question to ALSA people.
There are little USB-audio devices supporting the LED control, so we
haven't had any chance for LED class for USB-audio.
At most, we may create LED class devices for some HD-audio (usually
driven via exotic verbs or GPIO over HD-audio), but I wouldn't go in
that direction; it'll need too make things more complex than the
direct hook as of now.
thanks,
Takashi
More information about the Alsa-devel
mailing list