GNOME Bugzilla – Bug 781856
Provide way to set full RGB range output in GNOME on Wayland.
Last modified: 2021-07-05 13:47:33 UTC
In Gnome on Xorg, I can type in terminal: xrandr --output OUTPUT --mode MODE --rate RATE --set "Broadcast RGB" "Full" to set full HDMI output range. However in Wayland this can't work. So there is no way to set my video output properly using GNOME/Wayland. There should be option in Gnome Settings, I think in Monitors, for example, as an option below refresh rate.
I have no idea what this option does. Reassigning to something that does touch the screen configuration.
Created attachment 350598 [details] Raspberry Pi config file (part about HDMI range)
"PCs, TVs, and other devices represent colors using a range of numbers. “RGB Full” represents colors using values from 0 to 255. 0 is the blackest black, and 255 is the whitest white. “RGB Limited” represents colors using values from 16 to 235. 16 is the blackest black and 235 is the whitest white." Some displays can be set to display both 'Full' and 'Limited' range. However some expect 'Full' range, for example display which I am using (Dell PH2417H). There are also displays which can only display 'Limited' range. Example from Raspberry Pi config file: https://bug781856.bugzilla-attachments.gnome.org/attachment.cgi?id=350598 Article which covers the topic (it's about setting in Windows, however it's exactly the thing that Gnome/Wayland is missing) https://www.howtogeek.com/285277/how-to-avoid-washed-out-colors-when-using-hdmi-on-your-pc/
Comment on attachment 350598 [details] Raspberry Pi config file (part about HDMI range) http://elinux.org/RPiconfig
This sounds like color management, which is already possible using colord. How is this different? I'm no color expert, so would need some insight here.
Info from Archlinux Wiki: https://wiki.archlinux.org/index.php/Intel_graphics#Weathered_colors_.28color_range_problem.29 I'm pretty sure, that video output signal type and color management are two different things. Over HDMI there is possible to send signals: * RGB limited (16-235) * RGB full ( 0-255) * YCbCr limited (16-235) * YCbCr full ( 0-255) But not every display can handle every one of them. If display is set to display one of them, and we send other, there will be conflict. When the "RGB Limited" is send to display, which expects "RGB full" the black levels will be damaged. "RGB Limited" means that, only 16-235 from 8 bit data is used. 16 and below is the darkest level of color (R/G/B) and above 235 is the brightest. "RGB Full" uses 0-255 levels. So when display only support "RGB Full" range and output is set to "RGB Limited", it will only display greyish black. That's because for display in "RGB Limited" mode, "16" is the darkest level, but for display in "RGB Full" the darkest level is "0", so "16" is interpreted as grey (when the pixel is set to black, so in "Limited" (16,16,16) but in "Full" (0,0,0)) The same problem applies to white levels. In Xorg, that can be set: * xrandr --output $OUTPUT --set "Broadcast RGB" "Limited 16:235" * xrandr --output $OUTPUT --set "Broadcast RGB" "Full" But in Wayland it can't be done that way. The Wayland compositor should take care of that and provides method to set this parameter. (e.g. Gnome Settings -> Displays)
The range compression is, as mentioned above, part of the scanout. If the signal is set to Limited, the hardware compresses the 0-255 range into 16-235 before passing the signal to the monitor. IIRC, at some point in the recent past, DRM and/or the i915 driver changed the default ("Automatic") to select limited color range for all CEA video modes except 640x480. This includes a set of LG Flatron E2251 1080p60 screens I have here, iff they're connected via HDMI. The most visible aspect is that the black level is too high, so contrast suffers. The screens cannot be configured to recover the original 0-255 range from the compressed signal. There really needs to be exposed.
Bug 777248, a duplicate, has some more information including links to related external bugs.
*** Bug 777248 has been marked as a duplicate of this bug. ***
I don't understand why all the reporters are asking for it to be an option, instead of asking for it to be the default, if the hardware supports it. Is it not detectable?
The EDID (https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#CEA_EDID_Timing_Extension_data_format_--_Version_3) contains mode timings and if YCbCr is supported, but not the expected signal range. The HDMI spec (http://www.microprocessor.org/HDMISpecification13a.pdf) says, under 6.6, that "while using RGB, Limited Range shall be used for all video formats defined in CEA-861-D, with the exception of VGA (640x480) format, which requires Full Range." The gist I got from https://bugzilla.kernel.org/show_bug.cgi?id=94921#c4 is that this is not detectable. The kernel, by default, follows the HDMI spec. There is just lots of hardware which doesn't follow spec and always expects a full range signal. Hence, washed-out colors.
Many devices (mainly TV sets) do have the option to switch between limited and full, which makes autodetection even more impossible.
Yes, and this also applies to signal producers, not just consumers. AFAIK all video game consoles have a range setting for the HDMI output.
(In reply to Jan Alexander Steffens (heftig) from comment #13) > Yes, and this also applies to signal producers, not just consumers. AFAIK > all video game consoles have a range setting for the HDMI output. If you have screenshots from other OSes or systems that offer this option, please include links here, or upload the screenshots if they're small enough. Also, am I correct in thinking that this only applies to HDMI, or is it also an option when using other digital outputs, such as (mini)-DisplayPort. What about embedded DisplayPort (eDP) used as interconnect for many internal laptop screens?
(In reply to Bastien Nocera from comment #14) > (In reply to Jan Alexander Steffens (heftig) from comment #13) > > Yes, and this also applies to signal producers, not just consumers. AFAIK > > all video game consoles have a range setting for the HDMI output. > > If you have screenshots from other OSes or systems that offer this option, > please include links here, or upload the screenshots if they're small enough. > I posted this before. https://www.howtogeek.com/285277/how-to-avoid-washed-out-colors-when-using-hdmi-on-your-pc/ > Also, am I correct in thinking that this only applies to HDMI, or is it also > an option when using other digital outputs, such as (mini)-DisplayPort. What > about embedded DisplayPort (eDP) used as interconnect for many internal > laptop screens?
(In reply to Paweł Faderewski from comment #15) > (In reply to Bastien Nocera from comment #14) > > (In reply to Jan Alexander Steffens (heftig) from comment #13) > > > Yes, and this also applies to signal producers, not just consumers. AFAIK > > > all video game consoles have a range setting for the HDMI output. > > > > If you have screenshots from other OSes or systems that offer this option, > > please include links here, or upload the screenshots if they're small enough. > > > > I posted this before. > > https://www.howtogeek.com/285277/how-to-avoid-washed-out-colors-when-using- > hdmi-on-your-pc/ Do you have any screenshots that aren't part of UIs written by driver authors. Those are positively awful. Though it does show that there is a "default" value for those in the Intel configuration tool.
(In reply to Bastien Nocera from comment #16) > (In reply to Paweł Faderewski from comment #15) > > (In reply to Bastien Nocera from comment #14) > > > (In reply to Jan Alexander Steffens (heftig) from comment #13) > > > > Yes, and this also applies to signal producers, not just consumers. AFAIK > > > > all video game consoles have a range setting for the HDMI output. > > > > > > If you have screenshots from other OSes or systems that offer this option, > > > please include links here, or upload the screenshots if they're small enough. > > > > > > > I posted this before. > > > > https://www.howtogeek.com/285277/how-to-avoid-washed-out-colors-when-using- > > hdmi-on-your-pc/ > > Do you have any screenshots that aren't part of UIs written by driver > authors. Those are positively awful. Though it does show that there is a > "default" value for those in the Intel configuration tool. PS3 config: https://cnet3.cbsistatic.com/img/BlDGCMgKtK6arZZKZYrrNmNUvZA=/fit-in/570x0/2008/08/21/89abd261-f4d6-11e2-8c7c-d4ae52e62bcc/ps3_screensot.JPG http://manuals.playstation.net/document/en/ps3/current/settings/rgbfullrange.html PS4 config: http://imgur.com/VhpTd1A Raspberry Pi config (Video -> hdmi_pixel_encoding): http://elinux.org/RPiconfig Is this any good? About default, as someone said before, it's only guess, not really autodetection. In my case, my display expects full range, but Intel driver is using limited range. I can change range, by using xrandr on Xorg, but not when using Wayland.
Created attachment 352998 [details] Panasonic TV RGB range config 1
Created attachment 352999 [details] Panasonic TV RGB range config 2
Uploaded receiver side UI for reference. "Normal" in this case really means limited.
There's another article on howtogeek with screenshots from a (Samsung?) TV, a PS4 and an XBox One: https://www.howtogeek.com/295569/should-i-use-rgb-limited-or-rgb-full-on-my-playstation-or-xbox/ Another TV: http://s1368.photobucket.com/user/Dmitrij_Godzjura/media/DSC04038_zps7f078156.jpg.html A Nintendo Switch: http://en-americas-support.nintendo.com/app/answers/detail/a_id/22331/~/how-to-adjust-the-tv-settings An XBox 360, which seems to have a third setting between 16-235 and 0-255: http://www.sixfortyfive.com/streaming/calibration/xbox360_reference.png --- The "limited" signal is really a signal with toe- and headroom, allowing colors outside the bounds of the color space. So for a proper display, (16, 16, 16) really is reference black and (235, 235, 235) really is reference white. The signal can have darker colors called "blacker than black" and brighter colors called "whiter than white". They're there in case your not perfectly calibrated input wasn't quite constrained to be between the reference levels. The display might or might not be capable of displaying these colors. A conformant HDMI display calibrated for sRGB would fit the limited range to the sRGB space. A conformant HDMI output calibrated for sRGB would do the same. In the PC world we don't have toe- or headroom, though. So you end up with this "Broadcast RGB" hack where the color range gets compressed in order to ensure it's displayable. Trying to display an sRGB image, depending how you configure the GPU's output and the monitor's input (if you can), you get these cases: Output is limited, input is limited: Colors match but you introduce quantization noise. Output is full, input is limited: Colors get blown out, leaving the sRGB space. Output is limited, input is full: Colors get washed out. Output is full, input is full: Colors match.
Hopefully that's enough information for the mutter developers to start looking into how the option should be made available. And we can see what is needed on the UI side when we get to it.
I find it kinda discouraging that my report was resolved as a duplicate, even though I reported it first (months earlier): https://bugzilla.gnome.org/show_bug.cgi?id=777248 Anyway: (In reply to Paweł Faderewski from comment #6) > Over HDMI there is possible to send signals: > > * RGB limited (16-235) > * RGB full ( 0-255) > * YCbCr limited (16-235) > * YCbCr full ( 0-255) Wrong. It's: * RGB limited range 16-235 * RGB full range 0-255 * YCbCr 4:2:2 limited range 16-235 (YCbCr is always limited range, 4:2:2 refers to chroma subsampling) * YCbCr 4:4:4 limited range 16-235 (YCbCr is always limited range, 4:4:4 refers to chroma subsampling [4:4:4 = no chroma subsampling, i.e. full samples) However, the Intel and the AMD drivers mostly support RGB only. (In reply to Jan Alexander Steffens (heftig) from comment #21) > Trying to display an sRGB image, depending how you configure the GPU's > output and the monitor's input (if you can), you get these cases: > > Output is limited, input is limited: > Colors match but you introduce quantization noise. > > Output is full, input is limited: > Colors get blown out, leaving the sRGB space. > > Output is limited, input is full: > Colors get washed out. > > Output is full, input is full: > Colors match. Wrong. It's: Output is limited, input is limited: Neither crushed blacks nor gray blacks, but 0-255 is being compressed into 16-235 (with Intel). Output is full, input is limited: Blacks are being crushed Output is limited, input is full: Black is not black, instead black is gray, resulting in a washed out image, also 0-255 is simply being compressed into 16-235 (with Intel). Output is full, input is full: Everything is correct. (In reply to Bastien Nocera from comment #14) > Also, am I correct in thinking that this only applies to HDMI, or is it also > an option when using other digital outputs, such as (mini)-DisplayPort. What > about embedded DisplayPort (eDP) used as interconnect for many internal > laptop screens? It mostly applies to what you connect to, i.e. mostly applies when you connect to HDMI _inputs_ (i.e. the port on the monitor). Whether you use a straight HDMI to HDMI cable or a DisplayPort to HDMI adapter-cable or a DVI-D to HDMI adapter-cable often does not make much of a difference. HDMI inputs usually are the only kind of inputs that allow (or often require) to configure the output to either limited range or full range, to match the input. That being said though: The Intel driver has this set to automatic by default, which sucks, since it often sends limited range even when this is not desired or plain wrong and can also affect DVI-D and DisplayPort inputs, see for example: https://bugzilla.kernel.org/show_bug.cgi?id=94921 https://bugs.freedesktop.org/show_bug.cgi?id=100023 For the Intel driver it can be adjusted like this: Full range: xrandr --output $OUTPUT --set "Broadcast RGB" "Full" Limited range: xrandr --output $OUTPUT --set "Broadcast RGB" "Limited 16:235" Automatic: xrandr --output $OUTPUT --set "Broadcast RGB" "Automatic" The AMD driver(s) however do default to full range at all times, which is much better. The AMD driver now also has an option to switch between full range and limited range, see: https://bugs.freedesktop.org/show_bug.cgi?id=83226 So, for AMD it works like this: Full range: xrandr --output $OUTPUT --set output_csc bypass Limited range: xrandr --output $OUTPUT --set output_csc tvrgb However, since this is about Wayland, we obviously can't use xrandr, so the compositor needs to do this via the DRM property: https://01.org/linuxgraphics/gfx-docs/drm/drm-kms-properties.html https://bugs.freedesktop.org/show_bug.cgi?id=83226 Hence why this feature request exists... By the way, I've also requested this for Weston and for KWin, see: https://bugs.freedesktop.org/show_bug.cgi?id=99406 https://bugs.kde.org/show_bug.cgi?id=375666 (In reply to Paweł Faderewski from comment #17) > I can change range, by using xrandr > on Xorg, but not when using Wayland. Actually it looks like there might be a way to do it as a workaround before the Wayland compositor is being started, but I haven't really figured out the logic behind it, see: [QUOTE=fritsch in https://forum.kodi.tv/showthread.php?tid=301776] https://forum.kodi.tv/showthread.php?tid=301776 You can configure that _before_ you start wayland / weston whatever. A starting point is the proptest of libdrm Example for my HDMI port: proptest -M i915 -D /dev/dri/card0 61 connector 54 1 In my setup I used weston and kodi from the GSOC project. [/QUOTE]
Ahahaha, now that I was talking about it, I did some additional Googling and look what I've found: https://www.brad-x.com/2017/08/07/quick-tip-setting-the-color-space-value-in-wayland/ ;)
Anyway, that proptest solution there really isn't user friendly, so it would be nice if we would have a nice GUI solution for it in Mutter for GNOME which can be invoked while Wayland is running and doesn't need to be invoked before Wayland is running.
Any update?
Any update on this one?
No. If there were updates, you would see them in this ticket.
This request is a subset of Bug 774742
Atomic mode setting support has landed in mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.