Re: [PATCH v2 0/3] drm: backlight quirk infrastructure and lower minimum for Framework AMD 13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans!

thanks for your feedback!

On 2024-06-24 11:11:40+0000, Hans de Goede wrote:
> 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.

There are a fair amount of complaints on the Framework forums about this.
And that specific panel is actually readable even at 0% PWM.

> 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

Indeed, but IMO it is better to maintain the list in the kernel than
forcing all users to resort to random forum advise and fiddle with
lowlevel system configuration.

> b) The new value may be too low for certain users / use-cases

The various userspace wrappers already are applying a safety
threshold to not go to "0".
At least gnome-settings-daemon and brightnessctl do not go below 1% of
brightness_max. They already have to deal with panels that can go
completely dark.

> 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.


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux