https://bugs.freedesktop.org/show_bug.cgi?id=70934
Priority: medium Bug ID: 70934 Assignee: dri-devel@lists.freedesktop.org Summary: [Regression] Problem with colors (depth?) on DCE5 Barts (HD69xx) Severity: normal Classification: Unclassified OS: All Reporter: zajec5@gmail.com Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI
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).
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #1 from Rafał Miłecki zajec5@gmail.com --- Created attachment 88200 --> https://bugs.freedesktop.org/attachment.cgi?id=88200&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #2 from Rafał Miłecki zajec5@gmail.com --- Created attachment 88201 --> https://bugs.freedesktop.org/attachment.cgi?id=88201&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #3 from Rafał Miłecki zajec5@gmail.com --- Created attachment 88202 --> https://bugs.freedesktop.org/attachment.cgi?id=88202&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #4 from Rafał Miłecki zajec5@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #5 from Rafał Miłecki zajec5@gmail.com --- Btw. it's pretty old, isn't it? I'm surprised noone else was affected by it, huh.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #6 from Rafał Miłecki zajec5@gmail.com --- Created attachment 88207 --> https://bugs.freedesktop.org/attachment.cgi?id=88207&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Rafał Miłecki zajec5@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #88207|application/octet-stream |text/plain mime type| | Attachment #88207|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #7 from Rafał Miłecki zajec5@gmail.com --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #8 from Rafał Miłecki zajec5@gmail.com --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Rafał Miłecki zajec5@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #88201|Colors problem on TV |[Different issue] Colors description| |problem on TV Attachment #88201|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Rafał Miłecki zajec5@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #88202|Colors OK on TV |[Different issue] Colors OK description| |on TV Attachment #88202|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #9 from Alex Deucher agd5f@yahoo.com --- (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=... http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.13-wip&id=...
You might try enabling dithering via xrandr.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #10 from Rafał Miłecki zajec5@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #11 from Alex Deucher agd5f@yahoo.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #12 from Rafał Miłecki zajec5@gmail.com --- Created attachment 88238 --> https://bugs.freedesktop.org/attachment.cgi?id=88238&action=edit 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?
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #13 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #12)
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?
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?
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #14 from Rafał Miłecki zajec5@gmail.com --- [ 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
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #15 from Rafał Miłecki zajec5@gmail.com --- In xrandr my panel is visible as eDP, so I guess it's a eDP-1 with INTERNAL_UNIPHY1 .
https://bugs.freedesktop.org/show_bug.cgi?id=70934
--- Comment #16 from Alex Deucher agd5f@yahoo.com --- Does forcing the bpc to 8 fix the issue? If so, can you narrow down which particular table(s) are causing the problem?
https://bugs.freedesktop.org/show_bug.cgi?id=70934
Rafał Miłecki zajec5@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #17 from Rafał Miłecki zajec5@gmail.com --- 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=49...
Was also queued for stable releases.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org