Mailinglist Archive: radeonhd (265 mails)

[Marcel de Boer <marceldb@xxxxxxxx>]

Hi!

> Yes, i implemented gamma setting has been supported in late august or
> early september.

Many thanks! I went out and bought a HD2600 Pro, only to discover that the
RandR calls that I need to use for setting the gamma are not supported
by xcalib yet, so when I try to use xgamma or xcalib to load the gamma
tables, both of my screens still get the same gamma table loaded... (They
only see one Xinerama screen, apparently RandR does a lower level division
of the screens.)

I managed to hack up a version of xcalib that uses the RandR gamma calls,
which work for both screens independently, but I've still got a small
question about it: the RandR calls need the gamma table entries as three
lists of unsigned short values, but I found out that the most significant
byte of these values isn't used at all, leaving only a quite meagre 8 bits
for the value. Do you know if this could be a driver or driver <-> X
interface issue (as far as I could see from the driver sources, the card
has 10 bits available for each value) or if this could be a problem in the
implementation of these functions in RandR? (I found surprisingly little
information about XRRSetCrtcGamma and how it should be used.)

If a card doesn't support all 16 bits that are sent by XRRSetCrtcGamma, I
would expect that (for instance) the most significant 10 bits get used and
the least significant get dropped, otherwise a program setting the gamma
tables would first have to find out how many bits can be used, but as far
as I know, that information is not available...

Gtnx
        Marcel
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx