Hi Thomas, On 6/23/24 10:51 AM, Thomas Weißschuh wrote: > The value of "min_input_signal" returned from ATIF on a Framework AMD 13 > is "12". This leads to a fairly bright minimum display backlight. > > Add a generic quirk infrastructure for backlight configuration to > override the settings provided by the firmware. > Also add amdgpu as a user of that infrastructure and a quirk for the > Framework 13 matte panel. > Most likely this will also work for the glossy panel, but I can't test > that. > > One solution would be a fixed firmware version, but given that the > problem exists since the release of the hardware, it has been known for > a month that the hardware can go lower and there was no acknowledgment > from Framework in any way, I'd like to explore this alternative > way forward. There are many panels where the brightness can go lower then the advertised minimum brightness by the firmware (e.g. VBT for i915). For most users the minimum brightness is fine, especially since going lower often may lead to an unreadable screen when indoors (not in the full sun) during daylight hours. And some users get confused by the unreadable screen and find it hard to recover things from this state. So IMHO we should not be overriding the minimum brightness from the firmware using quirks because: a) This is going to be an endless game of whack-a-mole b) The new value may be too low for certain users / use-cases With that said I realize that there are also many users who want to have a lower minimum brightness value for use in the evening, since they find the available minimum value still too bright. I know some people want this for e.g. various ThinkPad models too. So rather then quirking this, with the above mentioned disadvantages I believe that it would be better to extend the existing video=eDP-1:.... kernel commandline parsing to allow overriding the minimum brightness in a driver agnostic way. The minimum brightness override set this way will still need hooking up in each driver separately but by using the video=eDP-1:... mechanism we can document how to do this in driver independent manner. since I know there have been multiple requests for something like this in the past I believe that having a single uniform way for users to do this will be good. Alternatively we could have each driver have a driver specific module- parameter for this. Either way I think we need some way for users to override this as a config/setting tweak rather then use quirks for this. Regards, Hans > > Notes: > > * Should the quirk infrastructure be part of drm_edid.c? > * The current allocation of struct drm_edid in amdgpu is bad. > But it is done the same way in other parts of amdgpu. > I do have patches migrating amdgpu to proper usage of struct drm_edid [0] > > Mario: > > I intentionally left out the consideration of the firmware version. > The quirk will stay correct even if the firmware starts reporting > correct values. > If there are strong opinions it would be easy to add, though. > > Based on amdgpu/drm-next. > > [0] https://lore.kernel.org/lkml/20240616-amdgpu-edid-bios-v1-1-2874f212b365@xxxxxxxxxxxxxx/ > > --- > Changes in v2: > - Introduce proper drm backlight quirk infrastructure > - Quirk by EDID and DMI instead of only DMI > - Limit quirk to only single Framework 13 matte panel > - Link to v1: https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5b2a@xxxxxxxxxxxxxx > > --- > Thomas Weißschuh (3): > drm: Add panel backlight quirks > drm: panel-backlight-quirks: Add Framework 13 matte panel > drm/amd/display: Add support backlight quirks > > Documentation/gpu/drm-kms-helpers.rst | 3 + > drivers/gpu/drm/Kconfig | 4 ++ > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +++++++++ > drivers/gpu/drm/drm_panel_backlight_quirks.c | 76 +++++++++++++++++++++++ > include/drm/drm_utils.h | 11 ++++ > 7 files changed, 124 insertions(+) > --- > base-commit: 1ecef5589320fd56af599b624d59c355d162ac7b > change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a > > Best regards,
