[Openchrome-users] Another try with xgamma (was: xgamma enabled)

[Luc Verhaegen]

On Tue, Dec 12, 2006 at 11:49:50AM -0300, Gonzalo A. de la Vega wrote:
>
> The comment is back... credits too. Sorry, I must have deleted it in a
> commented code deleting frenzy.
> 
> OK, now I have it tested on K8K800 and KM400 both 24 and 16bpp. The locking
> is caused when writing the IGA2 lut, so that's not done for CLE266 and
> KM400... SAMM is not working anyway right?
> Unichrome driver also locks up if USE_SECONDARY is defined. Apparently VIA's
> driver has not been tested on these two chips.
> 
> -----------------------------------
> Gonzalo A. de la Vega

If you access the secondary LUT, without secondary enabled, you 
hardlock. Not sure why that is necessary, but that's the unichrome for 
you.

USE_SECONDARY was perfectly ok when i was using it, in fact, i'm 
currently writing this mail while using secondary. And i did some quite 
extensive testing on CLE266Ax (couldn't get the colour ordering over 
DVP0 right) and VT7205. Did you do a complete rebuild?

My modesetting code included in openchrome doesn't do secondary, it's 
just not wired up, there's quite a lot involved for secondary to work 
decently. But with VBE you have no control over which you use. Panel 
usually sits on secondary, gets you scaling and dithering.

Why do you check for HasSecondary there? Is this variable updated after 
a mode has been set through VBE? Just check CR6A.7, that way you don't 
need to check for VT3122 or VT7205 either.

I have no idea why you're using 7bits though, the unichrome only allows 
6 or 8. If X really produces 7 bits spaced over 0x100 colors, you 
probably just end up writing each triplet twice.

Please do include the copyright statement when you copy, the actual 
license is of course the same.

Luc Verhaegen.
http://unichrome.sf.net/