Re: Re: [PATCH] ALSA: hda: generic: Always add LED controls

[Bernhard Seibold <mail@xxxxxxxxxxxxxxxxxxx>]

On Thu, Jan 04, 2024 at 10:46:04PM +0100, Jaroslav Kysela wrote:
> On 04. 01. 24 20:14, Bernhard Seibold wrote:
> > On Thu, Jan 04, 2024 at 05:41:48PM +0100, Takashi Iwai wrote:
> > > On Thu, 04 Jan 2024 16:58:38 +0100,
> > > Bernhard Seibold wrote:
> > > > 
> > > > LEDs for mute and microphone mute can be added to any system via the
> > > > audio-mute and audio-micmute triggers, e.g. via USB HID devices.
> > > > Therefore, add the LED controls unconditionally.
> > > 
> > > Hmm...  Won't your change lead to the sysfs entries always,
> > > i.e. creating sysfs entries even if the device has no LED at all?
> > 
> > This patch is not affecting create_mute_led_cdev, that function is still
> > only called for some special systems via fixups, to create the actual
> > LED classdevs that are present on there.
> > 
> > What I'm trying to change is to have the led-ctls always available. They
> > serve as input to the audio-mute and audio-micmute triggers, and these
> > triggers should work on any system with HD Audio, not just a few.
> > 
> > It would be even better to move the whole functionality into the sound
> > core so that it works with other drivers as well, but since yesterday was
> > the first time I even looked at sound code, I wouldn't even know where
> > to start.
> 
> You can attach controls using sysfs for special use cases. If the system has
> audio LED driver controlled in other code, the HDA driver should be notified
> somehow to create triggers, otherwise the default (current) functionality is
> fine in my eyes.

I've got a USB keyboard that has LEDs for mute and for microphone mute,
and these currently do not work as expected. I'm not sure how special
that use-case is, but I don't think expecting users to manually fiddle
around in sysfs to get their keyboard LEDs working is a good solution.

Regards,
Bernhard