From: Mario Limonciello <mario.limoncie...@amd.com> During the 2025 Display Next Hackfest the topic from the 2024 display next hackfest about what to do with adaptive backlight modulation was revisited.
The general consensus was that the 2024 proposed solution [1] although functional was not desirable because it was a binary decision that the compositor could decide to enable/disable but still couldn't control the intensity. The new proposal was to return back to a vendor property. I prototyped this and wanted to balance the existing userspace using a sysfs file, and thus it's an enum that will default to letting the sysfs file work, but if the compositor sets the property to any other value the sysfs file will turn read only. I have not yet done IGT for this, but wanted to get it on the list to make sure folks are amenable to the approach. If so; I'll write up an IGT test for it too. Link: https://lore.kernel.org/dri-devel/20250621152657.1048807-1-supe...@kernel.org/T/#m71d78efe2ef1d6c680b26fca3f74f07a3d9af6f9 [1] Mario Limonciello (1): drm/amd: Re-introduce property to control adaptive backlight modulation drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +++++ drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++++++++++++++++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + 4 files changed, 38 insertions(+), 2 deletions(-) -- 2.43.0
