Do not display the screensaver

[Cui, Hunk]

Hi, Jackson & Behrmann,

	What is mean about the server's internal representation is abstracted away from the driver's representation? I don't understand it. Can you particular explain it. I know the R,G,B originality values are 16 bits per channel. When the values are transfered to the driver layer, they will be dealed with through "val = (*red << 8) | *green | (*blue>>8);" because the "val" will be writen into Gamma correction RAM register (the type of hardware register: Each of the entries are made up of corrections for R/G/B. Within the DWORD, the red correction is in b[23:16], green in b[15:8] and blue in b[7:0]).
	Why the driver is allowed to truncate? And why not be transfered by R/G/B former values. Can you know that?

BTW: Behrmann, "Three one dimensional look up tables (LUT) each of 8-bit resolution would not make much sense in this scenario." Please particular explain it. Thank you for your earnest reply.

Thanks,
Hunk Cui

-----Original Message-----
From: Adam Jackson [mailto:ajax at nwnk.net] 
Sent: Wednesday, May 19, 2010 10:45 PM
To: Cui, Hunk
Cc: xorg-devel at lists.x.org
Subject: RE: Do not display the screensaver

On Wed, 2010-05-19 at 19:01 +0800, Cui, Hunk wrote:
> Hi, Jackson,
> 	First thanks for your explanation, through the debugging, I found
> when I start the "fade to black", the gamma values will be setup to
> the default value (1.0), it will be transferred to the XServer. And in
> XServer, the value will be write into the VidModeSetGamma ->
> xf86ChangeGamma -> xf86RandR12ChangeGamma -> gamma_to_ramp (calculate
> the RGB values) -> RRCrtcGammaSet. Now I have some difficulty. In
> gamma_to_ramp step, I found the type of ramp value is CARD16. Why is
> not the CARD8? For R,G,B values, it only have 256bytes RAM.

X color specifications are 16 bits per channel.  If your gamma ramp is
less precise than that, your driver is allowed to truncate, but the
server's internal representation is abstracted away from the driver's
representation.

- ajax