Re: Some questions

[Thomas Winischhofer <thomas@winischhofer.net>]

James Simmons wrote:
>>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