Bug 105177

Created attachment 137478 [details]
dmesg kernel 4.15.4; connected via hdmi; amdgpu.dc=0

Created attachment 137479 [details]
dmesg kernel 4.15.4; connected via hdmi; amdgpu.dc=1

Created attachment 137480 [details]
dmesg kernel 4.15.4; connected via dvi; amdgpu.dc=1

Can you attach a picture?

Also please attach your xorg log.

Created attachment 137510 [details]
framebuffer console via hdmi

frame buffer console should be black but is violet (hdmi)

Created attachment 137511 [details]
desktop (hdmi) - console should be black but is violet

Created attachment 137512 [details]
desktop (dvi) - console is black, like expected

Created attachment 137513 [details]
x.org.log (hdmi)

Created attachment 137514 [details]
x.org.log (dvi)

btw, all tests were done with amdgpu.dc=1, because suse configured the kernel that way.

There's a mismatch in colorspace we program and tell the HDMI receiver because we program the infoframe too early in our sequence. I'll send a patch tomorrow.

Created attachment 137536 [details] [review]
[PATCH] update infoframe after dig fe is turned on

This patch should fix your issue. Please let me know if you try it.

I've build a 4.15.5 kernel incl. your patch and booted with display connected to hdmi.
First boot hang.
In journalctl I found
Feb 24 11:29:28 linux kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:42:crtc-0] flip_done timed out
(I'll attach journalctl-boot-4-15-5-with-patch-hdmi-hang.txt)

Second try booted into gui (kde login). The colors where still wrong. But now it was possible to turn of the screen and on again. The screen resolution stayed the same but the colors still were wrong.
(I'll attach dmesg-4-15-5-with-patch-hdmi.txt and Xorg.0.log-4.15.5-with-patch-hdmi.txt)

I'll stay with the dvi connected monitor.

Created attachment 137575 [details]
journalctl-boot-4-15-5-with-patch-hdmi-hang.txt

Created attachment 137576 [details]
dmesg-4-15-5-with-patch-hdmi.txt

Created attachment 137577 [details]
Xorg.0.log-4.15.5-with-patch-hdmi.txt

Can you try the drm-next-4.17-wip branch from https://cgit.freedesktop.org/~agd5f/linux and see if that fixes the issue?

I will wait for suse providing a 4.17 kernel

I've tried drm-next-4.17-wip.
What I've seen is the same as described with the initial bug description:
When monitor is connected via hdmi I get wrong colors. This appears during boot before the gui (x.org) gets started (frame buffer boot animation). Wrong colors (sort of violet instead of black) also appear on frame buffer text console and with x.org gui.
This bug appears with "amdgpu.dc=1" kernel parameter.
While running x.org I've turned the monitor off and on again. This gives correct colors but the screen resolution goes to 1024x768. So it's no work around.

What I've seen is: The colors are correct if I run the monitor with a yuv color model instead of rgb.

One thing seems to be better: Every boot manged to get to the graphical login. I've tried about 10 reboots.

Btw.: There is a new bug showing up with a 4.16.0-rc7 kernel (I did not test rc1 to rc6): The screen flickers. I can't tell you whats triggers such a flicker but it does.
That bug is still around with the drm-next-4.17-wip kernel.

Please keep one issue per ticket. Open a new ticket if needed.

That said, a fix for the flickering issue should be in drm-next-4.17 of Alex's git repo at https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17 and should make it into Linus's tree from there.

That fix should also make it into 4.16 stable.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/306.