Mailinglist Archive: radeonhd (265 mails)

["Yang Zhao" <yang@xxxxxxxxxx>]

2009/1/7 Matthias Hopf <mhopf@xxxxxxx>:
> On Jan 05, 09 09:30:06 -0800, Yang Zhao wrote:
> > ...only
> > RandR's gamma hooks were causing issues.
>
> AFAICS, RandR's gamma hook only deals with 256-Entry tables - could
> *that* be an issue?

The 256-entry limit seems perfectly reasonable to me: that's what
checking RRGetCrtcGammaSize() is for.

The issue is that RRSetCrtcGammaRamp() is connected directly to
LUTxSet(), which doesn't do any data sanitization of its own, and
simply write to the registers. This is fine for XF86VidMode* where
truncation is done before reaching DDX code, but fails via RandR when
16-bit values that are assumed to be shorter end up being shifted and
ORed together. Simple matter of doing some shifting as CARD16* ramps
are packed into LOCO*.

This is also why I initially added truncation heuristic to LUTxSet(),
which turned out to be the wrong solution.


> > Assuming 16-bit precision for the RandR gamma calls seems to be
> > working fine so far, but RRCrtcGetGamma doesn't seem to be hooked up.
> > Currently, gnome-screensaver is destroying the user set gamma ramp
> > going in and out of screen saver, but I haven't verified whether or
> > not the fix for this is in a release. I'm not seeing any code for it
> > in radeonhd, though, and haven't managed to find how/if this can be
> > done in the first place.
>
> Good luck. As I said I have zero to no knowledge about this, and Luc
> told me yesterday that this is approximately the only place in X where
> he's actually scared of ;-)

Encouraging. ;)

Well, I gotta scratch this itch one way or another.

-- 
Yang Zhao
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx