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.
Thanks in advance,
jhs
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.
Cheers, Daniel
2013/5/20 Daniel Vetter daniel@ffwll.ch
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.
Cheers, Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Ok, thank you for your detailed explanation.
Regards, jhs
Hi,
2013/5/20 Daniel Vetter <daniel <at> ffwll.ch> 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. Cheers, Daniel-- Daniel Vetter Software Engineer, Intel Corporation+41 (0) 79 365 57 48 -
Does this mean the system is doing RGB full range to limited range compression on the raw RGB data it receives from an application?
Ie a video player that want to be able to handle blacker than black properly will need to force the GPU into fullrange output to avoid the driver internal compression of the signal and handle that itself?
/Joakim
On Wed, May 22, 2013 at 6:08 PM, Joakim Plate elupus@ecce.se wrote:
2013/5/20 Daniel Vetter <daniel <at> ffwll.ch> 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. Cheers, Daniel-- Daniel Vetter Software Engineer, Intel Corporation+41 (0) 79 365 57 48 -
Does this mean the system is doing RGB full range to limited range compression on the raw RGB data it receives from an application?
Ie a video player that want to be able to handle blacker than black properly will need to force the GPU into fullrange output to avoid the driver internal compression of the signal and handle that itself?
At least on the display I've seen limited range indeed seems to indeed clamp and full white/black. But ofc if your media player already outputs limited range, then you need to disable the gpu side ranger compression. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
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
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
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
On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner aplattner@nvidia.com 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
On Mon, Jun 3, 2013 at 4:03 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner aplattner@nvidia.com 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.
We standardized on the scaler KMS connector properties, but the randr ones are still device specific for compatibility reasons. Also, things like the scaler are generally actually crtc properties rather than connector properties, but randr and KMS don't really have the same display object abstractions.
Alex
dri-devel@lists.freedesktop.org
-
Aaron Plattner -
Alex Deucher -
Daniel Vetter -
Jan Hinnerk Stosch -
Joakim Plate