From: Hans de Goede <hdegoede@redhat.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Matt Hartley" <matt.hartley@gmail.com>,
"Kieran Levin" <ktl@framework.net>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Dustin Howett <dustin@howett.net>
Subject: Re: [PATCH v2 0/3] drm: backlight quirk infrastructure and lower minimum for Framework AMD 13
Date: Mon, 24 Jun 2024 11:11:40 +0200 [thread overview]
Message-ID: <e61010e4-cb49-44d6-8f0d-044a193d29b2@redhat.com> (raw)
In-Reply-To: <20240623-amdgpu-min-backlight-quirk-v2-0-cecf7f49da9b@weissschuh.net>
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@weissschuh.net/
>
> ---
> 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@weissschuh.net
>
> ---
> 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,
next prev parent reply other threads:[~2024-06-24 9:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-23 8:51 [PATCH v2 0/3] drm: backlight quirk infrastructure and lower minimum for Framework AMD 13 Thomas Weißschuh
2024-06-23 8:51 ` [PATCH v2 1/3] drm: Add panel backlight quirks Thomas Weißschuh
2024-06-23 20:20 ` Mario Limonciello
2024-06-23 20:55 ` Hans de Goede
2024-06-24 18:37 ` Mario Limonciello
2024-06-24 9:00 ` Hans de Goede
2024-06-29 4:52 ` Jeff Johnson
2024-06-23 8:51 ` [PATCH v2 2/3] drm: panel-backlight-quirks: Add Framework 13 matte panel Thomas Weißschuh
2024-06-23 8:51 ` [PATCH v2 3/3] drm/amd/display: Add support backlight quirks Thomas Weißschuh
2024-06-24 9:11 ` Hans de Goede [this message]
2024-06-24 16:15 ` [PATCH v2 0/3] drm: backlight quirk infrastructure and lower minimum for Framework AMD 13 Thomas Weißschuh
2024-07-18 8:25 ` Hans de Goede
2024-07-20 7:31 ` Thomas Weißschuh
2024-07-22 11:53 ` Hans de Goede
2024-07-24 8:57 ` Jani Nikula
2024-07-24 15:53 ` Alex Deucher
2024-07-02 13:12 ` Mario Limonciello
2024-08-05 12:55 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e61010e4-cb49-44d6-8f0d-044a193d29b2@redhat.com \
--to=hdegoede@redhat.com \
--cc=Rodrigo.Siqueira@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=dustin@howett.net \
--cc=harry.wentland@amd.com \
--cc=ktl@framework.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mario.limonciello@amd.com \
--cc=matt.hartley@gmail.com \
--cc=mripard@kernel.org \
--cc=sunpeng.li@amd.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox