Re: Some questions

James Simmons wrote:

quoted

However, the brokenness is really on the driver side.  They are unable
to change the video mode unless they are supplied with the correct
timing parameters where in fact they actually have the best knowledge on
how to calculate them. 

So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
we let the drivers calculate it for themselves?  I go for the latter, as
fbcon really should not have any business with hardware.

I agree.

Me Too(tm). SiSfb (sorry for mentioning this one over and over, but that's the only one I am working on) does that now, according to the following assumptions:

If old_x == new_x && old_y == new_y && old_clock == new_clock

	-> assume a change in depth, hence recalculate the clock
	based on the htotal and vtotal values (which are calculated
	using var's horizontal and vertical timing.

else if (old_x != new_x || old_y != new_y) && old_clock == new_clock

	-> assume a mode change originating from fbcon_resize (where
	only xres and yres are changed, everything else left unchanged; 	 hence, use the default clock (user selectable) because clock is
	invalid.

else if(timings are valid)

	-> use these timings, they originate from an application
	using the framebuffer device properly (directFB, for instance)

else -> use default clock

Works perfectly. Tested all possible applications (mplayer, sdl stuff, etc), no problems.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en