Re: [PATCH] drm/i915/display: Fixed a screen flickering when turning on display from off

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

 




this case have been there so many years, it's time to fix it if possible. And user-space software may improved by themselves in we didn't realize place.

even if not,  for the proof user-space setting  0, it's better to change to


   if (level < min || level == 0 )

        level =max;


Intel default FSP will set the default min is 2% (6/255). if someone missed the setting, it will be keep the default and level.min will be larger than 0.

if someone changed the default min in VBT or coreboot, the user-space lowest level set as 0, still can go though to this logic.


whatever, we think this one should correct back, otherwise it will keep occurring in each new kernel release on all Intel device, this is not very friendly to all developers.

and the only fix way is  hack patch to remove "level=max".


On 3/15/24 19:02, Ville Syrjälä wrote:
On Wed, Mar 06, 2024 at 12:19:42PM +0200, Jani Nikula wrote:
On Wed, 06 Mar 2024, gareth.yu@xxxxxxxxx wrote:
From: Gareth Yu <gareth.yu@xxxxxxxxx>

Turn on the panel from zero brightness of the last state, the panel was set
a maximum PWM in the flow. Once the panel initialization is completed, the
backlight is restored to zero brightness. There is a flckering generated.
Please be more precise in describing what exactly happens and
when. Driver probe? Modeset? What restores backlight to zero brightness?

Better yet, please file a bug at fdo gitlab, attach full dmesg with
debugs, etc.

Before we had the concept of minimum brightness, the minimum was always
0. And the check was:

	if (level == 0)
		level = max;

Historically, the point was, if you're enabling the display and
backlight, you don't want it to be at 0 brightness, because for most
displays that means a black screen.
I think that hack was originally added becaue some silly
userspace thingy was setting the backlight level to 0 on
suspend/etc. and then forgetting to restore it back to a
sane value afterwards. Dunno if that nonsense behaviour
still persists to this day.




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

  Powered by Linux