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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
