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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 05. 01. 24 0:41, Bernhard Seibold wrote:
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.

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.

						Jaroslav

--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.





[Index of Archives]     [Pulseaudio]     [Linux Audio Users]     [ALSA Devel]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux