Screen brigfhtness ichanges when opening wayland screen (wayfire) - Yoga slim7 Gen8 7840S API

Acvtually the issu happen when

1. Login to a system to console mode, set brightness to 5% (light -S 5 or direct in sysfs) run compositor from command line. Screen brightness go up.
2. Turn brigtness down to 5% in wayfire screen, switch to text console and back to wayfire - again screen brightness goes up.
3. Turn brightness to 5% in wayfire and then screen blanks at idle. Touch key or mouse - screen again runs on the much higher brightness.

In all cases in the /sys/class/backlight/amdgpu_bl0 directory brightness keep the value I set (5%) - but the actual brightness is different. So system somehpw ignores the value in brightness and not setting actual brightness the same but fill it with some default.

So seems that when screen in wayland activates the driver is doing something automatically that it should not - ideally if I set the brigtness I want to keep it at my preference not to be set by some default. I've also opened the bug on wayfire git - but that seems to be amdgpu issue, because I've tried exactly same setup on other laptop based on Intel Ultra 185H and there the same actions with switching between wayfire and text console or blanking screen on idle timeout keep the brightness exactly same as it was set up by me.

This might be a visible artifact of panel power saving (Adaptive Backlight Modulation). It's turned on by power-profiles-daemon and tuned in certain situations.

To confirm if that's the cause when this is happening check the value of /sys/class/drm/card0/card0-eDP-1/amdgpu/panel_power_savings when you observe this issue. If it's non-zero, set it to zero and see if the issue goes away.

I do not have such directory in sysfs. DO I need some special parameters to the amdgpu to see it?

@mark.herbert42 the path might be slightly different, for example card1 instead of card0, and you need root bash to check it

edit: actually in my testing root is not needed to read it

removed completely power-profiles-daemon,still same effect - actual brightness is set to magic number 96 always.

When the brightness changed I can issue the command

cat /sys/class/backlight/amdgpu_bl0/brightness| tee >/sys/class/backlight/amdgpu_bl0/brightness

so just read the value stored in brigtness and write it back there - and the actual brightness returns to what it should. The brigtness value is not changed - so it looks like only kernel can change actual brightness directly without modifying the brigtness contents.

Also noticed - each time this happens I have the message in dmesg - switching to text console or blank screen idle

[ 23.783448] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 297.555475] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 301.580645] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 391.200858] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 395.413956] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 748.759593] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 753.225857] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 810.693517] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 814.317917] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1203.472945] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1402.523255] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1851.706961] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1856.642333] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1874.587466] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 1885.426911] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data [ 2285.210498] amdgpu 0000:c3:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

The log with diagnostic data:

log.txt

Found from where magical 96 is coming.

set_default_brightness_aux

It sets 150000 as default because read default brightness function returns 0. And this function set default brightness is always called for oled displays. On dpms and on link training when we do switch from text mode (linux console) to graphics mode (wayland).

How I see in /sys/class/backlight/amdgpu_bl0/brightness the brigtness that was set up bu user is stored - so the driver knows about this brightness. So the question - is it possible instead of reading default brightness from BIOS use this /sys/class/backlight/amdgpu_bl0/brightness value? And if this value is not set (0 or huge ) fallback to read from bios and if bios is wrong go to hardcoded? I do not know here the brightness value is kept so can not make this patch myself...

Ah, it's an OLED panel. That's why ABM isn't exposed. It's by design.

So the driver stores this information in the struct backlight_device in amdgpu_dm.c. You can see amdgpu_dm_backlight_set_level() and amdgpu_dm_update_backlight_caps() for how these are fetched from the BIOS. However they're "DM" specific not "link" specific values. So it's layering problem to fetch them from DM.

Now here's the interesting part. Ironically the last time this code was touched was from a bug you reported: https://github.com/torvalds/linux/commit/a2020be69490ee8778c59a02e7b270dfeecffbd4 which was because https://github.com/torvalds/linux/commit/d9e865826c202b262f9ee3f17a03cc4ac5d44ced changed the behavior to no longer cache the brightness value...

added DC HDR labels

Can you confirm the specific call point that's tripping this behavior? Maybe throw a dump_stack() in set_default_brightness_aux()

Maybe we can come up with an optimization to not call set_default_brightness_aux() in that situation.

I have tried to remove the call for set_default_brightness_aux() and in this case display goes to 100% brigghtness instead of keeping the brightness unchanged. So that will not be a solution. Looks like firmware is resetting the brightness when the panel goes blank for some reason and the only valid option is to cache it somewhere. And it is cached - I need just to run

cat /sys/class/backlight/amdgpu_bl0/brightness| tee >/sys/class/backlight/amdgpu_bl0/brightness

And the brightness returns exactly to a value it was. So where from the systemc shows /sys/class/backlight/amdgpu_bl0/brightness need to be used as a sorce.

Thank you very much for the information.

amdgpu_return_cached_brightess.patch

I've reverted https://github.com/torvalds/linux/commit/d9e865826c202b262f9ee3f17a03cc4ac5d44ced with a small change - moved the brightness caching from the beginning of edp_set_backlight_level_nits to the end just before return true statement - to make sure only succesfully set brightness will get cached. Works for me perfectly.

The idea of setting default brightness for me looks wrong. It is a kind of workaround - well, if the rest does not work and you get black screen or super-bright screen (oled burns - so there are no oled owners who would like to default to 100%). But in general if your brightness auto-change every time you screen blanks to dpms, or you watch movie in fullscreen or play game with changed resolution or go to text console - that looks wrong. Fortunately the most time screen is pretty comfort at around 200 nits which seems to be my default and this does not seems very annoying. Unless you start working in dark environments for example and need much less brightness....

Now I have a patch that solves my issue - this ugly Yoga Slim 7 does not work with mainstream drivers anyway and need patched deivers, specific firmware version and so on. But how to make the universal solution to cover cases of oled screens that does not need the "default brightness" workaround and HDR minileds that were the reason to place it I do not know.

Would you mind bringing your patch to the amd-gfx mailing lists with the original author (Camille Cho <camille.cho@amd.com>) on the to line?

I think it's best to discuss it directly with them on the merits and impacts for HDR brightness.

I wold like to bit have no idea how to do it. If you can do it would be great.
In act my patch is mainly revert of the original patch with a little change, and for my hardware it works just perfectly this way. But I do not have HDR miniled to check if it still will be an issue on miniled.

I'll try to start an internal thread about it.

Just an update on this issue, it was reproduced and we have an internal fix for it that is under code review and validation. If everything looks good it should be part of the display team patch promotion in a week or two.

Here's the fix.

added bisected label

mentioned in commit agd5f/linux@7875afaf

mentioned in commit agd5f/linux@4f26c95f

mentioned in commit nouveau@d83c747a

closed