Created attachment 104923 [details]
dmesg with drm.debug=0x0e of monitor with correct colors

These are only the drm messages.

Created attachment 104924 [details]
xrandr --verbose of monitor with wrong colors

Created attachment 104925 [details]
Xorg.0.log of monitor with wrong colors

Created attachment 104926 [details]
Xorg.0.log of monitor with correct colors

The screen is even flickering every few seconds as if the frequency is too low or something,.

Shot in the dark, try setting the Broadcast RGB property to Full on DP2.

I'd also be interested in dmesg with drm.debug=0xe running this patch on top of drm-intel-nightly.

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9c0ebf62c0cc..929fde9e5f6a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3744,6 +3744,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
                                    DP_MAX_DOWNSTREAM_PORTS) < 0)
                return false; /* downstream port status fetch failed */
 
+       DRM_DEBUG_KMS("DPCD downstream ports: %*ph\n",
+                     (int) sizeof(intel_dp->downstream_ports),
+                     intel_dp->downstream_ports);
+
        return true;
 }

Many thanks, running `xrandr --output DP2 --set "Broadcast RGB" Full` seems to fix the issue for the session.
Finally colors look proper again on Linux.

Do you still need the debug messages with the patch applied? If so I will try to set this up tomorrow.

We do this with Broadcast RGB Automatic because DPv1.2 says, "When a Source device is transmitting a RGB stream with a video timing format called out in CEA-861C Section 5 as using CEA range RGB, it must use the CEA range RGB."

However it also says, "However, a Source device may transmit all code values from zero to the maximum even when it declares the CEA range in the Main Stream Attributes. It is the responsibility of the Sink device to limit the pixel value
range as needed."

I wonder if we could do that. Ville?

I'm inclined to close this as something along the lines of INVALID or WONTFIX.

I didn't had the issue with the same monitor and my old laptop, which had a i5-M520 (first generation core i).

So it is not just the monitor. I have also seen a similar report with an Intel graphic card: https://lists.fedoraproject.org/pipermail/users/2013-June/436691.html

Just for the records I had the same issue with the analog output.

One for Ville to clarify.

(In reply to comment #9)
> We do this with Broadcast RGB Automatic because DPv1.2 says, "When a Source
> device is transmitting a RGB stream with a video timing format called out in
> CEA-861C Section 5 as using CEA range RGB, it must use the CEA range RGB."
> 
> However it also says, "However, a Source device may transmit all code values
> from zero to the maximum even when it declares the CEA range in the Main
> Stream Attributes. It is the responsibility of the Sink device to limit the
> pixel value
> range as needed."
> 
> I wonder if we could do that. Ville?

My interpretation of the latter clause is that the source is allowed to include "invalid" pixel values in the data and the sink must be ready to receive them and clamp them to the limited range. So if we would send full range data and tell the sink it's limited range the sink will just clamp it and you get the "crushed blacks" syndrome.

I really wonder how so many display get away with ignoring the spec. I can only assume that the compliance tests don't check for this issue, and thus you can get the DP sticker on your product even if it doesn't do as the spec says.

Did something change recently with Kernel 3.17.1 in relation to this issue?
I had installed 3.16 before and after every restart I had to run `xrandr --output DP2 --set "Broadcast RGB" Full` to get regular colors.

Now after the new Kernel was installed and I rebooted the command had no effect and the colors looked normal from the beginning.

Marking it as resolved for now unless it randomly pop ups again. Thanks.