lkml.org 
[lkml]   [2003]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:32    [W:0.030 / U:61.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site