Hi,

quoted

Basic idea is, that when we have fixed mode devices (aka drivers which 
don't implement fb_check_var) we just simply fill in a "emulated" valid 
monitor/modeline into the var struct during the register_framebuffer() 
initialization call. Since the modeline is valid, X does not has any 
problems with it.

It works nicely, and simple. but,
IMHO, It is not bad for workaround, but not for merging into mainline.
If it is only for workaround, setting info->var->pixclock(and some others)
 in your driver, is simpler (assuming we have source code).

Generally, pixclock is 0 in purpose.
It means there really is no clock, or author didn't have enough HW spec.
Anyway, it indicate there is no information about pixclock.
I think nothing other than 0 is suitable for this, because 
this is T of clock, and T=0 is logically invalid (f=INF?).
.... I think.

If it is true as fbdev specification, that means applications must ignore
 timings when pixclock==0.
/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=/