[Openchrome-users] xgamma enabled

[Luc Verhaegen]

On Thu, Dec 07, 2006 at 02:12:11PM +0100, Benno Schulenberg wrote:
> 
> I've tried Luc's driver, an old checkout still  lying about
> (git SHA-ID: commit e9b86eb9b481161aaf11c2b5070435b95c8ec6bf),
> and indeed, it works marvellously there, 'xgamma -gamma 0.5', 
> 'xgamma -gamma 1.5', ...  Nice.
> 
> But with the latest checkout
> (git SHA-ID: commit 840a2d30554b8298806f8c642dd83b0ab62246be),
> ... xgamma probably still works, I didn't even try, because all the 
> lettering got about 50% bigger, the horizontal sync dropped from 85 
> to 75 Hz and made the display shift a centimetre to the right -- I 
> quickly moved away from that, back to svn 249.
> 
dpi is currently locked down at 100. This is due to me having replaced 
X's mode validation entirely, mode validation which depended on the EDID 
of the CRT for dpi, not caring about panel or TV hooked off the same 
CRTC. I will honour X's configured dpi soon, when i'm done implementing 
dualhead (at this point i'm able to have each head working on its own) 
and randr++, the latter will hopefully offer dynamic adjustment of dpi.

85Hz to 75Hz i would consider a regression, but i somehow feel that all 
you intended to do here was bash my code. But guess what you're already 
largely depending on now, and with gamma now, that dependency only seems 
to grow.

I would be most happy to get a log and find out why, with your monitor, 
75Hz is chosen. You might want to try putting "<HDisplay>x<VDisplay>@85" 
in the modes directive of the display section, at which point the driver 
will use CVT to generate just that mode (as @85 will not match a 
built-in mode, but will trigger generation). If that fails to give you 
85Hz, then something must be stopping the driver from accepting that, as 
the driver has no problem chosing the right modes here.

The shift in position is due to a different modeline having been chosen. 

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