vc4 gamma fixes#4682
Conversation
|
Tested on Pi4. The |
|
Interestingly leaving the Pi with bright HDMI0 for 30 minutes resulted in both displays blanking for a couple of seconds and they came back without the brightness issue. I wonder if X does send a gamma command after 30 mins (screensaver/screen blanking?). But it didn't remain black. |
|
I need to make sure I've pushed the latest changes (found a couple of other issues at the same time, and testing Pi3 has been awkward). |
The code falls through to "fail" under all conditions, so there is no need for the drm_property_blob_put if the gamma lut hasn't been changed. Fixes: 9cca266 "drm: Check whether the gamma lut has changed before updating" Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
With HVS5 the gamma block is now only reprogrammed with a disable/enable. Loading the table from vc4_hvs_init_channel (called from vc4_hvs_atomic_enable) appears to be at an invalid point in time and so isn't applied. Switch to enabling and disabling the gamma table instead. This isn't safe if the pipeline is running, but it isn't now. For HVS4 it is safe to enable and disable dynamically, so adopt that approach there too. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Two calls were made to drm_crtc_enable_color_mgmt to add gamma and CTM, however they were both set to add the gamma properties, so they ended up added twice. Fixes: 766cc6b "drm/vc4: Add CTM support" Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
edt-ft5406.dtsi is included from vc4-kms-dsi-7inch which was also setting i2c0mux and i2c0if status fields. This meant that dtoverlay wouldn't apply the overlay due to multiple fragments changing the same parameter. Move the enable from edt-ft5406.dtsi to edt-ft5406-overlay.dts for when it should be needed as an independent overlay. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
|
Branch rebased and latest changes pushed. I'm not seeing odd gamma tables with that.
For Pi0-3, the vc4 docs are not 100% clear whether it is legitimate to enable/disable gamma whilst active, but it seems to behave itself even if you do, so I'm happy enough with the patches as they stand. |
Add a check to vc4_hvs_gamma_check to ensure a new non-empty gamma LUT is of the correct length before accepting it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
|
Added another patch that validates the gamma LUT blob is of the correct length as I don't believe the framework does it for us. (Rockchip is certainly validating it within the driver). |
|
I'm still getting bright hdmi0 (until 30 minutes). |
Please confirm details to reproduce? Bullseye or Buster? Presumably X from your earlier description. Booting direct to X or console? |
|
It's bullseye. Set to boot to desktop with auto login. Two 4kp30 hdmi displays. |
|
The patches appear to have been pushed manually by popcornmix last night, so the merge of this PR actually did nothing. However the changes are in there now. |
I need to check that Pi3 is happy. Pi4 seems to be.