From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonino Daplas Subject: Re: Some questions Date: 06 Mar 2003 18:05:37 +0800 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <1046945135.1209.76.camel@localhost.localdomain> References: <1046913411 .1206.185.camel@localhost.localdomain> <3E670B82.30900@winischhofer.net> <1046942633.1330.54.camel@localhost.localdomain> <3E671848.5020506@winischhofer.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Received: from pine.compass.com.ph ([202.70.96.37]) by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18qsEa-0004DM-00 for ; Thu, 06 Mar 2003 02:04:17 -0800 In-Reply-To: <3E671848.5020506@winischhofer.net> Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Thomas Winischhofer Cc: James Simmons , Linux Fbdev development list 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