07 Jun, 2008

2 commits

  • Frame buffer and mode setting drivers can be built as modules,
    so fb_mode_option needs to be exported to support these.

    Prevents this error:

    ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined!

    Signed-off-by: Geoff Levand
    Acked-by: Geert Uytterhoeven
    Cc: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geoff Levand
     
  • The temporary structure for calculated CVT mode is not initialized. Few
    fields have only bits or-ed or and-ed so they may be left in incorrect
    (random) state.

    Testing of the tridentfb seems like a good exercise for the fbdev layer.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Krzysztof Helt
     

28 Apr, 2008

2 commits

  • __FUNCTION__ is gcc-specific, use __func__

    Signed-off-by: Harvey Harrison
    Cc: "Antonino A. Daplas"
    Cc: Krzysztof Helt
    Cc: Antonino Daplas
    Cc: Antonino A. Daplas
    Cc: Antonino Daplas
    Cc: Richard Purdie
    Cc: Jean Delvare
    Cc: Adrian Bunk
    Cc: Russell King
    Cc: Benjamin Herrenschmidt
    Cc: Ben Dooks
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Harvey Harrison
     
  • Currently, if a perfect match in terms of resolution is not found,
    fb_find_mode() only looks for a best-fit mode among modes with a higher
    resolution than the one requested. Thus, if the user requests a resolution
    higher than the largest supported one, they are dropped to the default mode
    (usually a low resolution one).

    Change this behaviour so that all valid video modes are considered when
    looking for a best-fit mode, while still preferring modes with a higher
    resolution.

    Signed-off-by: Michal Januszewski
    Cc: Krzysztof Helt
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

18 Jan, 2008

1 commit

  • Fix http://bugzilla.kernel.org/show_bug.cgi?id=9762

    Framebuffer is ok only with default parameters only (it is 1280x800-8@60). If
    parameters are video=radeonfb:1280x800-32@60 then xres, yres and xres_virtual
    are ok but yres_virtual is 1024. It can be corrected by fbset utility so I
    think it can be corrected in the driver code also.

    Steps to reproduce: video=radeonfb:1280x800-32@60 or
    video=radeonfb:1280x800-16@60

    Add 1280x800 mode into modedb

    Cc: "Rafael J. Wysocki"
    Cc: "Antonino A. Daplas"
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    alex
     

19 Oct, 2007

1 commit


17 Oct, 2007

4 commits


09 May, 2007

1 commit


15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

13 Feb, 2007

3 commits

  • fb_videomode_to_var(): reset the virtual screen parameters when converting
    from an fb_videomode to an fb_var_screeninfo.

    Without this the old virtual screen parameters are kept. Hence you cannot
    switch to a video mode with a lower resolution on frame buffer devices that
    don't support virtual screens and panning, as values are not supposed to be
    rounded down when they don't fit.

    I also reordered the assignments to match the order of the individual members.

    Signed-off-by: Geert Uytterhoeven
    Cc: James Simmons
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     
  • fbdev modedb: make more input and output pointer parameters const

    Signed-off-by: Geert Uytterhoeven
    Cc: James Simmons
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     
  • fbdev modedb: Take into account the specified refresh rates for video modes
    specified by name, so e.g. all of `720p', `720p@60', and `720p@50' work.

    Signed-off-by: Geert Uytterhoeven
    Cc: James Simmons
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

09 Dec, 2006

1 commit

  • If no default mode is specified, it should be grabbed from the supplied
    database, not the default one.

    [teanropo@jyu.fi: fix it]
    [akpm@osdl.org: simplify it]
    [akpm@osdl.org: remove pointless DEFAULT_MODEDB_INDEX]
    Signed-off-by: Jordan Crouse
    Cc: Geert Uytterhoeven
    Cc: "Antonino A. Daplas"
    Signed-off-by: Tero Roponen
    Cc: James Simmons
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jordan Crouse
     

11 Jul, 2006

1 commit

  • MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
    function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
    allows all of the framebuffer and VT console drivers to remove their
    dependency on tty.h.

    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

27 Jun, 2006

3 commits


28 Mar, 2006

