|
From: Antonino D. <ad...@po...> - 2003-03-06 10:04:17
|
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 |