Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 6 Jan 2003 23:27:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 6 Jan 2003 23:27:15 -0500 Received: from willow.compass.com.ph ([202.70.96.38]:60420 "EHLO willow.compass.com.ph") by vger.kernel.org with ESMTP id ; Mon, 6 Jan 2003 23:27:13 -0500 Subject: Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size From: Antonino Daplas To: James Simmons Cc: Linux Fbdev development list , Linux Kernel List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1041910441.1032.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Jan 2003 12:23:30 +0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5591 Lines: 145 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; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/