Re: [PATCH] fbdev: fix the fb_find_nearest_mode() function

["Antonino A. Daplas" <adaplas@gmail.com>]

Michal Januszewski wrote:
> 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).

Ok.

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

No, it's not wrong. But it is preferrable to have a nonzero value in
var->pixclock (whether calculated or via a VBE function call).

Still, I agree with you to initialize mode->refresh to zero (or perhaps
-1 to to denote a divide by zero) for these cases.

Tony
 



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl