Bug 105331 - Dithering doesn't work on HD4600 when using DP
Summary: Dithering doesn't work on HD4600 when using DP
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: x86-64 Linux
: P3 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
Depends on:
Reported: 2015-10-02 00:07 UTC by Dihan Wickremasuriya
Modified: 2016-03-22 16:03 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.2.0
Regression: No
Bisected commit-id:

dmesg output (4.2.0) (104.48 KB, text/plain)
2015-10-02 00:07 UTC, Dihan Wickremasuriya
xrandr output (4.2.0) (3.00 KB, text/plain)
2015-10-02 00:08 UTC, Dihan Wickremasuriya
intel_reg_dumper output (12.92 KB, text/plain)
2015-10-02 00:09 UTC, Dihan Wickremasuriya
VBIOS dump (64.00 KB, application/octet-stream)
2015-10-02 00:09 UTC, Dihan Wickremasuriya

Description Dihan Wickremasuriya 2015-10-02 00:07:46 UTC
Created attachment 189231 [details]
dmesg output (4.2.0)

Color dithering doesn't work when using the display port on a system with a Haswell Core i7-4770S CPU. The display is a 6-bit panel with a resolution of 1024x600.

System architecture: x86_64
Kernel version: 4.2.0-gentoo+
Linux distribution: Gentoo
Machine or mother board model: Dell XE2 with a Core i7-4770S CPU
Display connector: DP

dmesg, xrandr and intel_reg_dumper output and the VBIOS dump are attached.

The same issue was seen with kernel version 4.3.0-rc3 from the drm-intel-nightly branch in the http://cgit.freedesktop.org/drm-intel repository.
Comment 1 Dihan Wickremasuriya 2015-10-02 00:08:51 UTC
Created attachment 189241 [details]
xrandr output (4.2.0)
Comment 2 Dihan Wickremasuriya 2015-10-02 00:09:12 UTC
Created attachment 189251 [details]
intel_reg_dumper output
Comment 3 Dihan Wickremasuriya 2015-10-02 00:09:29 UTC
Created attachment 189261 [details]
VBIOS dump
Comment 4 Jani Nikula 2015-10-20 09:20:12 UTC
Ville, why do we default to 24 bpp instead of 18 bpp when the EDID has no bpc information?
Comment 5 Ville Syrjala 2015-10-20 11:16:55 UTC
No idea.

The DP spec says:
"In determining the colorimetry format, the Source device must check the capability of the Sink device via an EDID read. When the Sink device capability is unknown, for example due to the corruption of EDID, the Source device must fall back to 18bpp RGB, with full dynamic range"
"Note: The Source device falls back to 18bpp,VESA range RGB when the sink capability is unknown."
Comment 6 Jani Nikula 2015-10-20 12:14:35 UTC
I guess part of the problem is that the part that does the limiting now is agnostic to connector type. HDMI might have different rules?
Comment 7 Jani Nikula 2016-01-13 14:37:24 UTC
Dihan, sorry for the delay, please try
Comment 8 Dihan Wickremasuriya 2016-01-15 01:17:46 UTC
Thanks for the fix Jani, it works great! I tested on top of 4.4.0 which exhibits the same symptom without your patch.
Comment 9 Jani Nikula 2016-01-15 09:49:05 UTC
(In reply to Dihan Wickremasuriya from comment #8)
> Thanks for the fix Jani, it works great! I tested on top of 4.4.0 which
> exhibits the same symptom without your patch.

Thanks for testing, the fix has been pushed to drm-intel-next-queued with cc: stable so it will eventually get backported to stable kernels.

commit 013dd9e038723bbd2aa67be51847384b75be8253
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Jan 13 16:35:20 2016 +0200

    drm/i915/dp: fall back to 18 bpp when sink capability is unknown
Comment 10 Mario Kleiner 2016-03-21 22:44:10 UTC
I haven't tested this yet, but doesn't this change degrade any DVI or analog VGA display to 6 bpc/18 bpp if it is connected to DisplayPort via a DP->DVI or DP->VGA adapter?

That would be pretty disastrous to many medical/scientific vision testing applications that need at least 8 bpc without dithering, and often have to rely on specialized DVI/VGA display hardware, given that many machines nowadays only have DP outputs, but no real DVI or VGA connectors anymore.

A similar problem was fixed in e8fa4270536de2e5e8205fb2b90bb26afc471729 "drm/i915: Only dither on 6bpc panels" just a couple of months ago and i'm worried this reintroduces the problem for DP?
Comment 11 Jani Nikula 2016-03-22 08:49:48 UTC
(In reply to Mario Kleiner from comment #10)
> I haven't tested this yet, but doesn't this change degrade any DVI or analog
> VGA display to 6 bpc/18 bpp if it is connected to DisplayPort via a DP->DVI
> or DP->VGA adapter?

That depends on whether the displays have EDID 1.4 and advertise a sink capability higher than 18 bpp or not.

I presume the spec was written this way to avoid black screens, and to a large part that's the main priority we have too.
Comment 12 Mario Kleiner 2016-03-22 16:03:19 UTC
Black screens are not good, but degrading lots of well working displays out there isn't either. And 6 bpc for VGA and DVI sinks can not be right.

I think our general EDID handling needs a little bit of improvement for EDID < 1.4, or your patch would need to be more selective wrt. what kind of sink is connected to DP, or we need some manual override, otherwise this will be pretty bad for lots of scientific users. It will practically brick their systems for the purpose for which they bought them if they depend on DP->DVI/VGA output, which many do. The patch has reached stable distro via kernel updates.

CRT monitors or other analog VGA driven displays have essentially infinite resolution due to the analog input signal - only limited by the DAC resolution at the source. Currently our drm_add_display_info() routine in drm_edid.c assumes "unknown bpc" for any analog source, with the code comment "driver figures it out in this case". I'd assume driving the VGA sink with the highest bpc the hw can deliver should be safe, so assigning a large bpc, e.g., >= 16 bits would deal with analog sinks.

I also googled around a bit and found pdf's with descriptions of different EDID versions, the DVI spec and its predecessor, the DFP 1.x spec. As far as my understanding of EDID 1.3 from that goes, for a digital sink, if bit 0 of byte 0x14 is set to 1 (or for us: if (edid->input &  DRM_EDID_DIGITAL_TYPE_DVI) ) then the sink is a "DFP 1.x compatible TMDS" and that seems to mean that the display can take 8 bpc / 24 bpp input signals. From https://www.tu-chemnitz.de/informatik/RA/news/stack/kompendium/vortraege_99/peripherie/standards/dfp/DFP.pdf section 3.10 "EDID support":

"If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.) without extensions, the host will make the following assumptions:

1. 24-bit MSB-aligned RGB TFT
2. DE polarity is active high
3. H and V syncs are active high
4. Established CRT timings will be used
5. Dithering will not be enabled on the host

The DVI spec has similar wording wrt. DVI signals being compatible with DFP sinks and 24 bits per pixel input signal support as mandatory.

My proposal would be a patch, also for stable, to assign info->bpc = 16 for analog sinks instead of 0 and info->bpc = 8 if ((info->bpc == 0) && (edid->input &  DRM_EDID_DIGITAL_TYPE_DVI)) at the end of EDID 1.3 parsing.

Note You need to log in before you can comment on or make changes to this bug.