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!
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.
Is using the generic modesetting ddx a better plan for this?
Created attachment 113757 [details] [review] patch 1/2 These two patches implement support for this on DCE5+ hardware via the output_csc property.
Created attachment 113758 [details] [review] patch 2/2 Please apply both patches.
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.
(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.
(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.
Created attachment 113778 [details] [review] set quantization_range in AVI infoframe if the monitor supports selectable range
(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.
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.
@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
(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
(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)
(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.
(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.
(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!
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.
(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.
*** Bug 87591 has been marked as a duplicate of this bug. ***
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.
(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.
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.
I think it's because i have a HD5770 with DCE4 display core.
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!
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.
(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
(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.
Created attachment 117787 [details] [review] patch 1/2 Do these patches make YUV work for you? Select output_csc ycbcr601 or ycbcr709
Created attachment 117788 [details] [review] patch 2/2
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.
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?
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.
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).
(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
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1211.
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.