I'm noticing that the default screen brightness of my desktop when logged in is set to something beneath "1" when set to "1" with amdgpu.dc=1 switch in the kernel. Test to get to this point: * boot PC - (Grub screen brightness is "normal") * Set kernel value amdgpu.dc=1 and proceed with 4.16.0+ kernel boot - (kernel switches quiet and splash removed, brightness appears normal during boot process) * Lightdm display manager starts (brightness is still "normal") * Log in to any window manager, When X starts, the desktop is immediately darkened with what appears to be a high contrast setting. Looks like equivalent to manual setting I can't actually discern. It's not brightness, necessarily, but the net effect on the desktop is that everything is effectively darker. * I've tested this with Ubuntu's Unity desktop, and gnome-flashback (compiz and metacity), and it behaves the same. When amdgpu.dc=0 is set, desktop appears a normal level of brightness when logging in. It appears from the Xorg.0.log that the AMDGPU module isn't used for X, but brightness isn't affected. I'll include logs from amdgpu.dc=0 and amdgpu.dc=1. Let me know if you need any other logs.
Created attachment 138804 [details] dmesg output with amdgpu.dc=0
Created attachment 138805 [details] Xorg.0.log with amdgpu.dc=0
Created attachment 138806 [details] xrandr --verbose with amdgpu.dc=0
A fix I've found for the issue seems to be issueing an xrandr brightness command to each monitor output. EG: ~$ xrandr --output DP-5 --brightness .99 If brightness is set to 1, the monitor appears to lose some sort of rendering characteristic, not necessarily brightness - It's like color rendering or gamma correction change somehow. Simply changing the brightness a modicum seems to fix the issue.
Created attachment 138807 [details] xrandr --verbose with amdgpu.dc=1
Created attachment 138808 [details] Xorg.0.log with amdgpu.dc=1
Created attachment 138809 [details] dmesg output with amdgpu.dc=1
$ uname -a Linux nope 4.16.0+ #1 SMP Mon Apr 2 15:52:14 CEST 2018 x86_64 x86_64 x86_64 GNU/Linux ~$ lsb_release -a LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial
For DC developers: behind the scenes, brightness 1 means no-op/pass-through gamma LUT, lower brightness levels are simulated by modifying the gamma LUT accordingly.
Created attachment 138814 [details] [review] [PATCH] drm/amd/display: Don't program bypass on linear regamma LUT Does this fix things for you?
Okay, sadly, I wasn't clear about the kernel I was running. It's located here: https://github.com/M-Bab/linux-kernel-amdgpu and I installed the .deb created by the git contributor here: https://github.com/M-Bab/linux-kernel-amdgpu-binaries I downloaded the source listed in the first link I posted above, and it doesn't appear to have the same file structure you'd listed in your patch. I've attached amdgpu_dm_color.c to this bug. If you don't want to patch for this, I understand. I can see if I can speak to the person responsible for this repo.
Created attachment 139022 [details] I don't think this is the same file from 2.17. Sorry.
Not sure exactly how that kernel is assembled but it contains the problematic code in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c. You should be able to simply delete the block for if (__is_lut_linear(...)) in amdgpu_dm_set_regamma_lut to fix this, if the patch doesn't straight-up apply.
Sorry, I completely forgot that I was using a custom kernel. I downloaded it from here: https://github.com/M-Bab/linux-kernel-amdgpu-binaries and installed the .deb files directly. Here's the source: https://github.com/M-Bab/linux-kernel-amdgpu
This bug has been fixed in this branch: h https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.17 brightness appears as normal after building the kernel from git. Good job, and thanks.
Whoops. Changing to resolved/fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.