Bug 71769

Created attachment 89443 [details]
dmesg output from switching range with xrandr

Created attachment 89444 [details]
EDID data from /sys/class/drm/card0-HDMI-A-1/edid

We need someone with an analyzer sniffing out the infoframes your pioner box sends around ;-)

tbh I don't really know what to do here, assigning to Ville for luck.

Has the AVI infoframe sending been verified to work?

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?

(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.

We have a helper to do this in i-g-t called intel_infoframes. It should dtrt, so you can use it to send different infoframes around. At least Paulo used it do debug our infoframe update code.

intel_infoframes didn't detect any HDMIs and looking at the source I think it needs to be updated for Haswell.

I used the following to successfully change the infoframe to claim YCbCr 4:4:4

sudo intel_reg_write 0x60200 0x0001     ; \
sudo intel_reg_write 0x60220 0x000d0282 ; \
sudo intel_reg_write 0x60224 0x0808400f ; \
sudo intel_reg_write 0x60228 0x00000010 ; \
sudo intel_reg_write 0x6022C 0x00000000 ; \
sudo intel_reg_write 0x60200 0x1001

This changed the colors on screen, so the infoframes are clearly sent and understood by the monitor.

I wish I had an HDMI analyzer to see what the Oppo sends.

I am able to switch my monitor to limited range, if I use xrandr to set full range output first:

$ DISPLAY=:0 xrandr --output HDMI1 --set "Broadcast RGB" "Full"
$ sudo intel_reg_write 0x60200 0x1
$ sudo intel_reg_write 0x60220 0xd0282
$ sudo intel_reg_write 0x60224 0x4081043
$ sudo intel_reg_write 0x60228 0x10
$ sudo intel_reg_write 0x6022c 0x0
$ sudo intel_reg_write 0x60230 0x0
$ sudo intel_reg_write 0x60200 0x1001

But for some reason when I try this after setting limited range output with DISPLAY=:0 xrandr --output HDMI1 --set "Broadcast RGB" "Limited 16:235", nothing seems to happen. If I try my earlier YCbCr 4:4:4 infoframe, it still gets sent and colors change.

I constructed another infoframe to claim full range output:

DISPLAY=:0 xrandr --output HDMI1 --set "Broadcast RGB" "Limited 16:235"
sudo intel_reg_write 0x60200 0x1
sudo intel_reg_write 0x60220 0xd0282
sudo intel_reg_write 0x60224 0x808103f
sudo intel_reg_write 0x60228 0x10
sudo intel_reg_write 0x6022c 0x0
sudo intel_reg_write 0x60230 0x0
sudo intel_reg_write 0x60200 0x1001

And now my monitor switches to full range and the grey blacks turn even lighter.


If I'm reading this right, the infoframes are working properly, but colors are scaled too much with xrandr --output HDMI1 --set "Broadcast RGB" "Limited 16:235"

(In reply to comment #8)
> If I'm reading this right, the infoframes are working properly, but colors
> are scaled too much with xrandr --output HDMI1 --set "Broadcast RGB"
> "Limited 16:235"

Hmm. I tried to compare my IVB vs. HSW a bit, and it does look like HSW blacks are more grayish in limited range mode. But I double checked the code and we're computing the coefficients correctly as far as the spec is concerned. I need to
ask our display hardware guy whether the spec is wrong, or if I just misunderstood it.

I experimented a bit and simply halving the pipe CSC post coeffs seems to make the output look better.

Something like this (for pipe A, add 0x100 to register offsets for pipe B, 0x200 for pipe C)
intel_reg_write 0x49040 0x101
intel_reg_write 0x49048 0x101
intel_reg_write 0x49044 0x101
intel_reg_write 0x49028 0x0

Thanks, that seems a lot better.

I don't know if it's 100% accurate, I can see banding on a greyscale ramp. Do you think it's possible to map back to the original luma values after conversion to full range?

Other than that it looks good.

Ville confirmed with hw architects that our current hsw code is broken, assigning to him for the fix.

(In reply to comment #10)
> Thanks, that seems a lot better.
> 
> I don't know if it's 100% accurate, I can see banding on a greyscale ramp.
> Do you think it's possible to map back to the original luma values after
> conversion to full range?

The compression/expansion will leave some banding artifacts behind, that's somewhat inevitable. Afaik our hw doesn't have support to dither the colors a bit when compressing, so we can't fix this.

Created attachment 89751 [details] [review]
Fix for limited range output on HSW+

This should fix the problem.

Lauri, did you try the patch? And it so does it appear to work? It should, but there's always the possibility that I fumbled something. So a confirmation would be nice :)

I can confirm it's working. It's already been pulled into OpenELEC and other users are reporting success too.

commit 32cf0cb0294814cb1ee5d8727e9aac0e9aa80d2e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Nov 28 22:10:38 2013 +0200

    drm/i915: Fix pipe CSC post offset calculation

merged to -fixes with cc: stable, so should trickle down to released kernels.