On Mon, Oct 10, 2005 at 04:21:51PM +0800, Antonino A. Daplas wrote:

> > diff -Nurp fbdev-orig/drivers/video/modedb.c fbdev/drivers/video/modedb.c
> > --- fbdev-orig/drivers/video/modedb.c	2005-10-08 23:14:29.000000000 +0200
> > +++ fbdev/drivers/video/modedb.c	2005-10-09 01:25:16.000000000 +0200
> > @@ -663,6 +663,7 @@ void fb_var_to_videomode(struct fb_video
> >  {
> >  	u32 pixclock, hfreq, htotal, vtotal;
> >  
> > +	mode->refresh = 0;
> 
> Any reason why you need to set mode->refresh to 0?

This is something I had to use in a driver I'm currently working on and
I thought it might be a good idea to include it in the patch I sent.

The thing is, if the var struct has the pixclock field set to 0,
mode->refresh is left untouched, which could mean that it's either
set to a random value or to an invalid refresh rate coming from a
previously processed videomode (in case the fb_videomode struct is
reused).

I actually dealt with modes with var->pixclock == 0, and it always resulted
in a getting U:<xres>x<yres>-<random> in /sys/class/graphics/fb0/modes.

In case you're wondering why would anyone ever need to have
var->pixclock set to 0 -- I was using it to denote modes with a default
refresh rate set by the hardware (well, the Video BIOS to be more
specific). Please let me know is this is very wrong, but I just didn't
see any other way of doing it.

-- 
Michal Januszewski                                Gentoo Linux Developer
cell: +48504917690                         http://dev.gentoo.org/~spock/
JID: spock@im.gentoo.org               freenode: #gentoo-dev, #gentoo-pl