Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
> fbcon_resize() is not that broken, it's only trying to do what it's
> supposed to do.  It is indeed limited because it is trying to outguess
> the low-level drivers on the best resolution for a window size.
> 
> 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.  

Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
requires at least x and y dimension AND A CLOCK (or a vertical refresh 
rate, which I would prefer).

The driver is supposed to handle the "var"s it's fed. If that var is 
like the ones that result from the current fbcon_resize, namely with a 
new x and y res, but no valid clock, how on earth should the driver do 
this then? It receives a var which looks correct, and in fact, *could* 
be correct sometimes:

Suppose we have another application, say DirectFB, feeding the low level 
drivers with complete and correct "var"s.

In both cases we have valid x any y resultions, and a non-zero clock field.

Should we then let the driver read the x and y resolution and forget 
about the rest of that var? I hardly think that's what the public var is 
for. It could be reduced to a struct { USHORT xres, USHORT yres } then.

> 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.

What about the following solution: What if fbcon_resize sets the clock 
in the var to 0? We could use this to force low level drivers to decide 
on the clock for themselves. Otherwise, ie if the clock field is 
non-zero, they are supposed to take it as the desired clock.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/