Created attachment 128528 [details] Photo of TV with weird discolouration I'm getting weird colours on external output, see attachment Laptop is Dell XPS 13 Developer Edition I tried 2 different usb-c to hdmi adaptors on 2 different TVs
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
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.