Created attachment 140509 [details]
Toshiba TV screen with broken colors and wrong ratio
[SKL] Broken colours on usb-c/thunderbolt 3 to HDMI output (alt DP mode)
• Related to: #99137
• Description: Colours on external TV screen connected through USB-C/Thunderbolt 3 to HDMI adapter are broken — "16 bits depth" kind (see attachment) — and aspect ratio is 4/3.
- Hardware: DELL XPS 9350 with Intel Graphics 520 with BIOS V1.7.0, service tag CK00562 .
- USB-C/Thunderbolt Controller: Reference is hard to find, but the technical prospect mentions support for Display Port 1.2 only.
So my guess is it's intel late 2015 L6540 controller (Alpine Ridge) .
Tested firmware are original and latest from 05 Apr 2018 .
- USB-C/Thunderbolt to HDMI Adapter: Aukey CB-C37.
- External screen: TOSHIBA TV 43L420U.
- HDMI cable: I have tried many.
- Distro: Manjaro 17.1.11.
- Kernels tested: 4.18rc2, 4.17.4-1, 4.16.18-1, 4.14.53-1, 4.10.0-28, 4.9.111-1, 4.4.139-1
• Extra diagnostic: Colors are not broken on PC Monitors (22 to 28 inches) nor on Windows 10 with the same TOSHIBA TV.
HDMI audio is non-selectable in KDE settings, but I could make it work with `pacmd set-card-profile'. However, it did not improve color-rendering.
I tried to switch on/off the TV screen as OP in #99137 offered and change resolutions, with no success.
- picture of the broken colors screen (with current post)
- dmesg log with drm.debug=0xf (bellow this post)
- xrandr verbose query (bellow this post)
Created attachment 140510 [details]
dmesg log with drm.debug=0xf module enabled
Screen was attached from the beginning of boot process.
Created attachment 140511 [details]
xrandr verbose query
TOSHIBA TV screen is `DP1'.
So, to play my 5 cents here perhaps it might be related to the fact this controller supports DisplayPort 1.2 only (Thunderbolt alternate mode from June 2015) which is not that much popular. See .
Thank you for the report. Several remarks.
1. If you publish the Dell service tag, all people can look up the system configuration and warranty and so on. No idea, if only that data is needed to get the Dell support to do something.
2. Do you know if it’s X.Org server/Wayland related?
3. Could you please try to build drm-tip? 
4. You might also want to join #intel-gfx on irc.freenode.net. Maybe folks in there might help you too.
The following “warnings” are shown for the module in your log.
[ 1.866459] i915: unknown parameter 'enable_rc6' ignored
[ 1.866462] Setting dangerous option enable_fbc - tainting kernel
[ 1.866464] i915: unknown parameter 'semaphores' ignored
I'm totally new on the forum but I experienced same issue as on attached screens.
In my case the problem disappear after some random time (15 sec, 15 min or 30 min).
Here is a link do short video, it disappears after about 15 seconds and everything looks perfect.
Laptop: Dell XPS 9370
TV with wrong colors: Samsung 48" Smart Hub (UE48H6400)
Adapter: Hama USB-C Adapter for HDMI
Created attachment 141324 [details]
The colors fix themselves
(In reply to firstname.lastname@example.org from comment #6)
> I'm totally new on the forum but I experienced same issue as on attached
Thank you for your comment, and welcome. Please note, that this is about the Linux kernel driver. Looking at your video, it looks like you use Microsoft Windows?
(In reply to Paul Menzel from comment #8)
> (In reply to email@example.com from comment #6)
> > I'm totally new on the forum but I experienced same issue as on attached
> > screens.
> Thank you for your comment, and welcome. Please note, that this is about the
> Linux kernel driver. Looking at your video, it looks like you use Microsoft
it is Manjaro
OS: Manjaro 17.1.12 Hakoila
Kernel: x86_64 Linux 4.18.6-1-MANJARO
I have exactly the same setup, with KDE desktop environment as you do.
Might not be a coincidence ...
Sorry Paul Menzel, I didn't have enough time to compile a kernel.
(In reply to Jules Samuel Randolph from comment #10)
> Sorry Paul Menzel, I didn't have enough time to compile a kernel.
We didn't have enough time to look at the bug. :p
Seriously, we could use feedback running drm-tip.
Dropping the "ReadyForDev" tag as we don't have dmesg log from drm-tip yet
Jules, can you reproduce this issue with latst drm-tip and send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M??
Jules, any updates with drmtip?
I'm running out of time friends!
I'll try at some point in December.
(In reply to Jules Samuel Randolph from comment #15)
> I'm running out of time friends!
> I'll try at some point in December.
Jules, do you still have the issue with latest drmtip? If not this bug can be closed.