Bug 83226 - Allow use of ColorRange and ColorSpace in xorg.conf.d files
Summary: Allow use of ColorRange and ColorSpace in xorg.conf.d files
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium enhancement
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 87591 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-08-29 07:27 UTC by John
Modified: 2016-06-05 14:04 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
patch 1/2 (2.67 KB, patch)
2015-02-23 16:17 UTC, Alex Deucher
Details | Splinter Review
patch 2/2 (7.12 KB, patch)
2015-02-23 16:17 UTC, Alex Deucher
Details | Splinter Review
set quantization_range in AVI infoframe if the monitor supports selectable range (2.17 KB, patch)
2015-02-23 22:19 UTC, Alex Deucher
Details | Splinter Review
patch 1/2 (1.52 KB, patch)
2015-08-19 15:56 UTC, Alex Deucher
Details | Splinter Review
patch 2/2 (945 bytes, patch)
2015-08-19 15:56 UTC, Alex Deucher
Details | Splinter Review
possible fix (1.74 KB, patch)
2015-08-27 13:55 UTC, Alex Deucher
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description John 2014-08-29 07:27:21 UTC
Hello,

This a feature request, I hope it is the right place.

As my main computer is connected to an HD-TV that only supports limited range of colors, I would like to be able to use limited range with radeon(si) but it is not yet available unlike for Intel or Nvidia.
For now I'm able to set media players to limited range, but I would like to be able to do it at the system level.

Being able to switch the color space would also be nice.

Thanks!
Comment 1 1337rz 2015-02-21 22:54:02 UTC
I have the same request- there's potential for lots of colour range issues when juggling different systems, drivers, and displays, and this setting is important to ensure correct colours.
Comment 2 John 2015-02-22 07:10:37 UTC
Is using the generic modesetting ddx a better plan for this?
Comment 3 Alex Deucher 2015-02-23 16:17:23 UTC
Created attachment 113757 [details] [review]
patch 1/2

These two patches implement support for this on DCE5+ hardware via the output_csc property.
Comment 4 Alex Deucher 2015-02-23 16:17:55 UTC
Created attachment 113758 [details] [review]
patch 2/2

Please apply both patches.
Comment 5 Andy Furniss 2015-02-23 20:53:24 UTC
I see these are in your tree now - a question: what does tvrgb do?

By which I mean does it just "tell" the TV via hdmi info that the signal is limited or does it do more eg. scale so it really is limited between 16 & 235?

It's a bit hard to tell by testing as it could just be the way my TV behaves - it looks scaled judging by how much I have to alter black level but IIRC the HDMI/CEA specs say that all but 0 and 255 are still legal in limited range to allow for sub/super that occurs "naturally" in video and sub in a pluge for proper black level setup.
Comment 6 Alex Deucher 2015-02-23 20:56:31 UTC
(In reply to Andy Furniss from comment #5)
> I see these are in your tree now - a question: what does tvrgb do?
> 
> By which I mean does it just "tell" the TV via hdmi info that the signal is
> limited or does it do more eg. scale so it really is limited between 16 &
> 235?

The latter.
Comment 7 Andy Furniss 2015-02-23 21:45:50 UTC
(In reply to Alex Deucher from comment #6)
> (In reply to Andy Furniss from comment #5)
> > I see these are in your tree now - a question: what does tvrgb do?
> > 
> > By which I mean does it just "tell" the TV via hdmi info that the signal is
> > limited or does it do more eg. scale so it really is limited between 16 &
> > 235?
> 
> The latter.

OK, thanks, so it doesn't signal just scales - which makes me wonder if TVs would behave differently if it did - but then I don't know if the normal case actually signals full range - and if it doesn't what TVs assume by default.
Comment 8 Alex Deucher 2015-02-23 22:19:39 UTC
Created attachment 113778 [details] [review]
set quantization_range in AVI infoframe if the monitor supports selectable range
Comment 9 Andy Furniss 2015-02-24 00:12:05 UTC
(In reply to Alex Deucher from comment #8)
> Created attachment 113778 [details] [review] [review]
> set quantization_range in AVI infoframe if the monitor supports selectable
> range

Thanks, testing = doesn't make any difference for me, but looking I am not sure if my TV supports/advertises it, edid-decode doesn't show it, I'll try more tomorrow.
Comment 10 John 2015-02-24 02:32:46 UTC
I've applied the patches but I am not sure how to enable anything.
Since it's a drm patch, am I suppose to enable that the same way I do for audio and dpm?
If so, I haven't tried, but I don't see anything in modinfo for csc.
Comment 12 Andy Furniss 2015-02-24 10:15:27 UTC
(In reply to John from comment #10)
> I've applied the patches but I am not sure how to enable anything.
> Since it's a drm patch, am I suppose to enable that the same way I do for
> audio and dpm?
> If so, I haven't tried, but I don't see anything in modinfo for csc.

xrandr --verbose will show you the options/output name and the current setting.

to change do something like -

xrandr --output HDMI-0 --set output_csc tvrgb
Comment 13 Andy Furniss 2015-02-24 11:40:29 UTC
(In reply to Andy Furniss from comment #9)
> (In reply to Alex Deucher from comment #8)
> > Created attachment 113778 [details] [review] [review] [review]
> > set quantization_range in AVI infoframe if the monitor supports selectable
> > range
> 
> Thanks, testing = doesn't make any difference for me, but looking I am not
> sure if my TV supports/advertises it, edid-decode doesn't show it, I'll try
> more tomorrow.

I added a couple of DRM_ERROR... lines to see if I passed if(drm_rgb_quant_range_selectable and I don't.

But even if I did I don't think that patch will work as I only get one message at the start - I would have expected that flipping between tvrgb and bypass (which works OK) would have generated more, but it doesn't.

Added complication - I am testing on your drm-next-4.1-wip (yesterdays so patch applied by hand), which has issues for me as reported elsewhere (as expected due to these I don't even get the debug line until I take a second strike at xrandr)
Comment 14 Andy Furniss 2015-02-24 12:23:45 UTC
(In reply to Peter Frühberger from comment #11)
> @AndyFurniss: Use some test patterns, like:
> https://dl.dropboxusercontent.com/u/55728161/fullrgb-video.mp4 or
> https://dl.dropboxusercontent.com/u/55728161/graustufen-rgb-0-bis-10_172435.
> png or https://dl.dropboxusercontent.com/u/55728161/fullrgb_test.jpg

Thanks, it's always nice to have more tests - I was already using ones I got via you(r forum) + the original W6RZ with player set to not stretch.

I have wondered in the past why anyone needs limited range from an HTPC POV. I am sure there must be a reason, but as it seems that intel (from memory - was really testing something else) and now AMD are scaling I can't think why, given the specs don't really seem to require a scale.

It seems with a 2010 Panasonic plasma I am not going to be able to test fully as it looks like it doesn't advertise the right things (If the function actually got called I would have forced it to see). I guess the tv thinks it's getting limited anyway (but still displays 0-255). Added complication being it has many modes and lots of settings within each, so maybe in eg. game it expects different from others.

I usually run it in thx and it looks good for real vid, but not so good for a ramp - game is better for a ramp - I can tell that tvrgb scales using that.

From previous testing I know that it subsamples every mode to 422 yuv.

I wonder if TVs that do accept the full/limited info frame tweak their faux EOTF gamma curves or something.

Whatever, for me it seems using passthrough will be best - if I use limited I would have to stretch the vid to 0-255 then it would get scaled back and I would have to set TV by eye - I guess I could avoid yuv - rgb stretch and setup round that but it still gets scaled.

Using passthrough I can stretch/not stretch as I wish and with the latter I don't get any scale - I can set black level in TV so 16 is "right" and get to see highlights in the vid rather than have them clipped/scaled.
Comment 15 Alex Deucher 2015-02-24 14:36:29 UTC
(In reply to Andy Furniss from comment #13)
> 
> I added a couple of DRM_ERROR... lines to see if I passed
> if(drm_rgb_quant_range_selectable and I don't.
> 
> But even if I did I don't think that patch will work as I only get one
> message at the start - I would have expected that flipping between tvrgb and
> bypass (which works OK) would have generated more, but it doesn't.

Changing the AVI infoframe requires a full modeset, changing the output_csc does not.  The AVI infoframe change only takes affect when you force a full modeset (e.g., switch modes with xrandr).  It's trivial to change the code to force a full modeset rather than just updating the output_csc state when you update the property, but I left them decoupled now for testing.
Comment 16 John 2015-02-24 22:38:40 UTC
(In reply to Andy Furniss from comment #12)
> xrandr --verbose will show you the options/output name and the current
> setting.
> 
> to change do something like -
> 
> xrandr --output HDMI-0 --set output_csc tvrgb

Oh xrandr, I hadn't used that in years.
That worked thanks!


As for the patch themselves, I'll have to do more testing but so far I think it works. Thanks Alex!
Comment 17 John 2015-02-25 10:00:37 UTC
I'm not sure if it is because of these patches, or 4.0-rc1 (I moved the 2 of them together), but now when my screen goes off (energy saving stuff), I lose the hdmi audio, but when I move the mouse the screen is back but not the audio.
Switching it back on with xrandr works though.
Comment 18 Alex Deucher 2015-02-25 15:04:35 UTC
(In reply to John from comment #17)
> I'm not sure if it is because of these patches, or 4.0-rc1 (I moved the 2 of
> them together), but now when my screen goes off (energy saving stuff), I
> lose the hdmi audio, but when I move the mouse the screen is back but not
> the audio.
> Switching it back on with xrandr works though.

Not likely related.  Please file a separate bug for that.
Comment 19 Alex Deucher 2015-02-26 15:03:13 UTC
*** Bug 87591 has been marked as a duplicate of this bug. ***
Comment 20 Pitscho 2015-02-26 15:25:50 UTC
I've read a lot about tvrgb here, what is about YCbCr. My Tv for example produces a better picture with this space compared to limited RGB.
Comment 21 Alex Deucher 2015-02-26 15:31:38 UTC
(In reply to Pitscho from comment #20)
> I've read a lot about tvrgb here, what is about YCbCr. My Tv for example
> produces a better picture with this space compared to limited RGB.

YUV output is not supported yet.
Comment 22 freddyescobar 2015-03-27 13:08:15 UTC
Hi,

I applied the two patches to mainline kernel 3.19.3, with the 3 patches for Ubuntu (i run linux mint 17.1).
But i can't see the property "output_csc" in xrandr.

What's wrong ?

Thanks, and sorry for my english.
Comment 23 freddyescobar 2015-03-27 13:29:04 UTC
I think it's because i have a HD5770 with DCE4 display core.
Comment 24 rteklits 2015-05-02 03:04:36 UTC
I compiled this into kernel 4.0.1 on arch linux.  I have an APU with an R7 graphics chip.  All went well and after rebooting I was able to switch output_csc to tvrgb.  I tested it with a few different pictures and the black levels seem to be true.  I only eyeballed it though.  It looks dramatically better on my tv.  I've been using catalyst proprietary drivers for their support of limited RGB, but the catalyst GL isn't always friendly to gaming through Steam.  This solves the problem, so many many thanks!
Comment 25 Pitscho 2015-08-19 07:07:04 UTC
Hi Alex Deucher,

I have just read that you alone added over 400k lines of code to kernel 4.1 regarding amd stuff. That reminded me of the limitedRGB stuff.

When will the limitedRGB patch be part of the radeon driver? As far as I understand, right now, only the patch exist, which I would have to compile myself.
Comment 26 Alex Deucher 2015-08-19 13:32:59 UTC
(In reply to Pitscho from comment #25)
> Hi Alex Deucher,
> 
> I have just read that you alone added over 400k lines of code to kernel 4.1
> regarding amd stuff. That reminded me of the limitedRGB stuff.
> 
> When will the limitedRGB patch be part of the radeon driver? As far as I
> understand, right now, only the patch exist, which I would have to compile
> myself.

The patches have been upstream for a while now:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67ba31d3528e2460b2243b2d139b70fa479602e8
Comment 27 Alex Deucher 2015-08-19 13:41:01 UTC
(In reply to Pitscho from comment #20)
> I've read a lot about tvrgb here, what is about YCbCr. My Tv for example
> produces a better picture with this space compared to limited RGB.

If you set your TV to use YUV and set output_csc to ycbcr601 or ycbcr709, it may work.  Depending on your display, you may also have to adjust the hdmi packets the driver sends.
Comment 28 Alex Deucher 2015-08-19 15:56:12 UTC
Created attachment 117787 [details] [review]
patch 1/2

Do these patches make YUV work for you?  Select output_csc ycbcr601 or ycbcr709
Comment 29 Alex Deucher 2015-08-19 15:56:36 UTC
Created attachment 117788 [details] [review]
patch 2/2
Comment 30 Pitscho 2015-08-19 20:43:19 UTC
Sorry, I have no time atm to teach myself on how to compile the kernel and add patches and so on (I like to do as soon as I have time). So I've just installed Kernel 4.1.6 as *.deb on my Xubuntu machine.

A very big thank you for your efforts. Tvrgb works for me when I enable it via xrandr. My grey levels are way better now and my Chroomecast image isn't greyish anylonger, because I can use limitedRGB on every device.
The ycbcr  modes give me shifted colors (greyish pink).


PS: First I acceidentally enabled tvrgb for the wrong output (HDMI-1 (nothing connected) instead of HDMI-0) This froze my lightdm session and I had to reboot. sudo restart lightdm did not work.
Comment 31 sweeneygj 2015-08-27 11:22:50 UTC
I have a DCE3 (RS880) and a monitor which supports RGB quantisation.

before executing the EDID test the values are 

radeon_encoder->output_csc = RADEON_OUTPUT_CSC_BYPASS
frame.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT

then it executes the EDID test    

if (drm_rgb_quant_range_selectable(radeon_connector_edid(connector))) {
   if (radeon_encoder->output_csc == RADEON_OUTPUT_CSC_TVRGB)
      frame.quantization_range = HDMI_QUANTIZATION_RANGE_LIMITED;
   else
      frame.quantization_range = HDMI_QUANTIZATION_RANGE_FULL;                    
} else {
   frame.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
}

and the monitor loses sync and displays a blank screen.

Should the code test both the EDID and output_csc != BYPASS before attempting the range change?
Comment 32 Alex Deucher 2015-08-27 13:55:12 UTC
Created attachment 117948 [details] [review]
possible fix

(In reply to sweeneygj from comment #31)
> Should the code test both the EDID and output_csc != BYPASS before
> attempting the range change?

Yes.  Good catch.  Patch attached.
Comment 33 freddyescobar 2015-09-03 13:32:13 UTC
I have a DCE4 (HD5770) and i don't know if my monitor supports RGB quantization. I guess it can't (old Philips from 2007).

What could you suggest to me ? (Of course, output is Full RGB, and my tv is limited RGB).
Comment 34 N. W. 2016-06-05 14:04:02 UTC
(In reply to Andy Furniss from comment #12)
> (In reply to John from comment #10)
> > I've applied the patches but I am not sure how to enable anything.
> > Since it's a drm patch, am I suppose to enable that the same way I do for
> > audio and dpm?
> > If so, I haven't tried, but I don't see anything in modinfo for csc.
> 
> xrandr --verbose will show you the options/output name and the current
> setting.
> 
> to change do something like -
> 
> xrandr --output HDMI-0 --set output_csc tvrgb

Could anyone please explain why this setting needs to be done via xrandr?

Why not via the xorg.conf.d files?

To enable the TearFree option for example you can add:

   Option "TearFree" "True"

inside a xorg.conf.d file for example.

So why can't the color range be set via a xorg.conf.d file like this for example:

   Option "Broadcast RGB" "Limited"

?

Why xrandr and not xorg.conf.d? Or why not both?

Also, why is the AMD driver's option being called:

xrandr --output $OUTPUT --set output_csc tvrgb

?

For the Intel driver it's called:

xrandr --output $OUTPUT --set "Broadcast RGB" "Limited"

Why does the setting have to have a different name between the AMD and Intel driver?

Why can't the names just be kept the same?

Regards


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.