Mailinglist Archive: radeonhd (265 mails)

["Yang Zhao" <yang@xxxxxxxxxx>]

2009/1/9 Matthias Hopf <mhopf@xxxxxxx>:
> On Jan 07, 09 11:33:57 -0800, Yang Zhao wrote:
> > 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*.
>
> So the same API function is used with different semantics. Which can
> never work. How come that this is not hitting other drivers and/or users
> - or is it hitting them, and they are just in a minority, thus
> overlooked by the X community?

radeon assumes 8-bit precision, and does masking to make sure there's
no overflow. I haven't looked at xf86-video-intel, but I'd assume it
has something similar to match the hardware. There was no masking
happening in radeonhd, which, in hind-sight was a blessing or no one
would have noticed anything wrong.

I suppose because XV86VidMode functions still takes paletted colour in
to account, and RRSetCrtcGamma doesn't, they're not equivalent. Colour
calibration is really the only time fine-control over gamma ramps is
needed, so the latter wouldn't be something that gets used in a lot of
apps.



> Please continue to tell us your findings. It's really interesting,
> especially as almost nobody understands this subsystem well enough.

RandR seems to store an internal copy of the gamma ramp when
RRSetCrtcGamma() is called, so RRGetCrtcGamma() would always correctly
return what the last input ramp is. I haven't verified this with an
external app, but there doesn't seem to be much else that needs to be
done for true colour modes.

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