On 06/03/2013 12:36 PM, Daniel Vetter wrote: > On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote: >> On 05/20/2013 02:55 PM, Daniel Vetter wrote: >>> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote: >>>> Hallo, >>>> >>>> I hope this is the right place to ask, because I actually don't know >>>> whether it is a bug or a feature that I'm experiencing since linux 3.9: >>>> When I boot my system the backlight gets extremely bright compared to older >>>> kernel versions. It is most obvious when I leave X (more a yellow than a >>>> black background), but I have the impression, that the colors in X are >>>> brighter than usual, too. >>>> I used my spare time this afternoon to do a kernel bisect and learned that >>>> the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I >>>> don't have insight or understanding of the code: Is this behaviour intended >>>> and how could I change it to the old state or is it a bug and should I >>>> report it somewhere? >>>> My system is as follows: >>>> Intel i5-3570k with Intel HD 4000 >>>> my monitor is connected via HDMI. >>>> If you need any more information just tell me. >>> >>> Yeah, this is a feature. HDMI has (for oddball backwards compat with >>> analog TV signals) a special mode which reduces the useable RGB value >>> range by chopping off about 10% at the bottom and top end. This results in >>> light colors getting brighter and dark colors getting darker. >>> >>> The above mentioned commit tries (to the best of our knowledge) to >>> auto-set the option which most likely fits what the hdmi sink will do with >>> the color data. You can either fix this up in the hdmi sink with the >>> on-screen menu or by manually setting the "RBG Broadcast" property for the >>> relevant hdmi connector to the setting you want. >> >> This property seems like it's generally useful for all GPUs that >> support range compression. Has anyone started the process of adding >> it to randrproto.txt as an official property? >> >> http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n1723 > > Oops, I didn't know that we have some properties standardized there, > especially since the existing pile of drm/kms drivers seem to only lously > follow them. Should we move this into the kernel since that's essentially > the place that defines them?
Maybe? I think I'm the only one who even tries to follow those, so "SHOULD" and "MUST" don't really mean a whole lot right now. One option would be to just abandon the idea of standardizing properties, but I do think standardization is good. Where that standard should live, though, is a another question. The kernel doesn't seem like the right place since RandR properties are useful on lots of platforms other than Linux. > -Daniel -- Aaron
