Bug 99137

Found 2 "workarounds":

1. Use 800x600 resolution, I tried all other higher resolutions with no luck
2. Execute 

xrandr --output DP-2 --set "Broadcast RGB" "Full" AND
play a video - this fixes in all resolutions.

For starters, please add drm.debug=14 module parameter, and attach dmesg from boot to the problem.

Created attachment 128538 [details]
annotated dmesg with drm.debug=14 module parameter

Tried to annotate file, it contains dmesg after boot and login to unity, when colours are broken. Than switch to 800x600, which fixes colours. Than back to 1920x1080 which brakes colours.

Just installed Windows 10 and HDMI output looks perfect in 1920x1080, I think this rules out hardware problem

Tested it with kernel 4.8.4 and 4.9, bug still exists.

Hardware is a Dell XPS 13 developer edition laptop 

Sometimes it helps to switch resolution to 800x600 and revert it to 1920x1080.

Created attachment 128624 [details]
drm.debug during workaround


1. Boot with hdmi connected - broken colours
2. Switch to 800x600 - OK colours
3. Revert to 1920x1080 - broken
4. Switch to 800x600 - OK colours
5. Revert to 1920x1080 - OK colours

I'm using the latest Dell BIOS:
Version: 1.4.10
Last Updated: 22 Nov 2016

And latest thunderbolt firmware:
Release Date: 29 Jul 2016
Version: 2.16.01.003 ,A04
Last Updated: 10 Aug 2016

I'm not really sure how the DP->HDMI branch devices handle color depth. ATM we assume we can feed whatever bpc to DP sinks that are reported as supported in DPCD. But if the DP->HDMI conversion doesn't do anything to adjust the bpc, then we'll be feeding that all the way to the sink. Which means we should be checking the sink capabilities as well. Currently we only check for sink deep color support, but we fail to account for the sink max TMDS clock (or the DP++ dongle max TMDS clock if we have a DP->DP++->HDMI type of setup).

Also the sink should be told what the color depth is with the GCP infoframe. Whether or not that would be done automagically by the DP->HDMI device, or if we would have to send out that infoframe all the way from the source is totally left out from the DP spec. For this it would be extremely nice to see the infoframes the sink is actually receiving (doable with the chamelium?).

Updated to latest bios 1.4.14 -> still the same

I noticed the HDMI output looks good on the console (CTRL+ALT+F1)

Is there any experiment / workaround I could try?

I have found the same palletized colours (suggesting incorrect bit depth) on a Dell XPS 9360 (BIOS 1.2.3) with a Startech USB-C to HDMI cable (CDP2HDMM1MB) on 6 different devices (projector, monitor, 4 TVs).

Kernel is stock ElementaryOS 16.04 and with 4.9.0 kernel.

Created attachment 128717 [details]
dmesg from 4.9.0 with drm.debug=14; adapter connected at 73s

I can reproduce the colour issue on 4.10-rc2 also, but the xrandr "Broadcast RGB" or 800x600 workarounds above don't work for me. I can't reproduce the issue on Windows 10 though, so the hardware validates.

I find the adapter I use *does* give correct colours on my 1920x1080 projector, which reports 12-bit colour depth is in use from the menu. The other devices (including Dell U2713HM monitor) report only 8-bit colour depth in their EDID, so I bet the root-cause is either we are still sending 12 BPC data and should send 8 BPC, or we send 8 BPC but should be sending 12 BPC, and the adapter will truncate the data accordingly.

Would disabling the EDID check leading to "clamping display bpp (was 36) to EDID reported max of 24" be a useful test?

Broadcast RGB workaround doesn't seem to work anymore ... maybe it was just luck or something else

but switching back and forth couple of times to 800x600 still works most of the time

We need a better workaround or solution

Tried the same adaptor with Samsung BX2440X montior, BenQ BL2400 monitor and some Philips HD TV it all worked fine !
 
Setup was a bit different
 USB-C to HDMI adaptor ->  HDMI to DVI cable

So they both had DVI inputs 

But
 tried with another Samsung HDTV with HDMI to HDMI and got the weird colours

Looks like it works when input is DVI?

100% sure it's a HDMI input thing.

I tried 2 other screens:
- Dell Monitor with HDMI input -> says no signal
- LG Flat TC with HDMI input -> says invalid signal 

The only combination that works is:
USB-C to HDMI adaptor, using a HDMI to DVI cable 

Combination never worked:
USB-C to HDMI adaptor, using HDMI to HDMI cable - either wrong colours or no signal

I tested kernel 3.9.2 after removing this block that triggers from drivers/gpu/drm/i915/intel_display.c:

if (info->bpc != 0 && info->bpc * 3 < bpp) {
   DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported max of %d\n",
      bpp, info->bpc * 3);
   pipe_config->pipe_bpp = info->bpc * 3;
}

but it regressed the eDP1 panel output and didn't fix the DP1 output.

Any ideas?

Affects Kaby Lake platforms also (eg Dell XPS 9360) as well as Skylake (eg Dell XPS 9350).

Please try drm-tip branch of https://cgit.freedesktop.org/drm-tip with drm.debug=0xf module parameter, possibly with log_buf_len=4M or similar to fit all the dmesg in the buffer, and attach dmesg.

Created attachment 128998 [details]
Log from 4.10-rc3 drm-tip kernel with drm.debug=0xf

Many thanks for looking into this Jani!

Attached is the log from drm-tip (4.10-rc3) with drm.debug=0xf and log_buf_len=xM.

I plugged in the USB-C adapter at 83.53s, reproducing the colour/bitdepth issues. Just let me know for more information, debug or patch testing.

Experiencing the same on Dell Xps 13 Developer Edition Kaby Lake

The result can be seen at [1]

Reproduced it on the following kernels on ubuntu: 4.4, 4.8, 4,9 and on Fedora with 4.9. Two different monitors (one projector/beamer and a Samsung TV)

None of the described workarounds works. 

USB-c to VGA seems to work.

During my debug sessions I ran across several others who have had the same problem with Kaby Lake. I'd be happy to provide any logs that would help out

Hello everyone,
Could you please try to reproduce with latest mainline https://www.kernel.org/ and/or drm-tip https://cgit.freedesktop.org/drm-tip and attach dmesg log as suggested on comment #18, and confirm if the workarounds and reproducibility are the same.
Thank you.

Created attachment 134271 [details]
dmesg output on XPS13 9360 with kernel 4.13.2

Hello, I have the same exact issue.
For me the only workaround that is working is to turn external monitor off and then on while connected.

I tried to install latest mainline kernel 4.13.2 but nothing changed, same issues/workarounds are still present.

I'm attaching dmesg output. I could not try drm-tip because I was able to clone the git project but I'm not sure how to perform installation.

