Open karypid opened 2 months ago
I can confirm that I have the same issue on my 2022 Yoga 9i 14IAP7
@haryp2309 Can you try the rule file below and see if it makes things work?
❯ cat /etc/udev/rules.d/99-thinkpad-thresholds-udev.rules
# Change the permissions of the battery threshold attributes so that they can be modified by ordinary users
# See https://gitlab.com/marcosdalvarez/thinkpad-battery-threshold-extension
ACTION=="add|change", KERNEL=="BAT[0-1]", GROUP="wheel" , SUBSYSTEM=="power_supply", TEST=="/sys%p/charge_control_start_threshold", TEST{0002}!="/sys%p/charge_control_start_threshold", RUN+="/bin/chmod 666 /sys%p/charge_control_start_threshold"
ACTION=="add|change", KERNEL=="BAT[0-1]", GROUP="wheel" , SUBSYSTEM=="power_supply", TEST=="/sys%p/charge_control_end_threshold", TEST{0002}!="/sys%p/charge_control_end_threshold", RUN+="/bin/chmod 666 /sys%p/charge_control_end_threshold"
ACTION=="add|change", KERNEL=="BAT[0-1]", GROUP="wheel" , SUBSYSTEM=="power_supply", TEST=="/sys%p/charge_start_threshold", TEST{0002}!="/sys%p/charge_start_threshold", RUN+="/bin/chmod 666 /sys%p/charge_start_threshold"
ACTION=="add|change", KERNEL=="BAT[0-1]", GROUP="wheel" , SUBSYSTEM=="power_supply", TEST=="/sys%p/charge_stop_threshold", TEST{0002}!="/sys%p/charge_stop_threshold", RUN+="/bin/chmod 666 /sys%p/charge_stop_threshold"
Source: ublue forums thread
The udev rules from package
udev-rules-0.8-1.fc39.noarch
contain a rule in/usr/lib/udev/rules.d/99-thinkpad-thresholds-udev.rules
that attempts to change the permissions of the charge-threshold files. Presumably this is to allow the user to change the charge level without special permissions:My 2024 Yoga Pro 9i 16IMH9 does not create those charge threshold files. As a result, the udev rule keeps firing and keeps attempting to update the permissions for the 4 files. This fails as they are non-existent. Example output from system log:
The rule checks if the file with a mask, to fire when the permissions are not set, but it does not check if the file exists in the first place. This results in the above behavior.
The rule should be improved to check if the file exists at all, and then also check the permissions. This way for models without support for this the rule would not attempt running the command and would not spam the logs.