[Bug 71769] Monitor not recognizing RGB limited/full color range
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Nov 19 12:09:49 PST 2013
https://bugs.freedesktop.org/show_bug.cgi?id=71769
--- Comment #5 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to comment #4)
> Has the AVI infoframe sending been verified to work?
I seem to recall some patches that supposedly fixed some HDMI conformance
issues with infoframes. But that was before we switched over to the generic
infoframe helpers. I don't recall if there was any mention of which hardware
was used for the tests.
>
> I am thinking of changing the AVI infoframe to indicate YCbCr 4:4:4 instead
> of RGB to see if my monitor reacts to that (by messed up colors since the
> signal content would still be RGB) to confirm the infoframes are being
> transmitted. Would that be possible by changing the register contents using
> intel-gpu-tools, or should I just modify the kernel?
I think it should be doable w/ igt. You just need to follow the infoframe
programming sequence.
- disable AVI infoframe
- write the new infoframe data w/ updated checksum naturally, and remember the
magic ECC hole at byte 3.
- re-enable AVI infoframe
Our spec say we should wait for some vsyncs/hsyncs before disabling the
infoframe, but that makes no sense to me since the hardware might start
transmitting the infoframe again before we disable it. So I think the specs are
just a bit nuts, and we should in fact wait for at least one frame _after_
disabling the infoframe in question so that we don't corrupt any currently
transmitting infoframes.
Since this is HDMI, and getting incorrect colors is OK, I don't think there are
any other register that need frobbing actually.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20131119/c3d857a6/attachment.html>
More information about the intel-gfx-bugs
mailing list