Hi!
Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in the speaker- and/or mic-mute keys on the keyboard.
Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock) and the HP x2 10 series.
The detachable nature of these keyboards means that the keyboard and thus the mute LEDs may show up after the user (or userspace restoring old mixer settings) has muted the speaker and/or mic.
Current LED-class devices with a default_trigger of "audio-mute" or "audio-micmute" initialize the brightness member of led_classdev with ledtrig_audio_get() before registering the LED.
This makes the software state after attaching the keyboard match the actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will show the right value.
Makes sense.
+++ b/drivers/leds/trigger/ledtrig-audio.c @@ -6,10 +6,33 @@ #include <linux/kernel.h> #include <linux/leds.h> #include <linux/module.h> +#include "../leds.h"
-static struct led_trigger *ledtrig_audio[NUM_AUDIO_LEDS]; static enum led_brightness audio_state[NUM_AUDIO_LEDS];
+static int ledtrig_audio_mute_activate(struct led_classdev *led_cdev) +{
- led_set_brightness_nosleep(led_cdev, audio_state[LED_AUDIO_MUTE]);
- return 0;
+}
Is mute_activate called from atomic context?
Best regards, Pavel