enhanced color depth over dual-link dvi
I'm trying to use a dlp light engine from a Mitsubishi hdtv as a pc monitor by driving it directly with dvi from a hd2400xt. I removed the orginal TV electronics, which crashed from time to time with a blue screen. It was not difficult to get a picture, only the color space is not correct. After gamma correction, the display is too bright, leading to some saturation, and the lower order color bits seem to be lost. I'm guessing it is expecting to see greater than 24 bit color, using dual link for this instead of higher resolution. This would make sense if the contrast ratio is high enough to use it. It does use a dual link cable. The 2 bit TMDSA_COLOR_FORMAT field from [GpuF0MMReg:0x7888] of the rv630 seems to refer to using the secondary TMDS channels to transmit the extra bits: TMDSA_COLOR_FORMAT - RW - 32 bits - [GpuF0MMReg:0x7888] Field Name Bits Default ... TMDSA_COLOR_FORMAT 1:0 0x0 Description Controls TMDSA output colour format. Formats 0 and 1 work in single or dual link. Format 2 requires dual link (MSBs on primary link, LSBs on secondary link). 0=Normal (24bpp), Twin-Single 30bpp (8 MSBs of each component), or Dual-Link 48bpp 1=Twin-Link 30bpp (2 LSB of each component) 2=Dual-Link 30bpp 3=Reserved And the "Avivo Display Engine Whitepaper" seems to refer to this capability: " 10-bit and 16-bit DVI output The main benefit of higher color depth is borne by the fact that higher depth means more data per color component or larger color space. For example 10-bits per color offers 64 times more colors than 8-bits (1.07 billion colors), while 16-bits per color lets you experience over 16 million times more colors than 8-bits, for a total of over 280 trillion colors. Therefore, while most LCD panels today are using either 6-bits or 8-bits per color, a migration to 10-bit and higher LCD panels has begun. Presently, there are several generally-available PC displays capable of 10-bits and 16-bits per color, and more such high-end displays are expected to be offered from display vendors going forwards, as they will be able to count on having display sources to drive their higher color depth displays, since the Avivo Display Engine supports both 10-bits and 16-bits per color outputs over dual-link DVI interfaces. Moreover, many DTVs are starting to offer built-in 10-bit support, which along with Avivo’s 10-bit high-fidelity digital output would enable an end-to-end 10-bit pipeline from PC source to DTV, providing the best possible image fidelity possible. " How difficult would it be to modify the radeonhd driver to try to enable this? I don't know for sure that the light engine expects the same formats that AMD provides, even if it is using enhanced color depth with dual link, as well, although it should. Thanks, Andrew Shor -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jan 07, 10 14:45:42 -0500, Andrew Shor wrote:
most LCD panels today are using either 6-bits or 8-bits per color, a migration to 10-bit and higher LCD panels has begun. Presently, there are several generally-available PC displays capable of 10-bits and 16-bits per color, and more such high-end displays are expected to be
What you're referring to is called "Deep Color" - and AFAIR this has been added to the HDMI 1.3b spec. As DVI is physical layer compatible with HDMI, it should theoretically be transmitted over DVI as well. AFAIK there is some EDID information about whether the display supports Deep Color - that would have to be tested.
How difficult would it be to modify the radeonhd driver to try to enable this? I don't know for sure that the light engine expects the same formats that AMD provides, even if it is using enhanced color depth with dual link, as well, although it should.
As the format is standardized, it shouldn't be a problem. Lately the
Xserver (specifically libpixman) has been extended to be able to cope
with 10-10-10-2 bit visuals, so that should work as well - before that
change it would be close to impossible.
I think 10 bit per channel visuals haven't received a lot of testing -
I would doubt that only few applications crash :-]
Still it might work. 16 bits per channel are out of the question for
now, because AFAIK the server doesn't support color depths >32 bit.
The changes in radeonhd should be extensive, but rather easy to do I
guess, unless you're dealing with acceleration. You need to change
general setup, display setup, crtc programming, color table handling,
and acceleration.
We (Egbert and me) eventually wanted to add this as well, but never got
around to. Especially in the light of DisplayPort, which supports >8
bit per channel from day one (but we didn't even manage to get
DisplayPort running so far in radeonhd due to lack of time).
So any patches are very welcome!
Thanks
Matthias
--
Matthias Hopf
participants (2)
-
Andrew Shor
-
Matthias Hopf