Raspberry Pi 7" display brightness fix

[breakingspell]

Brightness path:

Raspberry Pi's official DSI-based display will present itself differently when the unit is using the vc4-kms-v3d driver. This breaks the backlight level control provided with the dash brightness plugin. To replicate, set in /boot/firmware/config.txt and observe path:

dtoverlay=vc4-fkms-v3d - /sys/class/backlight/rpi_backlight/brightness
dtoverlay=vc4-kms-v3d - /sys/class/backlight/10-0045/brightness

This PR fixes the path by checking for one and using the other if it doesn't exist.

It's worth noting that the DSI display seems to have trouble with the kms driver unless dtoverlay=vc4-kms-dsi-7inch is also loaded. I use the fkms fallback and it seems to works fine without hardware encoding. Also worth noting the existing RPi udev brightness permission works for both cases (/sys/class/backlight/%k/brightness)

Brightness range:

I noticed that the display's brightness range is rather odd, the brightest value is actually 200 while maximum value 255 is slightly dimmer. Plus, steps are much more pronounced between 0-100 as they are between 100-200. Someone made a comment about it ages ago, and about the energy draw as well.

I adjusted the min and max values from 76-255 to 20-180 (imperceptible from 200) and the step change to 20 units. However, I realize after posting the commit that this particular range affects all brightness operations using Session::System::Brightness, not just for the specific RPi display. Posting for review regardless, I may separate the range fix into it's own PR while seeing if it can be narrowed to only this panel.

Related issue (if applicable): fixes #
#149

[rsjudka]

ill test out with the new brightness range using the mocked plugin (essentially just adjusts opacity) but from an initial glance i think that may cause an issue

it might be easy enough to get the min and max from the brightness module.. maybe?

[breakingspell]

The range oddity is specific to that RPi first-party panel (mine is manufactured by element14), so the new range may break the mock plugin and every other display, whoops :)

I'm thinking it may be possible to identify these specific panels and override the range only then.

[breakingspell]

Had the idea to possibly relocate the brightness range/step integers from arbiter.cpp to the brightness plugins themselves (mocked, official_rpi, x). Each supported display type would define their ranges there, while session.cpp would only call for a unit step up or down to set brightness.

This would be cleaner than identifying hardware and overriding the values in the session/arbiter to accommodate for one odd panel model.

[nakato]

it might be easy enough to get the min and max from the brightness module.. maybe?

Looks like it's hard-coded currently. https://github.com/raspberrypi/linux/blob/da87f91ad8450ccc5274cd7b6ba8d823b396c96f/drivers/regulator/rpi-panel-attiny-regulator.c#L340

If some panels are brightest at 255 and others 200, it would be worthwhile changing the driver in the kernel to get the max-brightness from the DeviceTree so it can be configured based on the hardware in use, and then the sysfs max-brightness value would reflect that.

[breakingspell]

Went for a night drive recently and realized I didn't have this patch installed on my device, just tested with it and for some reason the path check no longer seems to work.
Neither brightness path will respond to requests from Dash app, but I can still set the brightness manually using # echo 100 > /sys/class/backlight/10-0045/brightness

Separated the brightness range commit from the PR while I work on this, the old adjustment is here for reference: breakingspell@2d77123. Detecting the specific models and adjusting just for them is probably the best solution, can save that for another PR.

C++ isn't my strong suit, I have a feeling the check was flawed and needs done another way. Will post once I have an update!

[breakingspell]

Ignore most of my previous update: I was missing the required udev brightness rule from the installer 😅
With the udev rule in place, the fix in this PR works as intended to control brightness within Dash app.

Before merging, let's wait for some tests and feedback on the fix