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

[Bernhard Seibold <mail@xxxxxxxxxxxxxxxxxxx>]

On Fri, Jan 05, 2024 at 10:27:52AM +0100, Jaroslav Kysela wrote:
> On 05. 01. 24 0:41, Bernhard Seibold wrote:
> > On Thu, Jan 04, 2024 at 10:46:04PM +0100, Jaroslav Kysela wrote:
> > > 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.
> 
> I see your point (and tracked your name to hid-lenovo.c which creates
> mute/micmute LED drivers for Lenovo keyboards). The question is, if the
> audio triggers should be enabled blindly (all time) or when a LED driver
> exists and is active (runtime). In later case, this can be covered using new
> udev rules. Obviously, no manual configuration from users is expected.

That would require a rule for every keyboard or other HID device with a
mute or micmute LED. I don't think this is a good idea when it could
just work out of the box.

The HID specification defines "usages" for these LEDs, so any HID device
can contain one, and this works also without device-specific drivers.

For "mute", an LED classdev is already being created by the input-leds
module. The default trigger is not yet set correctly, but I have a patch
for that. Support for "micmute" is still missing, but I'm working on
that as well.