I've switched from openSUSE's 3.4.47 to drm-next-3.13-wip and noticed problems with colors. Gradients are not smooth, it looks like the GPU is working in some limited color depth (lower than 24b).
Created attachment 88200 [details] Photo of the problem Unfortunately my poor camera and poor environment didn't produce a nice quality photo. It looks like there is some generic corruption, that isn't really visible on my panel. However if you look closely on the top part of the green gradient, you'll see that the color change isn't smooth. It looks like LCD is working in less than 24b colors mode.
Created attachment 88201 [details] [Different issue] Colors problem on TV Another colors problem is visible on TV connected over HDMI. That white horizontal stripes are caused by my poor camera, but the pink/purple colors are here visible for real. Also colors corruption visible on top 25% of the TV screen is also absolutely real.
Created attachment 88202 [details] [Different issue] Colors OK on TV In case of TV connected with HDMI a simple xrandr --output HDMI-0 --off xrandr --output HDMI-0 --auto fixed the problem. There weren't any problems with colors after that. Even gradients were OK (looks like TV is working in 24b mode). That white horizontal stripes are result on my poor camera only. Screen on this photo was perfect.
I was bisecting over commits touching drivers/gpu/ only, but the one I found seems pretty likely: eccea7920cfb009c2fa40e9ecdce8c36f61cab66 is the first bad commit commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66 Author: Alex Deucher <alexander.deucher@amd.com> Date: Mon Mar 26 15:12:54 2012 -0400 drm/radeon/kms: improve bpc handling (v2) Improve handling of bpc (bits per color) in radeon. In most cases we want 8 except for HDMI, DP, LVDS, and eDP. v2: handle DP better. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Dave Airlie <airlied@redhat.com> I'll verify that further tomorrow.
Btw. it's pretty old, isn't it? I'm surprised noone else was affected by it, huh.
Created attachment 88207 [details] [review] A small debugging patch I've applied It resulted in: [ 46.687422] fbcon: radeondrmfb (fb0) is primary device [ 46.687950] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 46.687953] [convert_bpc_to_bpp:408] Called with bpc 6 [ 46.687955] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 46.687957] [convert_bpc_to_bpp:408] Called with bpc 6 [ 46.687958] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 46.687959] [convert_bpc_to_bpp:408] Called with bpc 6 [ 46.688296] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 46.688298] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 46.688299] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.204703] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.204705] [atombios_crtc_set_pll:968] Changing bpc from 8 to 6 [ 48.204707] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.204709] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.204710] [atombios_adjust_pll:591] Changing bpc from 8 to 6 [ 48.204712] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.205120] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.205121] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.205123] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.205138] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.205139] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.205141] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.426542] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.426545] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.426547] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.426908] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.426910] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.426911] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.429552] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.429554] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.429556] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.432481] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.432483] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.432484] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.432488] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.432489] [atombios_dig_encoder_setup:544] Changing bpc from 8 to 6 [ 48.432491] [radeon_get_monitor_bpc:124] connector->display_info.bpc:6 [ 48.488094] Console: switching to colour frame buffer device 240x67 I think the problem is simply that connector->display_info.bpc is set to 6 instead of 8. I didn't track place where it's set yet.
Is that EDID that is corrupted for my screen? :| I added this one debugging line to drm_edid.c: [drm_add_display_info:1807] edid->input:0x95; DRM_EDID_DIGITAL_DEPTH_MASK:0x70; input & DRM_EDID_DIGITAL_DEPTH_MASK:0x10; DRM_EDID_DIGITAL_DEPTH_6:0x10; DRM_EDID_DIGITAL_DEPTH_8:0x20
There is my EDID: 00ffffffffffff004ca333d000000000 0c150104952616780aa0558d515a962a 1c505400000001010101010101010101 0101010101016a4d80a07038fc413020 36007ed710000018d49a80a07038fc41 302036007ed710000038000000fc0053 414d53554e470a2020202020000000fc 00313733485430322d4330310a200035 0x12: 0x01 EDID version 0x13: 0x04 EDID revision 0x14: 0x95 Input 0x15: 0x26 Width [cm] 0x16: 0x16 Height [cm] 0x17: 0x78 Gamma 0x18: 0x0a Features Let's take a look at that 0x95. 0x80 bit indicates that this is a digital signal interface In this situation 0x70 bits store info about color depth. 0x10 indeed means 6 bits per color. Btw I've noticed that when 0x80 bit is set we also should look at bits 0x18 from 0x18 (Features) to see supported color format(s). My features bits are 0x0a which gives 0x0a & 0x18 = 0x8. That means my display supports RGB 4:4:4 as well as YCbCr 4:4:4. But does it change anything? Any other ideas? :| This notebook is Samsung NP700G7A-S01PL
(In reply to comment #0) > I've switched from openSUSE's 3.4.47 to drm-next-3.13-wip and noticed > problems with colors. Gradients are not smooth, it looks like the GPU is > working in some limited color depth (lower than 24b). I suspect you are seeing a problem with these patches: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.13-wip&id=f35533d0d943b0dc31e1e16c0704959c6411f890 http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.13-wip&id=a7986a436b7234368aa03e9e06ad737c9e9e42c5 You might try enabling dithering via xrandr.
To clarify: I did "git checkout eccea7920cfb009c2fa40e9ecdce8c36f61cab66", tested the kernel and got that colors problems. On top of that commit I simply did "git revert eccea7920cfb009c2fa40e9ecdce8c36f61cab66", re-tested, and colors were OK again. So it's definitely matter of eccea7920cfb009c2fa40e9ecdce8c36f61cab66.
(In reply to comment #10) > To clarify: > I did "git checkout eccea7920cfb009c2fa40e9ecdce8c36f61cab66", tested the > kernel and got that colors problems. > On top of that commit I simply did "git revert > eccea7920cfb009c2fa40e9ecdce8c36f61cab66", re-tested, and colors were OK > again. > > So it's definitely matter of eccea7920cfb009c2fa40e9ecdce8c36f61cab66. Sounds like your EDID may have a buggy bpc setting then. If dithering doesn't help, we could add an EDID quirk to fix the bpc.
Created attachment 88238 [details] [review] drm/radeon: enable FMT dither for non-DP-bridge eDP I needed this patch to be able to see "dither" property for eDP, but it doesn't change anything. I did: xrandr --output eDP --set dither on (and noticed changed in xrandr --prop), but it didn't improve colors for me. I've also tried: xrandr --output eDP --off; sleep 1s; xrandr --output eDP --auto but it also didn't help. Is dither supported for eDP at all?
(In reply to comment #12) > Created attachment 88238 [details] [review] [review] > drm/radeon: enable FMT dither for non-DP-bridge eDP > > I needed this patch to be able to see "dither" property for eDP, but it > doesn't change anything. I did: > xrandr --output eDP --set dither on > (and noticed changed in xrandr --prop), but it didn't improve colors for me. > > I've also tried: > xrandr --output eDP --off; sleep 1s; xrandr --output eDP --auto > but it also didn't help. > > Is dither supported for eDP at all? Dithering is enabled automatically based on OEM config for LVDS and eDP panels so we don't expose the dither attribute for them. What connectors and asics are you having problems with?
[ 16.732721] [drm] Radeon Display Connectors [ 16.732722] [drm] Connector 0: [ 16.732723] [drm] eDP-1 [ 16.732724] [drm] HPD2 [ 16.732725] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 16.732726] [drm] Encoders: [ 16.732727] [drm] LCD1: INTERNAL_UNIPHY1 [ 16.732727] [drm] Connector 1: [ 16.732728] [drm] DP-1 [ 16.732729] [drm] HPD3 [ 16.732730] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 16.732731] [drm] Encoders: [ 16.732731] [drm] DFP1: INTERNAL_UNIPHY2 [ 16.732732] [drm] Connector 2: [ 16.732733] [drm] HDMI-A-1 [ 16.732734] [drm] HPD1 [ 16.732735] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 16.732735] [drm] Encoders: [ 16.732736] [drm] DFP2: INTERNAL_UNIPHY2 [ 16.732737] [drm] Connector 3: [ 16.732738] [drm] VGA-1 [ 16.732739] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4 [ 16.732739] [drm] Encoders: [ 16.732740] [drm] CRT1: INTERNAL_KLDSCP_DAC1
In xrandr my panel is visible as eDP, so I guess it's a eDP-1 with INTERNAL_UNIPHY1 .
Does forcing the bpc to 8 fix the issue? If so, can you narrow down which particular table(s) are causing the problem?
Fix is in Linus's tree and was included in 3.13-rc4 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=49d45a31b71d7d9da74485922bdb63faf3dc9684 Was also queued for stable releases.
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.