01 Aug, 2006

1 commit

  • The backlight and lcd subsystems can be notified by the framebuffer layer
    of blanking events. However, these subsystems, as a whole, can function
    independently from the framebuffer layer. But in order to enable to the
    lcd and backlight subsystems, the framebuffer has to be compiled also,
    effectively sucking in a huge amount of unneeded code.

    To prevent dependency problems, separate out the framebuffer notification
    mechanism from the framebuffer layer and permanently link it to the kernel.

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

    Antonino A. Daplas
     

15 Jul, 2006

1 commit

  • Add frame buffer driver for the 2700G LCD controller present on CompuLab
    CM-X270 computer module.

    [adaplas]
    - Add more informative help text to Kconfig
    - Make DEBUG a Kconfig option as FB_MBX_DEBUG
    - Remove #include mbxdebug.c, this is frowned upon
    - Remove redundant casts
    - Arrange #include's alphabetically
    - Trivial whitespace

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

    Mike Rapoport
     

04 Jul, 2006

1 commit


27 Jun, 2006

2 commits

  • In order for this feature to work, an interface will be needed. The most
    appropriate is sysfs. However, the framebuffer console has no sysfs entry
    yet. This will create a sysfs class device entry for fbcon under
    /sys/class/graphics.

    Add a class_device entry 'fbcon' under class 'graphics'. Console-specific
    attributes which where previously under class/graphics/fb[x] are moved to
    class/graphics/fbcon. These attributes, 'con_rotate' and 'con_rotate_all',
    are also renamed to 'rotate' and 'rotate_all' respectively.

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

    Antonino A. Daplas
     
  • This patch adds a new framebuffer driver for the Intel Based macs. This
    framebuffer is needed when booting from EFI to get something out the box.

    [akpm: note: doesn't support modular building]

    [akpm@osdl.org: cleanups]
    Signed-off-by: Edgar Hucek
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Edgar Hucek
     

01 Apr, 2006

1 commit


28 Mar, 2006

1 commit


07 Nov, 2005

1 commit

  • According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
    drivers that do not support hardware cursors is redundant. The soft_cursor
    function is usable by all drivers because it is just a wrapper around
    fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
    moved to the console directory.

    Thus, drivers that do not support hardware cursors can leave the fb_cursor
    field blank. For drivers that do, they can fill up this field with their own
    version.

    The end result is a smaller code size. And if the framebuffer console is not
    loaded, module/kernel size is also reduced because the soft_cursor module will
    also not be loaded.

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

    Antonino A. Daplas
     

30 Oct, 2005

1 commit


10 Sep, 2005

3 commits

  • This set of two patches add support for the framebuffer of the Samsung S3C2410
    ARM SoC. This driver was started about one year ago and is now used on iPAQ
    h1930/h1940, Acer n30 and probably other s3c2410-based machines I'm not aware
    of. I've also heard yesterday that it's working also on iPAQ rx3715/rx3115
    (s3c2440-based machines).

    Signed-Off-By: Arnaud Patard
    Signed-off-by: Antonino Daplas
    Signed-off-by: Ben Dooks
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arnaud Patard
     
  • 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
     
  • This is a framebuffer driver for the Cyberblade/i1 graphics core.

    Currently tridenfb claims to support the cyberblade/i1 graphics core. This
    is of very limited truth. Even vesafb is faster and provides more working
    modes and a much better quality of the video signal. There is a great
    number of bugs in tridentfb ... but most often it is impossible to decide
    if these bugs are real bugs or if fixing them for the cyberblade/i1 core
    would break support for one of the other supported chips.

    Tridentfb seems to be unmaintained,and documentation for most of the
    supported chips is not available. So "fixing" cyberblade/i1 support inside
    of tridentfb was not an option, it would have caused numerous
    if(CYBERBLADEi1) else ... cases and would have rendered the code to be
    almost unmaintainable.

    A first version of this driver was published on 2005-07-31. A fix for a
    bug reported by Jochen Hein was integrated as well as some changes
    requested by Antonino A. Daplas.

    A message has been added to tridentfb to inform current users of tridentfb
    to switch to cyblafb if the cyberblade/i1 graphics core is detected.

    This patch is one logical change, but because of the included documentation
    it is bigger than 70kb. Therefore it is not sent to lkml and
    linux-fbdev-devel,

    Signed-off-by: Knut Petersen
    Cc: Muli Ben-Yehuda
    Acked-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Knut Petersen
     

22 Jun, 2005

1 commit

  • Add support for the Arc monochrome LCD board.

    The board uses KS108 controllers to drive individual 64x64 LCD matrices.
    The board can be paneled in a variety of setups such as 2x1=128x64,
    4x4=256x256 and so on. The board/host interface is through GPIO.

    Signed-off-by: Jaya Kumar
    Cc: "Antonino A. Daplas"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jaya Kumar
     

01 May, 2005

1 commit

  • This patch adds support for the framebuffer on the freescale i.MX SOC
    architecture. The driver has been tested on the mx1ads board, the pimx1 board
    and another custom board with different displays.

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

    Sascha Hauer
     

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