2 commits

  • Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove
    duplicates of ARRAY_SIZE. Some coding style and trailing whitespaces are
    also fixed.

    Compile-tested where possible (some are other arch or BROKEN)

    Signed-off-by: Tobias Klauser
    Cc: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tobias Klauser
     
  • Add a modeline for the Philips 200W display. aty128fb does not do DDC, it
    picks 1920x1440 or similar. It works ok with nvidiafb because it can ask
    for DDC data.

    mode "1680x1050-60"
    # D: 146.028 MHz, H: 65.191 kHz, V: 59.863 Hz
    geometry 1680 1050 1680 1050 16
    timings 6848 280 104 30 3 176 6
    hsync high
    vsync high
    rgba 5/11,6/5,5/0,0/0
    endmode

    hwinfo --monitor
    20: None 00.0: 10000 Monitor
    [Created at monitor.206]
    Unique ID: rdCR.pzUFTofo1S4
    Parent ID: 002j.bJRsY88eNSC
    Hardware Class: monitor
    Model: "PHILIPS Philips 200W"
    Vendor: PHL "PHILIPS"
    Device: eisa 0x0832 "Philips 200W"
    Serial ID: "VN 016596"
    Resolution: 720x400@70Hz
    Resolution: 640x480@60Hz
    Resolution: 640x480@67Hz
    Resolution: 640x480@72Hz
    Resolution: 640x480@75Hz
    Resolution: 800x600@56Hz
    Resolution: 800x600@60Hz
    Resolution: 800x600@72Hz
    Resolution: 800x600@75Hz
    Resolution: 832x624@75Hz
    Resolution: 1024x768@60Hz
    Resolution: 1024x768@70Hz
    Resolution: 1024x768@75Hz
    Resolution: 1280x1024@75Hz
    Resolution: 1152x864@70Hz
    Resolution: 1152x864@75Hz
    Resolution: 1280x960@60Hz
    Resolution: 1280x1024@60Hz
    Resolution: 1680x1050@60Hz
    Size: 433x271 mm
    Driver Info #0:
    Max. Resolution: 1680x1050
    Vert. Sync Range: 56-85 Hz
    Hor. Sync Range: 30-93 kHz
    Config Status: cfg=new, avail=yes, need=no, active=unknown
    Attached to: #5 (VGA compatible controller)

    Signed-off-by: Olaf Hering
    Acked-by: "Antonino A. Daplas"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Olaf Hering
     

09 Nov, 2005

1 commit


07 Nov, 2005

2 commits

  • Add new helper, fb_find_best_display(), which will search the modelist for the
    best mode for the attached display. This requires an EDID block that is
    converted to struct fb_monspecs and a private modelist. The search will be
    done in this manner:

    - if 1st detailed timing is preferred, use that
    - else if dimensions of the display are known, use that to estimate xres and
    - else if modelist has detailed timings, use the first detailed timing
    - else, use the very first entry from the modelist

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     
  • Currently the fb_find_nearest_mode() function finds a mode with screen
    resolution closest to that described by the 'var' argument and with some
    arbitrary refresh rate (eg. in the following sequence of refresh rates: 70 60
    53 85 75, 53 is selected).

    This patch fixes the function so that it looks for the closest mode as far as
    both resolution and refresh rate are concerned. The function's first argument
    is changed to fb_videomode so that the refresh rate can be specified by the
    caller, as fb_var_screeninfo doesn't have any fields that could directly hold
    this data.

    Signed-off-by: Michal Januszewski
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Januszewski
     

10 Sep, 2005

1 commit

  • The Coordinated Video Timings (CVT) is the latest standard approved by VESA
    concerning video timings generation. It addresses the limitation of GTF which
    is designed mainly for CRT displays. CRT's have a high blanking requirement
    (as much as 25% of the horizontal frame length) which artificially increases
    the pixelclock. Digital displays, on the other hand, needs to conserve the
    pixelclock as much as possible. The GTF also does not take into account the
    different aspect ratios in its calculation.

    The new function added is fb_find_mode_cvt(). It is called by fb_find_mode()
    if it recognizes a mode option string formatted for CVT. The format is:

    x[M][R][-][][i][m]

    The 'M' tells the function to calculate using CVT. On it's own, it will
    compute a timing for CRT displays at 60Hz. If the 'R' is specified, 'reduced
    blanking' computation will be used, best for flatpanels. The 'i' and the 'm'
    is for 'interlaced mode' and 'with margins' respectively.

    To determine if CVT was used, check for dmesg for something like this:

    CVT Mode - M[-R], ie: .480M3-R (800x600 reduced blanking)

    where: pix - product of xres and yres, in MB
    M - is a CVT mode
    n - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10)
    -R - reduced blanking

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

09 Aug, 2005

1 commit

  • Reported by:Vincent Fortier (Bugzilla Bug 4768)

    "At boot time the screen appears moved to the mid right portion of the actual
    video pannel making the end of the line appears at the left edge... It simply
    looks like moved half way to the right"

    His particular hardware has a display with an unusual dimension (1920x1200) but
    unfortunately has no EDID block. None of the entries in the global mode
    database is correct for this particular display, and it particularly has
    difficulty scaling up 640x480 (the default startup mode of nvidiafb) to
    1920x1200 which causes the above described problem.

    1, Add 1920x1200 to the global mode database.

    2. Let nvidiafb base the startup mode from the flatpanel dimensions only if the
    EDID block is absent, no boot mode parameter is specified by the user, and
    a flatpanel/LCD display is attached.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Linus Torvalds

    Antonino Daplas
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds