Small HD 2600 gamma question
Hi! I've been looking around a bit for a new video card, and the HD 2600 Pro (AGP) seems like a good choice, especially with the reported support from ATI for open-source drivers. I'm not (yet) interested in much acceleration, but I do want to use the card for photo editing, so before I make a final decision, I'd like to know if this card has support for independent gamma tables for each display of a dual-head setup (so I can use the tuned calibrations for both of my monitors.) E.g. what happens if you give the following two commands: xgamma -s 0 -gamma 2 xgamma -s 1 -gamma 0.5 Does the first screen become lighter and the second one darker or does something else happen? This list may not be the right place to ask this, but this information is almost impossible to find anywhere, so the driver developers are probably the only people who know. Thank you very much in advance! Gtnx Marcel de Boer -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Yes, i implemented gamma setting has been supported in late august or early september. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Dec 16, 07 15:50:32 +0100, Luc Verhaegen wrote:
Yes, i implemented gamma setting has been supported in late august or early september.
He's asking about separate gamma per output. I don't know how this is
reflected in the driver - RandR has some driver interface, but apparently
no protocol interface for that, and for xinerama my knowledge is even
less accurate...
Matthias
--
Matthias Hopf
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
participants (3)
-
Luc Verhaegen
-
Marcel de Boer
-
Matthias Hopf