Re: Some questions

[Antonino Daplas <adaplas@pol.net>]

On Thu, 2003-03-06 at 17:43, Thomas Winischhofer wrote:
> > Mode checking is not simply looking at xres and yres, but also looking
> > at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> > then compared to the monitor/graphics card's capability.  If any of the
> > values fall outside the limits then the mode is not valid.  Otherwise,
> > the new mode should still produce a usable display, perhaps not the one
> > the user wants (ie refresh rate is lower).  By this time though, the
> > user can freely use fbset to fine tune all the timings.
> 
> Perhaps I have not made myself clear:
> 
> I start with a default 800x600-60. Pixelclock in var is now X.
> 
> fbcon_resize adapts the xres and yres, leaving the pixelclock alone.
> 
> The driver sees upon the check_var call: xres, yres and X - the old 
> pixelclock (which is non-zero).
> 
> That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
> no way of distinguishing!
> 

Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
calculate hsync and vsync.  Compare this with your monitor's limit -- if
any fall outside, the entire mode, pixelclock and all is not valid.

(see fb_get_mode() and fb_validate_mode() in fbmon.c)

And if you use very narrow vsync and hsync ranges, then the "stale"
pixelclock will always most certainly be invalid.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com