Do not display the screensaver

[Cui, Hunk]

Hi, All,
	Through communication with you, I have a certain understanding of this Gamma correction RAM (PAR & PDR registers) principle.
	Now I use the ddd tools to debugging the xscreensaver-xserver, when I debug the server (about Get Gamma Ramp), The function: "xf86GetGammaRamp -> RRCrtcGammaGet -> xf86RandR12CrtcGetGamma" please see below:

The first line:
xf86CrtcPtr crtc = randr_crtc->devPrivate;

After run upper line,
crtc->gamma_red, crtc->gamma_green, crtc->gamma_blue tables have been loaded into the Gamma Correction values

Now I want to ask everyone, In what is the definition about the " randr_crtc->devPrivate ", where the values are arise in?

[Cui, Hunk] The randr_crtc->devPrivate->gamma_red / randr_crtc->devPrivate->gamma_green / randr_crtc->devPrivate->gamma_blue are initialized in "xf86InitialConfiguration -> xf86CrtcSetInitialGamma" function, is it?

Thanks,
Hunk Cui

-----Original Message-----
From: yangman at gmail.com [mailto:yangman at gmail.com] On Behalf Of Yang Zhao
Sent: Thursday, May 20, 2010 12:39 PM
To: Cui, Hunk
Cc: xorg-devel at lists.x.org
Subject: Re: Do not display the screensaver

On 19 May 2010 21:03, Cui, Hunk <Hunk.Cui at amd.com> wrote:
>        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.

The term "gamma" in this discussion is actually misleading: all the
gamma-related calls, as they are currently implemented, eventually
results in writes to the hardware LUT which translates pixel values to
actual electrical output values. "Gamma correction" is just one of the
things you can do by modifying the values in the table.

The precision of the LUT depends on the hardware. Radeons, for
example, have 10 bits of precision per channel. CARD16 is an
appropriate upper bound for the range of precisions that will
realistically be in use.  Also keep in mind that these LUTs were used
primarily to drive analog outputs not too long ago, which have much,
much higher precisions than their digital counter parts.

A client makes a "gamma correction" call, server generates a new LUT
with 16 bits of precision per channel, then the driver takes this and
truncates to whatever precision the hardware can actually take.


-- 
Yang Zhao
http://yangman.ca