On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner <aplattner@xxxxxxxxxx> wrote: > 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. Yeah, I've read through that least and realized that for open-source drivers we have a different reality. And we do sometimes get bug reports from userspace guys complaining about the mismatch between the standard (followed by you guys) and the "evolved" standard (I know, lipstick on a pig) used by all the open-source drivers. My thinking behind putting this in the kernel is that current X open-source drivers just pass properties through (mostly) and that other compositors like wayland (or gralloc/hw_composer) would have one place to reference. Dunno what to do. -Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
