Geert Uytterhoeven wrote:

Panning state is not unknown. It's in var.

I don't think it is not always in var.
I found there are following three types of drivers.

1. ideal(?) driver
FBIOPUT_VSCREENINFO: pan (rounded a_set_varnd) done, no error, pan in returned var
FBIOGET_VSCREENINFO: returns pan

2. driver which doesn't provide own check_var (fixed mode drivers)
FBIOPUT_VSCREENINFO: no pan done, no error, false pan in returned var
FBIOGET_VSCREENINFO: returns pan

3. driver which doesn't provede pan_display nor check pan in check_var
FBIOPUT_VSCREENINFO: no pan done, no error, false pan in returned var
FBIOGET_VSCREENINFO: returns false pan

2 will be trouble if people expect they can initialize pan by
FBIOPUT_VSCREENINFO. Actually, you need FBIOPAN_DISPLAY afterwards.
Or when they believe returned var have valid value for pan.
Actually, you need FBIOGET_VSCREENINFO (anyway, you need FBIOPAN_DISPLAY as
 described above, this one is not so big problem).

3 is weired. info->var continuously have value which can not be set to HW.
Many drivers which doesn't support pan seems to be this type
(sstfb is one of exceptions).
Possibly, we can fix it at the middle of fb_set_var().
But because of the rule(?) that only *_check_var() can freely modify var, 
In this case, *_check_var() in each driver should do return error, or set
 them 0. Right?

If you don't know the pixclock, set it to 0.

OK. Thank you.
/yoshii


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/