Hi, apparently the Intel HD Graphics driver for Windows has a "IT Content" option that can be either enabled or disabled, see following screenshot for example: https://www.howtogeek.com/wp-content/uploads/2016/12/img_5855c293ac26d.jpg According to a post on the AVS Forum, enabling "IT Content" does the following: http://www.avsforum.com/forum/26-home-theater-computers/1477460-theory-about-intel-s-hdmi-quantization-range-setting-full-0-255-a-7.html#post24629922 > HDMI specs "IT Content" flag is set On in video stream. > > CEA-861: > "In IT applications (e.g. involving bit mapped text), > each pixel in the source’s frame buffer is most clearly > displayed if it is directly mapped to a light-emitting pixel > on the display device - such that adjacent pixels are > completely independent and do not interact. > The IT content bit indicates when picture content is > composed according to common IT practice (i.e. without > regard to Nyquist criterion) and is unsuitable for > analog reconstruction or filtering. When the IT content bit > is set to 1, downstream processors should pass > pixel data unfiltered and without analog reconstruction." Apparently there is no option for it on the Linux driver. Can you please add an option to the Linux driver which allows to enable the "IT Content" bit? Regards
PS: Apparently the NVIDIA driver for Windows supports this as well, see following screenshot and forum thread for example: http://abload.de/img/hdmi-content-typebtumj.png https://forums.geforce.com/default/topic/814785/hdmi-content-type-api-/ Also found something on hdmi.org: https://www.hdmi.org/manufacturer/hdmi_1_4/content_type.aspx Apparently there is not just a setting for "IT Content", but for "gaming, movie, photograph, and text viewing modes". And the receiving display can alter it's processing settings based on which type of content it receives. It would be amazing if that would be possible on Linux as well. Looks like other Linux users have complained about the lack of such an option as well: https://github.com/ValveSoftware/SteamOS/issues/494 https://devtalk.nvidia.com/default/topic/952181/linux/is-hdmi-content-type-supported-in-any-way-/
Should be pretty trivial to add an enum connector property to specify the content type.
(In reply to Ville Syrjala from comment #2) > Should be pretty trivial to add an enum connector property to specify the > content type. Thanks for commenting. Any chance for it to appear in kernel 4.15? Ubuntu 18.04 LTS will ship with kernel 4.15 according to the current release schedule.
Any update?
But is the goal just to change the color range? See "Broadcast RGB" property.
(In reply to Jani Nikula from comment #5) > But is the goal just to change the color range? See "Broadcast RGB" property. As you should know, I am very familiar with the "Broadcast RGB" property, see: https://bugs.freedesktop.org/show_bug.cgi?id=100023 This bug here is not to just change to change the color range though. The goal in this case is to set/force the connected TV into a specific HDMI content type mode. A lot of HDTVs have a PC mode, where all internal video processing is being bypassed and full chroma resolution is being displayed (i.e. no subsampling). Most TVs have an option to activate the PC mode, however: 1. Often this is very awkward to do, often you have to rename the HDMI input of the TV to "PC" in order for the PC mode to become enabled. If you want to use PC mode and Movie mode on the same HDMI input depending on what you feed the TV with (i.e. running KODI for videos and running a browser for websurfing), it's obviously very awkward and inconvenient to rename the HDMI input using the TVs OSD each time you switch between watching movies and browsing the web for example. If there would be a xrandr option to allow to switch between which mode the TV is being set to, that would be very helpful in this case. 2. Some TVs do not allow to switch the TV into a PC mode (at least not via the OSD). It would be interesting to see what such TVs will do, when you send it a signal with HDMI content type set to "IT" (or "Graphics" or whatever it is being called). Maybe that way it would be possible to achieve a PC mode on such TVs, which would be incredibly nice.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
I haven't seen any updates on this. I set the quantumization setting in Windows and my HDMI connected TV is fine, but there is no setting on Linux, so colors are off. Is there a way to fix? Thanks!
Hi, I've just started to work on this issue - currently it requires adding a new property to drm_connector_state. I will keep this ticket updated.
UPDATE: Finished working on the patch, xrandr will now show "content type" property for the HDMI output which can be also manipulated, will soon send it for review.
Setting state to assigned, patch is ready and is going through review process.
Getting some testing from the people who asked for this might be a decent idea: https://patchwork.freedesktop.org/series/41874/ Please test if possible and make sure it behaves as you'd expect.
Reporter, please try to verify the fix as proposed in previous message. One way to switch between different Content-type modes is using xrandr. You can see all the possible Content-type values by typing xrandr --prop and look for it in the HDMI properties. Then you can set one of those with xrandr --output (HDMI_OUTPUT_NAME) --set "content type" "Graphics" for example. After that the display should switch to new the mode(if it is supported by display).
Reporter, any updates from you?
Reporter, proposed solution is ready for review/testing. Are you able to test? See: https://patchwork.freedesktop.org/series/41876/
Developer, unless it is merged into the mainline kernel it will be difficult to test. Not all users compile kernels themselves. No offense, but judging from your email address, you seem to be working for Intel and working on graphics products. Don't you have a PC with HDMI output and TV with HDMI input in your office/lab to test it yourself? Just saying. By the way: Is that patch also supposed to work when using a DisplayPort to HDMI adapter or DVI-D to HDMI adapter?
(In reply to N. W. from comment #16) > Developer, unless it is merged into the mainline kernel it will be difficult > to test. Not all users compile kernels themselves. > > No offense, but judging from your email address, you seem to be working for > Intel and working on graphics products. Don't you have a PC with HDMI output > and TV with HDMI input in your office/lab to test it yourself? Just saying. > > By the way: Is that patch also supposed to work when using a DisplayPort to > HDMI adapter or DVI-D to HDMI adapter? Yes, sure I have :) I have tested and it works for me, however I was recommended by colleague(Ville Sirjala) to ask reporter to verify the fix. Probably as we are still developing specific CI test for that. I'm pretty sure it's going to work though, as the change is trivial. As for second question, currently is it supposed to work only with HDMI connector and other connector types don't use this DRM property.
(In reply to Stanislav Lisovskiy from comment #17) > Yes, sure I have :) I have tested and it works for me > I'm pretty sure it's going to work though, as the change is trivial. Then it would probably be wise to merge it into the mainline kernel, so that 4.17 will have it. (In reply to Stanislav Lisovskiy from comment #17) > As for second question, currently is it supposed to work only with HDMI > connector and other connector types don't use this DRM property. Can you please also enable it for cases where a DisplayPort to HDMI or DVI-D to HDMI adapter is being used? Not all devices have native HDMI outputs, but have DisplayPort or DVI-D outputs instead, which can also be connected to HDMI inputs via simple passive adapters.
(In reply to N. W. from comment #18) > Then it would probably be wise to merge it into the mainline kernel, so that > 4.17 will have it. v4.17 is long done as far as features go, and the ship has sailed for v4.18 also. v4.19 is the earliest this can go to.
Series pushed to drm-misc-next. Goes to 4.19 I suppose.
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.