SUMMARY Because the backlighthelper prioritizes led sysfs entries with "lcd" in the name before everything else it thinks "/sys/class/leds/g15::lcd_backlight/" is the path for screen brightness and it ignores the "/sys/class/backlight/intel_backlight/" STEPS TO REPRODUCE 1. Connect a Logitech G15 2. Try to change screen brightness 3. cry OBSERVED RESULT Brightness of the keyboard lcd changes EXPECTED RESULT Brightness of the laptop screen changes SOFTWARE/OS VERSIONS KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
Based on merely reading the code, this still seems to apply to Plasma 6.0, at least up to 6.0.3. Assuming that the "lcd" match was put there for a good reason (prior work in Bug 399646 / commit https://invent.kde.org/plasma/powerdevil/-/commit/401e3ed8999e22d5653fac9cb3d78a638c742825) then I'm not sure what a "generic" fix would look like. Apart from the fix that's planned for the Linux kernel but will apparently still take a good while to actually arrive. An obvious solution would be to exclude known devices such as this G15 from the list of matches, but where could we get a list of "bad matches" to ignore?
Perhaps we can exclude matches for more specific LED class specializations, such as multicolor LEDs. Could you confirm whether the g15::lcd_backlight directory contains a multi_intensity file as per https://www.kernel.org/doc/html/latest/leds/leds-class-multicolor.html?
I wonder whether we should actually keep LED class detection around in PowerDevil at all. The original introduction was in 2016 via https://phabricator.kde.org/D2419 where Bhushan Shah added LED handling for "some devices", with "an example" being the Nexus 5. No other devices were named, it's unclear to me how the "wled" identifier adds anything of value. Whichever way you slice it, it seems like a stretch to assume that *any* kind of LCD backlight is indeed the display backlight. The Nexus 5 support itself appears to be getting hooked up to the standard backlight class in 2024: https://lore.kernel.org/lkml/20240220-lm3630a-fixups-v1-4-9ca62f7e4a33@z3ntu.xyz/ I would like to make the case for removing the LED class detection entirely and redirecting any resulting bug reports (will there be any at all?) to the kernel bug tracker, where the proper fix is to hook up the respective LED to the backlight interface.