[Bug 46800] [SNB] Full/Limited Color range not functional

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46800

--- Comment #7 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to comment #6)
> The patch seems to have fixed the issue of the xrandr command not working
> (kernel 3.8.0 RC3) – had to manually edit i915_reg.h. Can now switch between
> full and limited modes and all seems fine, also retains the setting between
> refresh rate changes. Is there any way this can be automated? For example is
> there information in the EDID that could be used? That would obviously be
> the preferred solution. This however is a very welcome step forward.

I don't think EDID gives us anything quite like that.

Based on a quick glance a the CEA and HDMI specs, there are a few things
however that we could use to make it automatic in some cases.

The CEA EDID extension block has a bit that tells whether the display supports
selecting the RGB range. But if that bit is not set, then there's no direct way
to tell which range the display uses by default.

The CEA spec does state that the source should use limited range for all CEA
video modes, except 640x480. I'm not quite sure what should happen with non-CEA
modes, perhaps full range should be used.

Also the AVI infoframe has the capability to tell the display which range the
source is sending. I need to check if were providing that information correctly
or not.

And I suppose if the display is actually a DVI display instead of HDMI, we
should probably default to full range.

The question is how do we want to implement the automatic mode. Should we leave
it up to userspace to do it, or do we provide another setting for the
'Broadcast RGB' property, say "Automatic", which would let the kernel make
these decisions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20130111/5d6efdb2/attachment.html>