Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: "Pali Rohár" <pali.rohar@gmail.com>, "Pavel Machek" <pavel@ucw.cz>
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,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-leds@vger.kernel.org
Subject: Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)
Date: Wed, 28 Nov 2018 22:00:59 +0100	[thread overview]
Message-ID: <0ed37870-c7b6-fd6b-2f6e-7325fdde3629@gmail.com> (raw)
In-Reply-To: <20181128204612.l3bayhop4qmep2hj@pali>

On 11/28/2018 09:46 PM, Pali Rohár wrote:
> On Wednesday 28 November 2018 21:34:10 Pavel Machek wrote:
>> Hi!
>>
>>>>>>> Looks good... except one detail: you have "tpacpi::micmute" and
>>>>>>> "dell::micmute". I know it follows "tradition", but we are trying to
>>>>>>> fix that at the moment. Laptop micmute button is a laptop micmute
>>>>>>> button, and userspace should not need to know what prefix to use
>>>>>>> depending on vendor.
>>>>>>>
>>>>>>> I'd suggest using "sys::micmute".
>>>>>>
>>>>>> I can imagine that in future some devices like keyboards would have also
>>>>>> mute led. We already have keyboards with mute key, so it is something
>>>>>> not unrealistic. What should be name convention for these mute leds?
>>>>>>
>>>>>> Is not "sys::" prefix too generic?
>>>>>
>>>>> Good point.  I thought of "laptop::" but it's not always laptop.
>>>>> "builtin::"?  Doesn't sound great, either.
>>>>>
>>>>> A nice godfather is required here...
>>>>
>>>> Just use sys:: :-).
>>>>
>>>> laptop:: would work for me, too. (It is always laptop in the cases we
>>>> are handling now, right?)
>>>>
>>>> When we get a keyboard with mute led, we'll have to decide if it
>>>> should be input6::mute -- because it is on keyboard, or if it is
>>>> sys::mute -- because the key is expected to mute whole system.
>>>
>>> drivers/input/input-leds.c seems to already support mute LED.
>>> It will be exposed as inputN::mute.
>>>
>>> Documentation/leds/leds-class.txt defines LED naming pattern
>>> to <devicename:color:function> and "sys" does not look as
>>> something resembling device name.
>>
>> So what is your suggestion?
> 
> I guess we should follow documentation. Or update documentation if it
> does not make sense to follow it.
> 
>> I don't care much as long as it is same in tpacpi and dell
>> case. (Neither are device names, btw :-).
>>
>> Actually "::mute" would make sense, too.
> 
> "::mute" is not a good idea due to name uniqueness.

LED core adds a numerical suffix to the original name
if it is already taken. Of course it is a last resort just
to avoid name clash.

> In case you would have two drivers which both provides "mute" led, then
> they need to have different name. Reason also why generic name "sys" is
> not a good idea.
> 
> input subsystem seems to solved this problem by appending number after
> "input" word.
> 
> I think that driver name or subsystem name would be usable together with
> number.
> 
> Userspace application would be probably interested to distinguish
> between "mute led which is part of laptop" and "mute led which is
> available on external USB keyboard".
> 
> 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?

-- 
Best regards,
Jacek Anaszewski
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel