Bug 55121 - Limited color range on screen that is connected via HDMI [SandyBridge]
Summary: Limited color range on screen that is connected via HDMI [SandyBridge]
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-12 20:24 UTC by Ivan Bulatovic
Modified: 2014-09-27 14:00 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.8.0-rc3-MAINLINE+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Ivan Bulatovic 2013-03-12 20:24:22 UTC
After testing linux-3.9.0-rc1 I've noticed that, when KMS kicks in, background is gray instead of black and so are the fonts (grayish instead of white). This remains the same after starting KDE. I haven't had the time to look into this further 'till now, so here is the result of the bisect:

[root@silverstone linux-3.9.0-rc2]# git bisect good
55bc60db5988c8366751d3d04dd690698a53412c is the first bad commit
commit 55bc60db5988c8366751d3d04dd690698a53412c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Jan 17 16:31:29 2013 +0200

    drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
    
    Add a new "Automatic" mode to the "Broadcast RGB" range property.
    When selected the driver automagically selects between full range and
    limited range output.
    
    Based on CEA-861 [1] guidelines, limited range output is selected if the
    mode is a CEA mode, except 640x480. Otherwise full range output is used.
    Additionally DVI monitors should most likely default to full range
    always.
    
    As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
    otherwise will follow CEA-861 rules.
    
    NOTE: The default value for the property will now be "Automatic"
    so some people may be affected in case they're relying on the
    current full range default.
    
    [1] CEA-861-E - 5.1 Default Encoding Parameters
    [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
    
    v2: Use has_hdmi_sink to check if a HDMI monitor is present
    v3: Add information about relevant spec chapters
    
    Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 ca743831e7c311d70360e57754f616a3e25bfc7c 18a3d2c4e6c9c12321f363d5442a847340bfd504 M      drivers                                                                                                                                                                   
[root@silverstone linux-3.9.0-rc2]# uname -a                                                                                                                                                                                                                                      
Linux silverstone 3.8.0-rc3-MAINLINE+ #13 SMP PREEMPT Tue Mar 12 21:03:47 CET 2013 x86_64 GNU/Linux 

dmesg output doesn't hold anything suspicous AFAIK.

Monitor: Samsung BX2231 connected via HDMI
IGP: Intel HD2000 (i5-2400)

TIA!
Comment 1 Feng, Cancan 2013-03-13 07:35:55 UTC
The same issue of HDMI exists on G45. Testing branch we used is drm-intel-testing from  git://people.freedesktop.org/~danvet/drm-intel. 
Here are three modes which have problem:
1.      CRTS(3):[0]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148500
2.      CRTS(3):[0]  1280x720 60 1280 1390 1430 1650 720 725 730 750 0x5 0x40 74250
3.      CRTS(3):[0]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27000

If you need more information, please feel free to let me know.
Comment 2 Ivan Bulatovic 2013-03-18 19:26:44 UTC
OK, when I set HDMI black level option to Low on my monitor OSD, output is correct again. According to the information I was able to pick up this option limits the range to 16-235 (default normal setting expands this to 0-255). 

However whites are a bit dirty, flashy and they strain my eyes if I try to rev up brightness, when I lower the brightness setting then whites are just dirty :)

I remember the first few days since I bought this monitor, low black level option produced clean black but white and other colors were a lot worse than with the normal setting.

Heck, I don't know now if this is a bug or feature or I should just get me a better monitor :) I would appreciate a small explanation about this...
Comment 3 Daniel Vetter 2013-03-18 19:31:26 UTC
The commit you've bisect to tries to set the reduced range mode (i.e. 16-240) automatically according to what the hdmi/dp spec suggests. Which means if you set up a mode listed in the CEA mode list.

Can you please check what happens when you pick an auto setting in your OSD (if there is such a thing)?

