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? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel