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!
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.
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...
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 :(
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 !
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
(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.
(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 !
(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.
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
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...
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.
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).
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.
That was it Daniel, thanks :)
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.
"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?
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.
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.