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. >From my experience with ThinkPads, the default brightness range there was fine for me. But on the Framework 13 AMD it is not. > 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. I'm not a fan. It seems much too complicated for most users. Some more background to the Framework 13 AMD case: The same panel on the Intel variant already goes darker. The last responses we got from Framework didn't indicate that the high minimum brightness was intentional [0], [1]. Coincidentally the "12" returned from ATIF matches AMDGPU_DM_DEFAULT_MIN_BACKLIGHT, so maybe the firmware is just not set up completely. > 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. This also seems much too complicated for normal users. [0] https://community.frame.work/t/25711/26 [1] https://community.frame.work/t/47036/7
