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@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org