Closed ZeroErrors closed 3 years ago
i think one issue is that using the rpi screen (and in turn that brightness sysfile existing) does not necessarily guarantee brightness control will be supported (older versions of the screen dont support it). So that would be a case where auto will fail (not a major issue tho)
oh, wasn't aware that there was cases where it's not supported and the file would exist. I guess we can probably add extra checks when cases come up, if we can detect the display model or something.
hmm someone who is more familiar with the pis than myself can chime in, but I haven't heard of a way to detect the different version (v1.0 and v1.1) in sw
Description
Related issue: fixes https://github.com/openDsh/dash/issues/48
This PR adds the ability to automatically detect the supported brightness plugins.
When the config value for
brightness_plugin
is set toauto
, which is the default, we iterate the available brightness plugins and check if they are supported and select the plugin that is the highest priority supported plugin.Implementations:
official rpi
checks to see if/sys/class/backlight/rpi_backlight/brightness
is writable and has the highest priority since it provides a true brightness control when availablemocked
is always supportedx
is supported ifQGuiApplication::primaryScreen()
returned non-null and we can successfully executexrandr
Checklist: