Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's

[Antonino Daplas]

On Tue, 2003-01-07 at 06:27, James Simmons wrote:

> 
> > This approach has one major problem though.  In the 2.4 interface, we
> > have fbset that basically "assists" fbdev with the changes.  The fbset
> > utility will fill up fb_var_screeninfo with correct information such as
> > video timings from /etc/fb.modes.  
> 
> I neved like the idea of fb.modes. We should be asking the hardware are 
> selves instead.Yes there are cases of really old hardware that lack this. 
> I think the below code will be usefull for these cases.
>  
That's true.  The VBEInfoBlock struct contains a far pointer to a list
of video modes supported, standard VESA DMT modes and OEM-specific
modes.  This is function 0x4F00 of VBE which unfortunately is accessible
only in 16-bit mode.  Maybe the EDID block also contains such
information?

Also, if the user wants to control the refresh rate, or use nonstandard
video modes, there's no choice but to have the timings generated even
for new hardware.  That's where the GTF is useful.

> > So, what's needed is a function that calculates timing parameters which
> > is generic enough to work with the most common monitors.  One solution
> > is to use VESA's GTF (Generalized Timing Formula).  Attached is a patch
> > that implements the formula.
> 
> Great!!!!
> 
> > The timings generated by GTF are different from the standard VESA
> > timings (DMT).  However, it should work for GTF compliant monitors and
> > is also specifically formulated to work with older monitors as well. 
> > Another advantage is that it can calculate the timings for any video
> > mode. It may not work for proprietary displays or TV displays.
> > 
> > One requirement of the GTF is that the monitor specs must be known, ie
> > info->monspecs must be valid.  This can be filled up several ways:
> > 
> > 1. VBE/DDC and EDID parsing (I see the beginnings of it already in
> > fbmon.c)
> 
> Yeap. We can parse the EDID block for data about the limits of your 
> monitor!!! 
> 
> > 2. entered as a boot/module option
> 
> Yuck! But I don't see much of a choose for modular drivers.

We do need to have the monitor's operational limits uploaded whatever
way and as early as possible so the user can boot to a high resolution
immediately.  Using VBE/DDC and parsing the EDID block may not work with
new, but cheap monitors.  I have one such monitor that is supposed to
support DDC2 but spits out a useless EDID block.  So passing it as a
boot option may be useful.  This is similar to XFree86 falling back to
/etc/X11/XF86Config's 'HorizSync' and 'VertRefresh' when the EDID info
is not available.

>  
> > 3. ?ioctl to upload monitor info to fbdev.
> > 
> > (As a side note, should we also add pixclock_min and pixclock_max to
> > info->monspecs?).
> 
> ioctl already exist for this. The only issue is fb_monspec good enough for 
> our needs.
> 
What's the ioctl by the way?

The GTF only requires xres, yres and one of the three:

horizontal scan rate
vertical refresh rate
pixelclock.

in order to generate timings. So adding minimum and maximum pixelclock
fields in info->monspecs will be useful.  Otherwise the GTF may generate
a pixelclock that is outside the graphics card's/monitor's capability. 

Secondly, the GTF function assumes the following:

hsync_len = 8% of htotal
left_margin = 1/2 of inactive frame length
right margin = remainder of htotal

vsync_len = 3
lower_margin = 1
upper margin = remainder of vtotal.

Anyway, the most critical part when computing timings information is the
inactive frame length (htotal - xres, vtotal - yres), which is hblank
and vblank in the fb_get_mode() function.

Finally, some of the fixed numbers I used in the GTF function is
supposedly for a monitor with US specifications:

#define FLYBACK                     550
#define V_FRONTPORCH                1
#define H_OFFSET                    40
#define H_SCALEFACTOR               20
#define H_BLANKSCALE                128
#define H_GRADIENT                  600

I'm not even sure about the meaning of some of them :-). We can add them
in the future if the above assumptions need to be changed.

Tony

PS:  The GTF patch is erroneous.  hfmin and hfmax must be in Hz and the 
boolean logic is incorrect.

diff -Naur linux-2.5.54/drivers/video/modedb.c linux/drivers/video/modedb.c
--- linux-2.5.54/drivers/video/modedb.c	2003-01-06 13:34:50.000000000 +0000
+++ linux/drivers/video/modedb.c	2003-01-07 03:29:59.000000000 +0000
@@ -547,10 +547,10 @@
 	 * If monspecs are invalid, use values that are enough
 	 * for 640x480@60
 	 */
-	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
 	    info->monspecs.hfmax < info->monspecs.hfmin ||
 	    info->monspecs.vfmax < info->monspecs.vfmin) {
-		hfmin = 29; hfmax = 30;
+		hfmin = 29000; hfmax = 30000;
 		vfmin = 60; vfmax = 60;
 	} else {
 		hfmin = info->monspecs.hfmin;
@@ -628,10 +628,10 @@
 	 * If monspecs are invalid, use values that are enough
 	 * for 640x480@60
 	 */
-	if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+	if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
 	    info->monspecs.hfmax < info->monspecs.hfmin ||
 	    info->monspecs.vfmax < info->monspecs.vfmin) {
-		hfmin = 29; hfmax = 30;
+		hfmin = 29000; hfmax = 30000;
 		vfmin = 60; vfmax = 60;
 	} else {
 		hfmin = info->monspecs.hfmin;