On Thu 2018-11-22 13:36:43, Andy Shevchenko wrote:
On Tue, Nov 20, 2018 at 2:19 PM Takashi Iwai tiwai@suse.de wrote:
On Tue, 20 Nov 2018 12:51:59 +0100, Pavel Machek wrote:
Hi!
You have general-purpose LED, yet you are treating it as "something special". That means ugly code (quoted above) and lack of flexibility.
For example, if my notebook lacks HDD LED, I can use scrollock LED for that instead. Or, in reverse way, maybe "mic mute" LED is not useful for me, and I'd like to use it for notifications instead.
I'm not against adding the LEDs device implementation for any exotic usage.
But for the audio mute LED features, you'll need really lots of other works if it were implemented via leds device. That's the hardest part, and a few lines of hooks solves it easily in the kernel side. That's all about it.
If you are ready for submitting the real solutions in user-space side (patching PulseAudio and whatever all existing sound daemons, and creating yet another daemon for non-PA systems (another footprint, lovely), and so on), we can happily delete such in-kernel hooks :)
I'm not saying we should move it to the userspace.
I'm saying this should be "normal" led. drivers/leds/led-huawei-acpi.c, or something. Perhaps this acpi stuff is so similar you don't really need .c code.
And then there should be a "mic muted" trigger. Similar to drivers/leds/trigger/ledtrig-disk.c.
And who will trigger this, e.g. when the mixer is muted?
Is this settled? I'm encouraged to promote this series to our for-next branch.
I'd prefer this to be normal LED and "mic muted" to become normal trigger.
Pavel