Next step is to force the newly added xrandr property to what you want, but currently we don't tell the screen what we've set through the hdmi infoframes. So I this might not work yet correctly, but require a corresponding manual setting in the OSD. Iirc hdmi specs under which exact circumstances monitors must follow the infofram setting, so we might need to implement that and default to the non-reduced range if possible.

Generally though hdmi corner cases seem to be made of fail unfortunately, so this might take a few patches to fix properly :(
Comment 4 Ivan Bulatovic 2013-03-18 20:48:03 UTC
Here is the section regarding HDMI black levels from monitor manual:

HDMI Black Level When watching with a DVD or set-top box connecting to the product via HDMI, image quality deterioration (black level, lower-quality contrast, lighter color tone, etc.) may occur depending on the connected external device.
•<Normal>
•<Low>
This function is active only when the external device is connected via <HDMI>. The <HDMI Black Level> function may not be compatible with all external devices.

It defaults to Normal (AFAIK it represents the full range mode) and it worked before this commit.

So, somehow "Automatic" mode for the "Broadcast RGB" property defaults to limited range output even though full range mode is supported.

Thanks for the explanation Daniel, I had the missfortune to step on more than a few landmines that OEM's layed out _strictly_ following "standard" specs (ie ACPI tables) so I'll guess I will just wait and keep an eye out for any patches regarding this commit and report back if anything changes.

If Ville wants to have any patches tested against this exact case before hiting mainline I would be glad to help out.

Best regards !
Comment 5 Ivan Bulatovic 2013-03-18 20:52:12 UTC
Oh, maybe this would be of any help

xrandr --query --verbose

HDMI3 connected 1920x1080+0+0 (0x49) normal (normal left inverted right x axis y axis) 477mm x 268mm
        Identifier: 0x45
        Timestamp:  6617
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:    
        CRTC:       0
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        EDID: 
                00ffffffffffff004c2d6d0745433242
                0215010380301b782a78f1a655489b26
                125054bfef80714f8100814081809500
                950fa940b300023a801871382d40582c
                4500dd0c1100001e011d007251d01e20
                6e285500dd0c1100001e000000fd0038
                4b1e5111000a202020202020000000fc
                00534d4258323233310a20202020015c
                02031cf14890041f0514131203230907
                078301000066030c00200080011d80d0
                721c1620102c2580dd0c1100009e011d
                8018711c1620582c2500dd0c1100009e
                011d00bc52d01e20b8285540dd0c1100
                001e8c0ad090204031200c405500dd0c
                110000188c0ad08a20e02d10103e9600
                dd0c1100001800000000000000000036
        Broadcast RGB: Automatic 
                supported: AutomaticFullLimited 16:235
        audio: auto 
                supported: force-dvioffautoon
  1920x1080 (0x49)  148.5MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
  1920x1080 (0x4a)  148.5MHz +HSync +VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   56.2KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   50.0Hz
  1920x1080i (0x4b)   74.2MHz +HSync +VSync Interlace
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   28.1KHz
        v: height 1080 start 1084 end 1094 total 1125           clock   50.0Hz
  1920x1080i (0x4c)   74.2MHz +HSync +VSync Interlace
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   33.8KHz
        v: height 1080 start 1084 end 1094 total 1125           clock   60.1Hz
  1600x1200 (0x4d)  162.0MHz +HSync +VSync
        h: width  1600 start 1664 end 1856 total 2160 skew    0 clock   75.0KHz
        v: height 1200 start 1201 end 1204 total 1250           clock   60.0Hz
  1680x1050 (0x4e)  119.0MHz +HSync -VSync
        h: width  1680 start 1728 end 1760 total 1840 skew    0 clock   64.7KHz
        v: height 1050 start 1053 end 1059 total 1080           clock   59.9Hz
  1280x1024 (0x4f)  135.0MHz +HSync +VSync
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
  1280x1024 (0x50)  108.0MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1440x900 (0x51)  136.8MHz -HSync +VSync
        h: width  1440 start 1536 end 1688 total 1936 skew    0 clock   70.6KHz
        v: height  900 start  903 end  909 total  942           clock   75.0Hz
  1440x900 (0x52)   88.8MHz +HSync -VSync
        h: width  1440 start 1488 end 1520 total 1600 skew    0 clock   55.5KHz
        v: height  900 start  903 end  909 total  926           clock   59.9Hz
  1280x960 (0x53)  108.0MHz +HSync +VSync
        h: width  1280 start 1376 end 1488 total 1800 skew    0 clock   60.0KHz
        v: height  960 start  961 end  964 total 1000           clock   60.0Hz
  1280x800 (0x54)   71.0MHz +HSync -VSync
        h: width  1280 start 1328 end 1360 total 1440 skew    0 clock   49.3KHz
        v: height  800 start  803 end  809 total  823           clock   59.9Hz
  1152x864 (0x55)  108.0MHz +HSync +VSync
        h: width  1152 start 1216 end 1344 total 1600 skew    0 clock   67.5KHz
        v: height  864 start  865 end  868 total  900           clock   75.0Hz
  1280x720 (0x56)   74.2MHz +HSync +VSync
        h: width  1280 start 1720 end 1760 total 1980 skew    0 clock   37.5KHz
        v: height  720 start  725 end  730 total  750           clock   50.0Hz
  1280x720 (0x57)   74.2MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock   45.0KHz
        v: height  720 start  725 end  730 total  750           clock   60.0Hz
  1024x768 (0x58)   78.8MHz +HSync +VSync
        h: width  1024 start 1040 end 1136 total 1312 skew    0 clock   60.1KHz
        v: height  768 start  769 end  772 total  800           clock   75.1Hz
  1024x768 (0x59)   75.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1328 skew    0 clock   56.5KHz
        v: height  768 start  771 end  777 total  806           clock   70.1Hz
  1024x768 (0x5a)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  832x624 (0x5b)   57.3MHz -HSync -VSync
        h: width   832 start  864 end  928 total 1152 skew    0 clock   49.7KHz
        v: height  624 start  625 end  628 total  667           clock   74.6Hz
  800x600 (0x5c)   50.0MHz +HSync +VSync
        h: width   800 start  856 end  976 total 1040 skew    0 clock   48.1KHz
        v: height  600 start  637 end  643 total  666           clock   72.2Hz
  800x600 (0x5d)   49.5MHz +HSync +VSync
        h: width   800 start  816 end  896 total 1056 skew    0 clock   46.9KHz
        v: height  600 start  601 end  604 total  625           clock   75.0Hz
  800x600 (0x5e)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  800x600 (0x5f)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
        v: height  600 start  601 end  603 total  625           clock   56.2Hz
  720x576 (0x60)   27.0MHz -HSync -VSync
        h: width   720 start  732 end  796 total  864 skew    0 clock   31.2KHz
        v: height  576 start  581 end  586 total  625           clock   50.0Hz
  720x480 (0x61)   27.0MHz -HSync -VSync
        h: width   720 start  736 end  798 total  858 skew    0 clock   31.5KHz
        v: height  480 start  489 end  495 total  525           clock   59.9Hz
  640x480 (0x62)   31.5MHz -HSync -VSync
        h: width   640 start  664 end  704 total  832 skew    0 clock   37.9KHz
        v: height  480 start  489 end  491 total  520           clock   72.8Hz
  640x480 (0x63)   31.5MHz -HSync -VSync
        h: width   640 start  656 end  720 total  840 skew    0 clock   37.5KHz
        v: height  480 start  481 end  484 total  500           clock   75.0Hz
  640x480 (0x64)   30.2MHz -HSync -VSync
        h: width   640 start  704 end  768 total  864 skew    0 clock   35.0KHz
        v: height  480 start  483 end  486 total  525           clock   66.7Hz
  640x480 (0x65)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   60.0Hz
  720x400 (0x66)   28.3MHz -HSync +VSync
        h: width   720 start  738 end  846 total  900 skew    0 clock   31.5KHz
        v: height  400 start  412 end  414 total  449           clock   70.1Hz
Comment 6 Ville Syrjala 2013-04-10 13:51:53 UTC
(In reply to comment #4)
> Here is the section regarding HDMI black levels from monitor manual:
> 
> HDMI Black Level When watching with a DVD or set-top box connecting to the
> product via HDMI, image quality deterioration (black level, lower-quality
> contrast, lighter color tone, etc.) may occur depending on the connected
> external device.
> •<Normal>
> •<Low>
> This function is active only when the external device is connected via
> <HDMI>.
> The <HDMI Black Level> function may not be compatible with all external
> devices.
> 
> It defaults to Normal (AFAIK it represents the full range mode) and it worked
> before this commit.
> 
> So, somehow "Automatic" mode for the "Broadcast RGB" property defaults to
> limited range output even though full range mode is supported.

As stated in the commit message, the logic selects limited range when a CE video mode is used. And your monitor's preferred mode just happens to be one of these CE video modes, so there you have it.

Some monitors/TVs don't even allow you to change the setting from the OSD when a CE video mode is used (my TV is like this), so following the spec is pretty much the only option we have to guarantee that we see the expected result with most displays. In your case your monitor apparently allows you to change the setting even when using a CE video mode.

Unfortunately your monitor doesn't support another feature that would allow it to detect which setting is used by the source device, so you must manually choose the matching option from the OSD. And for some reason the monitor doesn't implement the CEA spec correctly, so it gives you the wrong default setting.

You said that you get a better picture when you configure your TV for "Low", but you said whites are dirty. Does that mean it's still too dark or something? I'm not 100% sure we're utilizing the 16-235 range fully, or if we're under/overshooting the signal a bit. Unfortunately I'd need a HDMI/DP frame grabber or some kind of analyzer to find out for sure, and I don't have such devices currently.

> Thanks for the explanation Daniel, I had the missfortune to step on more than
> a
> few landmines that OEM's layed out _strictly_ following "standard" specs (ie
> ACPI tables) so I'll guess I will just wait and keep an eye out for any
> patches
> regarding this commit and report back if anything changes.
> 
> If Ville wants to have any patches tested against this exact case before
> hiting
> mainline I would be glad to help out.

Unfortunately I don't see any good way to resolve this. Your monitor just implements the spec incorrectly, which means you have to configure such things manually.
Comment 7 Ivan Bulatovic 2013-04-10 21:23:07 UTC
(In reply to comment #6)
> As stated in the commit message, the logic selects limited range when a CE
> video mode is used. And your monitor's preferred mode just happens to be one
> of
> these CE video modes, so there you have it.
> 
> Some monitors/TVs don't even allow you to change the setting from the OSD
> when
> a CE video mode is used (my TV is like this), so following the spec is pretty
> much the only option we have to guarantee that we see the expected result
> with
> most displays. In your case your monitor apparently allows you to change the
> setting even when using a CE video mode.

Understood and agreed.

> Unfortunately your monitor doesn't support another feature that would allow
> it
> to detect which setting is used by the source device, so you must manually
> choose the matching option from the OSD. And for some reason the monitor
> doesn't implement the CEA spec correctly, so it gives you the wrong default
> setting.

OK, let me see if I understood this one.

1. Monitor default mode is CE
2. Monitor OSD default mode is wrong (set for Full range)
3. We automatically search for monitor default mode, CE is the one, set RGB color range to limited
4. Since OSD mode is Normal (instead of low) I can see white somewhat darker (it's not 0 now it's 16) and black somewhat lighter (it's 235 instead of 255).
5. Now monitor doesn't pick up that input is set to limited range and stays on Normal setting

One thing is missing though, what have we done before this commit ? We set the colorimetry to full range as default and if it isn't supported at all we set it to 16_235 ? If the data we receive is valid at all ? Looked at intel_sdvo.c and intel_sdvo_regs.h and still I'm not sure about this one.

But I don't have to be, it would be nice for us to be able to select rgb color range as a kernel parameter ie (maybe there is already, just not aware of it yet).

> You said that you get a better picture when you configure your TV for "Low",
> but you said whites are dirty. Does that mean it's still too dark or
> something?
> I'm not 100% sure we're utilizing the 16-235 range fully, or if we're
> under/overshooting the signal a bit. Unfortunately I'd need a HDMI/DP frame
> grabber or some kind of analyzer to find out for sure, and I don't have such
> devices currently.

Don't worry about this, this isn't about the signal, it's this trash for a monitor that I shouldn't have bought in the first place. :)

I was just trying to figure out how can we emerge from this, if specs werent followed strictly - problems are bound to happen either way and the only thing that can help the end user is to set the parameters himself. Personally I'm wondering is there a way and how ?

Thanks Ville !
Comment 8 Ville Syrjala 2013-04-11 09:00:57 UTC
(In reply to comment #7)
> 
> OK, let me see if I understood this one.
> 
> 1. Monitor default mode is CE
> 2. Monitor OSD default mode is wrong (set for Full range)
> 3. We automatically search for monitor default mode, CE is the one, set RGB
> color range to limited
> 4. Since OSD mode is Normal (instead of low) I can see white somewhat darker
> (it's not 0 now it's 16) and black somewhat lighter (it's 235 instead of
> 255).
> 5. Now monitor doesn't pick up that input is set to limited range and stays
> on
> Normal setting

Yep, you got it.

There's a perfectly good mechanism in the spec for informing the display about the actually used range, but sadly I've not yet seen a display that implements it :(

> 
> One thing is missing though, what have we done before this commit ? We set
> the
> colorimetry to full range as default and if it isn't supported at all we set
> it
> to 16_235 ?

The old way was to default to full range always, and allow user to change to limited range manually. The automatic mode wasn't there.

> If the data we receive is valid at all ? Looked at intel_sdvo.c and
> intel_sdvo_regs.h and still I'm not sure about this one.
> 
> But I don't have to be, it would be nice for us to be able to select rgb
> color
> range as a kernel parameter ie (maybe there is already, just not aware of it
> yet).

There's no parameter currently. I started to actually think that it might be nice to be able to override the defaults for various properties in general. But that's a bigger topic that needs a lot more thought.

> I was just trying to figure out how can we emerge from this, if specs werent
> followed strictly - problems are bound to happen either way and the only
> thing
> that can help the end user is to set the parameters himself. Personally I'm
> wondering is there a way and how ?

The only chance I see is that we'd detect somehow that the display is using full range by default. I was thinking that it might be a more general issue with monitors, whereas TVs would be more likely to use limited range. But unfortunately I don't know of any way to tell TVs and monitors apart based on the EDID information. A blacklist would be another option, but that approach won't scale very well.
Comment 9 Daniel Vetter 2013-04-11 09:11:54 UTC
On Thu, Apr 11, 2013 at 11:00 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
>> I was just trying to figure out how can we emerge from this, if specs werent
>> followed strictly - problems are bound to happen either way and the only
>> thing
>> that can help the end user is to set the parameters himself. Personally I'm
>> wondering is there a way and how ?
>
> The only chance I see is that we'd detect somehow that the display is using
> full range by default. I was thinking that it might be a more general issue
> with monitors, whereas TVs would be more likely to use limited range. But
> unfortunately I don't know of any way to tell TVs and monitors apart based on
> the EDID information. A blacklist would be another option, but that approach
> won't scale very well.

At least my 24" desktop screens from HP here implement the
limited/full color range stuff according to spec on HDMI. So I don't
think it's an issue with TV vs. computer screens, but probably more
with sloppy/cheap vs. not-so-cheap ...

I think this is not a game we can't win, but with the automatic mode
we should at least make conformant hw work. Anything else needs manual
configuration anyway :(
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Comment 10 Ivan Bulatovic 2013-04-11 09:27:43 UTC
OK, so now the only thing is missing is the ability to manually configure RGB broadcast range. I'm thinking that the best way would be through the kernel parameter, since adding this option for a xf86-video-intel ddx driver might be too late in the process (maybe someone is defaulting to init 3 and later on starts X+DE/WM if at all and colors get fsckd the moment that KMS kicks in).

Adding quirks for a specific models of monitors would be one hell of a job and might never be complete enough...
Comment 11 Daniel Vetter 2013-04-11 09:34:25 UTC
Nope, we don't need any further options, since userspace can just set this like the ddx can. If they want to.

Which means plymouth (or any other graphical boot-splash) needs to learn this. And if you want this with the console something like kmscon is the right answer. Adding more kernel parameters for random hacks is not something I want.
Comment 12 Ivan Bulatovic 2013-04-11 11:18:08 UTC
Well, I've just tried to set RGB_BROADCAST property from userspace and it's a no go.

This is my 20-intel.conf in xorg.conf.d

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
#   Option      "TearFree"  "true"
EndSection


Section "Screen"
    Identifier "Default Screen Section"
    Device     "Intel Graphics"
    Monitor    "<default monitor>"
EndSection

Section "Monitor"
   Identifier "<default monitor>"
   Option "BROADCAST_RGB" "0"
EndSection

And from Xorg.0.log

(WW) intel(0): Option "BROADCAST_RGB" is not used

and when I try to set it via xrandr:

xrandr -d :0 --output HDMI3 --set "BROADCAST_RGB" "0"
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  37
  Current serial number in output stream:  37

I've tried with "Full" for BROADCAST_RGB and various other options and it allways show the same error.

man intel say:

SDVO and DVO TV outputs are not supported by the driver at this time.

So right now (unless I'm mistaken) there is no way for me to manually set Full range ? 

I know this might probably belong to a new bug report (if this is a bug at all, maybe ddx can't accept this option at all for now in this case).

Userspace applications should allow the user to exploit all the options that kernelspace API allows them to, but sometimes this is just not the case.

Fixing broken userspace apps with kernel hacking is not something that anybody wants, (Linus screamed to the heavens about this many times).
Comment 13 Daniel Vetter 2013-04-11 11:57:27 UTC
Case matters for connector properties, so "Broadcast RGB", not "BROADCAST RGB". Also, the value you spec needs to again match one on the list exactly.
Comment 14 Ivan Bulatovic 2013-04-11 13:14:34 UTC
That was it Daniel, thanks :)
Comment 15 Daniel Vetter 2013-04-12 08:36:33 UTC
Ok, I think everything is working as intended then and I think this is about as good as we can make it giving broken hardware. I'll hence close this as wontfix,

Thanks a lot for reporting this issue.
Comment 16 Tom Yan 2014-06-21 10:42:55 UTC
"Premature optimization is the root of all evil."

Isn't limited color range for ancient cheap monitor/tv? When/Why the hell it would be default to CE modes? Aren't tons of common modes are CE modes?

Yeah it isn't about TV vs Monitor, coz I got a Panasonic HDTV with HDMI and an EIZO monitor with DP, both of damn high quality, still I become "a victim of sloppy/cheap tv/monitor".

Screw that dummy "Automatic" option.

While it's in the kms driver there should be at least a kernel param to disable it. What should I do when Wayland comes?
Comment 17 Tom Yan 2014-09-27 13:53:03 UTC
Most stupid thing is assume all hdmi or displayport monitors should use limited range, which if the vendor actually implement it is awfully insane.

Don't take out that cea "standard" please, it doesn't told people to use a more precise pixel clock.
Comment 18 Tom Yan 2014-09-27 14:00:47 UTC
Also even switching to Full doesn't make the color show as good as with nvidia. Honestly I have no idea why i915 can be so screwed up. Even Catalyst can have a chance to compete.

Note You need to log in before you can comment on or make changes to this bug.