Dithering, how to disable
Hi, It seems that Lenovo doesn't really believe in the concept of truth in marketing. The panel advertised as 24-bit is actually 18-bit (they claim 16.7 M colors, not 16.2 M or the actual 262 k). To compensate, there is some dithering involved, and seems to give an effect most people describe as "sparkling". This grainy, or sparkly, appearance is a bit annoying and might be the reason why I perceive this display as straining. So I'd like to disable it and see if that makes me a happy camper. I've been fiddling with the register LVTMA_BIT_DEPTH_CONTROL, disabling the relevant dither bits there. That does indeed remove so much of the dithering that you can start seeing the banding caused by the 18-bit truncation. Unfortunately, the display is still grainy, so something is still active. So my question is if there are more things I can tweak or if the remaining issue is just a property of the matrix. TMDSA_BIT_DEPTH_CONTROL seems to be just for TMDS (which is just for DVI?), but there's also a DVOA_BIT_DEPTH_CONTROL which I'm unsure where it fits in. Grateful for any help. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Pierre, Le jeudi 01 novembre 2007, Pierre Ossman a écrit :
It seems that Lenovo doesn't really believe in the concept of truth in marketing. The panel advertised as 24-bit is actually 18-bit (they claim 16.7 M colors, not 16.2 M or the actual 262 k). To compensate, there is some dithering involved, and seems to give an effect most people describe as "sparkling".
This grainy, or sparkly, appearance is a bit annoying and might be the reason why I perceive this display as straining. So I'd like to disable it and see if that makes me a happy camper.
I've been fiddling with the register LVTMA_BIT_DEPTH_CONTROL, disabling the relevant dither bits there. That does indeed remove so much of the dithering that you can start seeing the banding caused by the 18-bit truncation. Unfortunately, the display is still grainy, so something is still active.
Can't you just set the radeonhd driver to 15-bit or 16-bit depth mode? -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Thu, 1 Nov 2007 12:03:50 +0100 Jean Delvare <jdelvare@suse.de> wrote:
Can't you just set the radeonhd driver to 15-bit or 16-bit depth mode?
Can't say that it made much of a difference. The graininess is still there. :/ Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Thu, Nov 01, 2007 at 09:22:22AM +0100, Pierre Ossman wrote:
Hi,
It seems that Lenovo doesn't really believe in the concept of truth in marketing. The panel advertised as 24-bit is actually 18-bit (they claim 16.7 M colors, not 16.2 M or the actual 262 k). To compensate, there is some dithering involved, and seems to give an effect most people describe as "sparkling".
Could it be that it really is a 24bit panel and that, since we do not know any better, we set it up as an 18bit panel and it still works? When i'm back in the office; i should probably try to set up the hp laptop as 24bits. This laptop is a mobility r5xx, 1680x1050, so i was initially quite surprised to see that it was only an 18bit panel. Iirc, i attempted to drive it differently, without success, but this was in the hectic days right before XDS.
This grainy, or sparkly, appearance is a bit annoying and might be the reason why I perceive this display as straining. So I'd like to disable it and see if that makes me a happy camper.
I've been fiddling with the register LVTMA_BIT_DEPTH_CONTROL, disabling the relevant dither bits there. That does indeed remove so much of the dithering that you can start seeing the banding caused by the 18-bit truncation. Unfortunately, the display is still grainy, so something is still active.
Please describe what you mean by grainy? Could there be something else going on besides dithering? I hope it is not something as straightforward as adjusting gamma.
So my question is if there are more things I can tweak or if the remaining issue is just a property of the matrix. TMDSA_BIT_DEPTH_CONTROL seems to be just for TMDS (which is just for DVI?), but there's also a DVOA_BIT_DEPTH_CONTROL which I'm unsure where it fits in.
These are both for seperate outputs and will not influence your panel. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Fri, 2 Nov 2007 10:56:19 +0100 Luc Verhaegen <libv@skynet.be> wrote:
Could it be that it really is a 24bit panel and that, since we do not know any better, we set it up as an 18bit panel and it still works? When i'm back in the office; i should probably try to set up the hp laptop as 24bits. This laptop is a mobility r5xx, 1680x1050, so i was initially quite surprised to see that it was only an 18bit panel. Iirc, i attempted to drive it differently, without success, but this was in the hectic days right before XDS.
Great. Let me know how at goes, and if there is anything I can test here.
Please describe what you mean by grainy? Could there be something else going on besides dithering? I hope it is not something as straightforward as adjusting gamma.
A solid white (3 x 0xff) does not give a solid color or brightness. It looks almost identical to a panel covered in dust. I had a chat with Lenovo and they couldn't tell me of any known issues (despite the fact that you can find lots of forum posts where people have experienced recent thinkpads having this issue). They speculated that it might be a backlight effect where it doesn't give a proper, constant light. I'm sceptical though as the variation is on a pixel scale, and I would suspect an uneven backlight spread would give larger fluctuations. (They also don't consider this problem big enough to warrant a repair, so I'm stuck with solving it myself or trying to return the machine) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Jean Delvare -
Luc Verhaegen -
Pierre Ossman