[SOLVED] Can this led toggle script be made more efficient (thinkpad)?

mongoose088 · 2022-04-12 03:27:07

Hello all,

I am using a thinkpad T470 with Arch. There is a mute key led that illuminates when "FN + F1" is pressed.

It does not work out of the box, so I enabled the functionality using a script.

In my ~/.config/i3/config file, I call the script with the following:

exec_always --no-startup-id $HOME/.scripts/led_toggle.sh

And the working script is as follows:

#!/bin/sh
while :
do

	mute_status=$(amixer sget Master | awk '/Mono/ {print $6}')

	if [ $mute_status = "[off]" ];
	then
		brightnessctl --device 'platform::mute' set 1
	fi

	if [ $mute_status = "[on]" ];
	then
		brightnessctl --device 'platform::mute' set 0
	fi

	sleep 25
done

Per htop, this applies about a 7% load against my CPU. I am wondering the following:

Is that too high for a simple script? There are daemons running in the background using less than 1%. I feel like there must be a more "proper" way to monitor the status of an LED being toggled that is less resource intensive, but I've never used a script like this before.

Last edited by mongoose088 (2022-04-13 02:02:06)

Trilby · 2022-04-12 03:37:08

mongoose088 wrote:

Per htop, this applies about a 7% load against my CPU.

That's not really possible with that script. Are you sure you weren't looking at the wrong line?

Overall though, you should fix the original problem rather than running a script like this that could lag in setting the led by up to 25 seconds. What's the output of `cat /sys/class/leds/platform::mute/trigger`?

Alternatively, if you only toggle the mute with a key press, just set the led in the same key binding that sets/toggles the mute rather than doing so continuously in a loop.

Last edited by Trilby (2022-04-12 03:39:58)

mongoose088 · 2022-04-13 00:28:06

Trilby wrote:

That's not really possible with that script. Are you sure you weren't looking at the wrong line?

You're right, it was weird to me too. I took a screenshot, but honestly, it must have been some kind of strange behavior.

htop

Trilby wrote:

Overall though, you should fix the original problem rather than running a script like this that could lag in setting the led by up to 25 seconds. What's the output of `cat /sys/class/leds/platform::mute/trigger`?
Alternatively, if you only toggle the mute with a key press, just set the led in the same key binding that sets/toggles the mute rather than doing so continuously in a loop.

Thank you! Your cat command hint pushed me in the right direction, and I completely fixed my script.

My code lacks polish, but I went this way to be sure that the mute key would not "de-sync" from the status of the volume, and it does work:

#!/bin/bash
muteLED(){

	mute_status=$(amixer sget Master | awk '/Mono/ {print $6}')

	if [ $mute_status = "[off]" ];
	then
		result=1
	fi

	if [ $mute_status = "[on]" ];
	then
		result=0
	fi
}
muteLED
sudo sh -c "printf "%d" $result > /sys/class/leds/platform\:\:mute/brightness"

Last edited by mongoose088 (2022-04-13 01:06:16)

Trilby · 2022-04-13 00:45:44

That's not really any different - you are still working around a problem that should exist which is why I asked for the output of the cat command to start diagnosing what's actually wrong.

But if you really go with the script, you shouldn't need a root shell every time through, and using sudo there is odd ... have you put a NOPASSWD entry in sudoers for that full command string? If not, how can that work at all? In anycase, don't run the full shell as root, just the command to write to the file, e.g.:

echo $result | sudo tee /sys/class/leds/platform::mute/brightness

mongoose088 · 2022-04-13 01:04:07

Trilby wrote:

That's not really any different - you are still working around a problem that should exist which is why I asked for the output of the cat command to start diagnosing what's actually wrong.
But if you really go with the script, you shouldn't need a root shell every time through, and using sudo there is odd ... have you put a NOPASSWD entry in sudoers for that full command string? If not, how can that work at all? In anycase, don't run the full shell as root, just the command to write to the file, e.g.:
echo $result | sudo tee /sys/class/leds/platform::mute/brightness

Ah, okay, I misunderstood you. I thought the issue was how I used an infinite loop to keep checking on the status of something, rather than checking for the status "as needed".

So, I did the code change you suggested, and it doesn't seem to work. I get this error:

tee: '/sys/class/leds/platform::mute/brightness': Invalid argument

But I'm much more interested in the actual solution you're talking about. So, the cat output you requested...

$ cat /sys/class/leds/platform::mute/trigger
[none] usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 panic BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid BAT1-charging-or-full BAT1-charging BAT1-full BAT1-charging-blink-full-solid rfkill-any rfkill-none audio-mute audio-micmute rfkill0 ucsi-source-psy-USBC000:001-online phy0rx phy0tx phy0assoc phy0radio rfkill1 bluetooth-power