(In reply to Igor Saggese from comment #22)
> Created attachment 134271 [details]
> dmesg output on XPS13 9360 with kernel 4.13.2
> 
> Hello, I have the same exact issue.
> For me the only workaround that is working is to turn external monitor off
> and then on while connected.
> 
> I tried to install latest mainline kernel 4.13.2 but nothing changed, same
> issues/workarounds are still present.
> 
> I'm attaching dmesg output. I could not try drm-tip because I was able to
> clone the git project but I'm not sure how to perform installation.
Thanks for the information. 
You can search over the internet, youtube, google, etc., for a build guide.
Also, you can get a clue on https://01.org/linuxgraphics/documentation/build-guide-0 to compile the kernel.

Just an update from me:
I have not seen this problem for a while now. 

I've been using the same HDMI adaptor since I reported this problem. I think around 2017-03 the problem was fixed, at least on my system.

I tested it with various devices. From 40" Flat TV to 24" Dell Full HD monitors.

Right now running a 4k Samsung display without issues.

Works on Dell XPS 9350 with I6200U - Intel® HD Graphics 520
 and 9360 with i7-8560u - Intel® UHD Graphics 620

Using 4.10.0 kernel.

Thanks for the update S.illes79, then I'll close this as fixed. Thanks again.

Daniel, Ola and Igor, S.illes79 issue was SKL and was fixed on 4.10. Double checking your dmesg logs, yours are KBL. So I'm closing this case as fixed since original ticked was owned by S.illes79. Could you please file a new ticket with the requested information for KBL? Thank you.

sorry but i was not able to recheck with the exact same TV until this Xmas - only happens at my parents who they live in different country, this xmas I was home and rechecked it and still does not work 

Seems to be very specific with that TV.... I've been using HDMI all the time and haven't seen it going that mad for year

(In reply to s.illes79 from comment #26)
> sorry but i was not able to recheck with the exact same TV until this Xmas -
> only happens at my parents who they live in different country, this xmas I
> was home and rechecked it and still does not work 

What TV is that? What adapter did you use?

> Seems to be very specific with that TV.... I've been using HDMI all the time
> and haven't seen it going that mad for year

Just to clarify, in your original report it happened with two TV models, right?

Then I’d say, it’s a new issue. Please create a new issue with the required logs preferably from the latest Linux kernel (4.15.4). If you use Ubuntu Linux, you can easily install it from [2].


[1] https://01.org/linuxgraphics/documentation/how-report-bugs
[2] http://kernel.ubuntu.com/~kernel-ppa/mainline/

(In reply to Elizabeth from comment #25)

[…]

> Daniel, Ola and Igor, S.illes79 issue was SKL and was fixed on 4.10. Double
> checking your dmesg logs, yours are KBL. So I'm closing this case as fixed
> since original ticked was owned by S.illes79. Could you please file a new
> ticket with the requested information for KBL? Thank you.

Danial, Ola, Igor, did you open an issues yet. Here, with the Dell XPS 13 9360 (Kaby Lake) and the adapter Huawei MateDock USB-C Multiport Adapter, it always worked with at least Linux 4.10.

With the adapter Dell DA200, higher resolutions over HDMI work with *linux-image-4.13.0-32-generic*.


[1] https://bugs.launchpad.net/dell-sputnik/+bug/1726759
[2] https://packages.ubuntu.com/xenial/linux-image-4.13.0-32-generic

First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Closing, please re-open if still occurs.

Created attachment 140500 [details]
dmesg log with drm module

Created attachment 140501 [details]
xrandr query

Created attachment 140502 [details]
Toshiba TV screen with broken colors

I can reproduce a similar issue.

Setup:

- Hardware: DELL XPS 9350 with Intel Graphics 520
- USB-C-Thunderbolt to HDMI Adapter: Aukey CB-C37
- External screen: TOSHIBA TV 43L420U
- Distro: Manjaro 17.1.11
- Kernels tested: 4.18rc2, 4.17.4-1, 4.16.18-1, 4.14.53-1, 4.9.111-1, 4.4.139-1 

Problem Description:

Colors are broken and screen ratio remains 4/3 whatever resolution I configure from linux.

Attachments:

- A picture of the faulty screen
- A dmesg log with drm.debug=0xf module
- A xrandr query

Also, I pinned this askubuntu post reproducing this problem where some users report enabling HDMI audio resolves the issue [1].

I could not reproduce as I cannot select HDMI audio from GUI.

[1]: https://askubuntu.com/questions/839084/strange-colors-when-attaching-laptop-to-tv-via-hdmi-on-ubuntu-16-04

Thank you for your comment. As the original reported marked this as solved, could you please create a new issue, reference this here, and close this again? The motivation is, that it could indeed be specific problem with your setup (TV, cable, …). Also, please test with Linux 4.10, which the original reported said it was working for him/her.

OK I'll do that. I tried this morning with 4.10.0-28, without any success.

New bug reported at https://bugs.freedesktop.org/show_bug.cgi?id=107157.

Closing this as further work on a different specific configuration is occurring at https://bugs.freedesktop.org/show_bug.cgi?id=107157