This would change the specification of $BACKLIGHT_SEARCH_PATH, technically, in a backwards-incompatible fashion.
Namely, if your $BACKLIGHT_SEARCH_PATH currently includes a :, this change would cause unexpected behavior.
The proposal is to make $BACKLIGHT_SEARCH_PATH:-aware (like $PATH), thus allowing users to define multiple paths to search for candidates. The default value is then likely to become /sys/class/backlight:/sys/class/leds (which, for example, would allow for modifying the keyboard backlight rather than the screen backlight only needing to change one environment variable, rather than two).
Work necessary to complete this:
[x] change the internal fallback value of $BACKLIGHT_SEARCH_PATH to /sys/class/backlight:/sys/class/leds
[x] make l:-aware when searching for and returning candidates
[x] add a routine to go through the paths listed in $BACKLIGHT_SEARCH_PATH attempting to find the target device name before continuing with the brightness modification
[x] add a test to check that l and [-.+]<#>[%] properly discover/target a device in a :-specified path
This would change the specification of
$BACKLIGHT_SEARCH_PATH
, technically, in a backwards-incompatible fashion.Namely, if your
$BACKLIGHT_SEARCH_PATH
currently includes a:
, this change would cause unexpected behavior.The proposal is to make
$BACKLIGHT_SEARCH_PATH
:
-aware (like$PATH
), thus allowing users to define multiple paths to search for candidates. The default value is then likely to become/sys/class/backlight:/sys/class/leds
(which, for example, would allow for modifying the keyboard backlight rather than the screen backlight only needing to change one environment variable, rather than two).Work necessary to complete this:
$BACKLIGHT_SEARCH_PATH
to/sys/class/backlight:/sys/class/leds
l
:
-aware when searching for and returning candidates$BACKLIGHT_SEARCH_PATH
attempting to find the target device name before continuing with the brightness modificationl
and[-.+]<#>[%]
properly discover/target a device in a:
-specified path