Last edited by mongoose088 (2022-04-13 01:06:49)

Trilby · 2022-04-13 01:39:37

Well there's the problem, the trigger is disabled, but audio-mute is available as an option. The following should fix it at least for your current boot:

echo "audio-mute" | sudo tee /sys/class/leds/platform::mute/trigger

Run this, then test whether toggling the audio-mute changes the led (it should). If it does, then we just need to make this permanent.

EDIT: and you're right that I had also commented on your script's infinite loop. In my follow-up I neglected the improvement you made on that. But in any case, I dont think that sort of script is really the right approach; I just can't help but comment on scripts that could be improved.

Last edited by Trilby (2022-04-13 01:43:45)

mongoose088 · 2022-04-13 01:46:44

Trilby wrote:

Well there's the problem, the trigger is disabled, but audio-mute is available as an option. The following should fix it at least for your current boot:
echo "audio-mute" | sudo tee /sys/class/leds/platform::mute/trigger
Run this, then test whether toggling the audio-mute changes the led (it should). If it does, then we just need to make this permanent.
EDIT: and you're right that I had also commented on your script's infinite loop. In my follow-up I neglected the improvement you made on that. But in any case, I dont think that sort of script is really the right approach; I just can't help but comment on scripts that could be improved.

Yep, running that command indeed now toggles auto-mute. What's the move to make it permanent?

Also, if I want to generally learn about the /sys/class structure, what should I be reading?

Trilby · 2022-04-13 01:57:33

mongoose088 wrote:

Also, if I want to generally learn about the /sys/class structure, what should I be reading?

I'm the wrong one to ask. What I know comes from trial and error ... and lots of random flailing. It would all be in the kernel documentation somewhere - but I don't have any references.

But there are some common patterns such as the trigger 'file' giving a list of options with the selected one displayed in brackets. You select another option by echoing/writing the desired value to the 'file'. I put 'file' in quotes as none of these are actual files, but are rather interfaces to kernel strucutres / objects that each just have hooks for normal file-like operations. A similar list / selection mechanic is used for things like the cpu and IO schedulers.

In any case, you could test whether this setting would persist after a reboot, but I highly doubt that it would. If it doesn't, you just need to run some command on every boot to similarly write "adio-mute" to that 'file'. I suspect the technically correct way to do this would be with a udev rule, but I'm not well versed in those. A systemd service that just echoes to the file should also suffice.

Also note that this still isn't a full solution as the question remains why that trigger is disabled in the first place. Is it possible that any other script you had been working on for related purposes may have written to that file by accident? (I suspect writing a non-matching string to the file would result in selection of the "none" option).

Last edited by Trilby (2022-04-13 01:59:31)

mongoose088 · 2022-04-13 02:01:14

Trilby wrote:

I'm the wrong one to ask. What I know comes from trial and error ... and lots of random flailing.

You've described my troubleshooting process rather succintly.

Trilby wrote:

In any case, you could test whether this setting would persist after a reboot, but I highly doubt that it would. If it doesn't, you just need to run some command on every boot to similarly write "adio-mute" to that 'file'. I suspect the technically correct way to do this would be with a udev rule, but I'm not well versed in those. A systemd service that just echoes to the file should also suffice.

I can definitely work with that. I will mark this one as solved. Thanks again for your help and pointers!

For completeness sake...

I chose to create a systemd service. First I created an executable file: /usr/local/sbin/led_toggle.sh

#!/bin/bash
echo "audio-mute" | sudo tee /sys/class/leds/platform::mute/trigger

Next I created a service file: /etc/systemd/system/led_toggle.service

[Unit]
Description=Sends audio-mute trigger to /sys/class/leds/ so kbd audio mute light works.

[Service]
ExecStart=/usr/local/sbin/led_toggle.sh

[Install]
WantedBy=multi-user.target

Finally, I ran "sudo systemctl enable led_toggle.service", and everything was okay on reboot.

Last edited by mongoose088 (2022-04-15 04:04:25)

Arch Linux

#1 2022-04-12 03:27:07

[SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#2 2022-04-12 03:37:08

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#3 2022-04-13 00:28:06

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#4 2022-04-13 00:45:44

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#5 2022-04-13 01:04:07

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#6 2022-04-13 01:39:37

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#7 2022-04-13 01:46:44

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#8 2022-04-13 01:57:33

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

#9 2022-04-13 02:01:14

Re: [SOLVED] Can this led toggle script be made more efficient (thinkpad)?

Board footer