add rt713 & rt1318 LED control

[shumingfan]

add rt713 & rt1318 LED control

[mrhpearson]

Just a note that I've tested this on Fedora 41 on a X1 Carbon G13 (Lunarlake) and can confirm that both Mic and Speaker LEDs are working correctly.

(I did pull in upstream kernel commit as well https://patchwork.kernel.org/project/alsa-devel/patch/20250226084728.1889082-1-shumingf@realtek.com/ )

[Ameer-Ivan]

To add to this, I've also tested on X1 Carbon G13 and an X1 2-in-1 Gen 10 (both LunarLake) and also confirmed that the Mic and speaker LED's are working correctly. @perexg apologies for suddenly pulling you in, may I ask for your help in reviewing this patch? we are trying to get this included on the upcoming SRU cycle on 3/14 if possible.

[perexg]

I don't like this settings. Is there other reason other than LED control to mark those devices conflicting together?

[shumingfan]

@perexg The customer's machine has one speaker mute LED and also wants to mute the output of the headphones.
Therefore, we added device conflicting to avoid the speaker being on while the headphones are plugged.
e.g.
We registered two controls for the speaker mute LED.
attach:rt1318-1 DAC Switch
attach:rt713 FU05 Playback Switch
The kernel driver (control_led.c) will check these two controls. These two controls turn off, LED could turn ON.
Therefore, we set conflicting devices for the speaker and headphones each other.

[perexg]

I tried to improve the LED settings in PR #517 and included those changes (except the ConflictingDevice change). It would be nice, if you can retest those changes, too.

[perexg]

Also, starring at PR #487, we need really define the circumstances when LEDs should follow some inputs or outputs. For me, the logical way is to follow only internal microphone and internal speakers. If you plug USB headset for example, then LEDs are not controlled, too. It should be highly confusing to users.

Also see issue #440 . Here user expects different way, but "selected output" is problem for external hw like mentioned USB devices.

[shumingfan]

I tried to improve the LED settings in PR #517 and included those changes (except the ConflictingDevice change). It would be nice, if you can retest those changes, too.

@perexg I will test PR #517 tomorrow. If there are any results, I will get back to you.

[shumingfan]

I tried to improve the LED settings in PR #517 and included those changes (except the ConflictingDevice change). It would be nice, if you can retest those changes, too.

@perexg I will test PR #517 tomorrow. If there are any results, I will get back to you.

@perexg I tested PR #517 on Lenovo machine (rt713+rt1318).
The capture devices(headset mic/internal mic) can control LED on/off.
The playback devices(internal speaker + headphones) can't control LED on/off.
Unless I add the conflicting device "speaker" in the Headphones section.
As I mentioned (#512 (comment)), the kernel driver will check all attached speaker controls to decide the LED on/off.

[perexg]

As I wrote, we should probably drop the LED bindings for headphones/headsets. I updated my PR #517, so only rt1318 speaker changes (with a little fix for mixer controls) are kept . I am open to any discussion for the explanation in https://github.com/alsa-project/alsa-ucm-conf/blob/4f10a8491fbb1819fe99b926de2ab1ec8befdfc7/ucm2/common/ctl/led.conf .