[Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)

Jesse Barnes jbarnes at virtuousgeek.org
Wed Feb 29 19:36:41 CET 2012

On Wed, 29 Feb 2012 15:38:44 +0000
Paul Owen <paul at starstreak.net> wrote:

> On 28 February 2012 17:59, Jesse Barnes <jbarnes at virtuousgeek.org>
> wrote:
> >
> > There are several places we need to set extended vs normal range:
> > DSP*CNTR (bit 25)
> > PIPE*CONF (bits 26 and 13)
> > TRANS*CONF (bit 10, for xvYCC DP configs)
> > DVS*CNTR (for sprites, bit 21)
> Okay - good learning exercise for me this! So by default, latest 3.3
> kernel (github / master) upon boot xrandr reports Broadcast RGB as
> Full. For that intel_reg_read reports the following (hope I'm looking
> at the correct registers):
> intel_reg_read 0x70008 (PIPEACONF): 0xC0000000 / bits 26 and 13
> aren't set intel_reg_read 0x70180 (DSPACNTR) : 0xD8004400 / bit 25
> isn't set
> Okay - so just as an experiment, running xrandr -d :0 --output HDMI3
> --set "Broadcast RGB" "Limited 16-235" and rerunning the above gives
> exactly the same result, i.e. no bits set. So trying intel_reg_write
> with the following commands (hope my binary is correct!):
> intel_reg_write 0x70008 0xC4002000
> intel_reg_write 0x70180 0xDA004400
> Seems to have the desired effect - that is video seems to have the
> correct colour range - this is by eye since my TV doesn't seem to
> report the actual input range anywhere. Running just the first command
> seems to raise the brightness/decrease the contrast (or just raise
> gamma - not sure) - the second brings it back down - so both as you
> say are needed. Changing refresh seems to knock out the effect of the
> second command. Re-running that second command fixes it once more.
> I've posted on the XBMC forum in the hope others can try this to see
> what effect it has.
> > Yeah defaulting to the limited range for TVs may make sense.  Paulo
> > has been looking at TV detection and HDMI infoframes a bit, so may
> > be able to whip up a patch.
> That would be superb if possible since it removes all faffing about
> with xorg or whatever. Many thanks for this.

Great, glad it wasn't hiding anywhere more obscure.

Can you file a bug with the findings above just so we don't lose it?  I
expect the fix should be pretty easy, but I don't want to lose track of


More information about the Intel-gfx mailing list