An error occurred fetching the project authors.
  1. 01 Apr, 2009 1 commit
  2. 26 Feb, 2009 2 commits
  3. 10 Feb, 2009 1 commit
  4. 21 Jan, 2009 1 commit
  5. 12 Jan, 2009 2 commits
  6. 06 Nov, 2008 1 commit
  7. 16 Oct, 2008 3 commits
  8. 26 Aug, 2008 1 commit
  9. 28 Jul, 2008 1 commit
  10. 24 Jul, 2008 4 commits
  11. 28 Apr, 2008 2 commits
    • Jaya Kumar's avatar
      fbdev: platforming metronomefb and am200epd · 03c33a4f
      Jaya Kumar authored
      This patch splits metronomefb into the platform independent metronomefb and
      the platform dependent am200epd.
      Signed-off-by: default avatarJaya Kumar <jayakumar.lkml@gmail.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03c33a4f
    • York Sun's avatar
      fbdev: powerpc: driver for Freescale 8610 and 5121 DIU · 9b53a9e2
      York Sun authored
      The following features are supported:
      plane 0 works as a regular frame buffer, can be accessed by /dev/fb0
      plane 1 has two AOIs (area of interest), can be accessed by /dev/fb1 and /dev/fb2
      plane 2 has two AOIs, can be accessed by /dev/fb3 and /dev/fb4
      Special ioctls support AOIs
      
      All /dev/fb* can be used as regular frame buffer devices, except hardware
      change can only be made through /dev/fb0.  Changing pixel clock has no effect
      on other fbs.
      
      Limitation of usage of AOIs:
      AOIs on the same plane can not be horizonally overlapped
      AOIs have horizonal order, i.e. AOI0 should be always on top of AOI1
      AOIs can not beyond phisical display area. Application should check AOI geometry
      before changing physical resolution on /dev/fb0
      
      required command line parameters to preallocate memory for frame buffer diufb.
      
      optional command line parameters to set modes and monitor
      video=fslfb:[resolution][,bpp][,monitor]
      Syntax:
      
      Resolution
      xres x yres-bpp@refresh_rate, the -bpp and @refresh_rate are optional
      eg, 1024x768, 1280x1024, 1280x1024-32, 1280x1024@60, 1280x1024-32@60, 1280x480-32@60
      
      Bpp
      bpp=32, bpp=24, or bpp=16
      
      Monitor
      monitor=0, monitor=1, monitor=2
      0 is DVI
      1 is Single link LVDS
      2 is Double link LVDS
      
      Note: switching monitor is a board feather, not DIU feather. MPC8610HPCD has three
      monitor ports to swtich to. MPC5121ADS doesn't have additional monitor port. So switching
      monirot port for MPC5121ADS has no effect.
      
      If compiled as a module, it takes pamameters mode, bpp, monitor with the same syntax above.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b53a9e2
  12. 24 Apr, 2008 1 commit
  13. 20 Mar, 2008 1 commit
    • Jaya Kumar's avatar
      fbdev: defio and Metronomefb · de7c6d15
      Jaya Kumar authored
      Implement support for the E-Ink Metronome controller.  It provides an mmapable
      interface to the controller using defio support.  It was tested with a gumstix
      pxa255 with Vizplex media using Xfbdev and various X clients such as xeyes,
      xpdf, xloadimage.
      
      This patch also fixes the following bug: Defio would cause a hang on write
      access to the framebuffer as the page fault would be called ad-infinitum.  It
      fixes fb_defio by setting the mapping to be used by page_mkclean.
      Signed-off-by: default avatarJaya Kumar <jayakumar.lkml@gmail.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      de7c6d15
  14. 11 Mar, 2008 1 commit
  15. 29 Nov, 2007 1 commit
    • Huang, Ying's avatar
      x86_64 EFI boot support: EFI frame buffer driver · 7c83172b
      Huang, Ying authored
      This patch adds Graphics Output Protocol support to the kernel.  UEFI2.0 spec
      deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output
      Protocol (GOP) is produced.  Therefore, the boot loader needs to query the
      UEFI firmware with appropriate Output Protocol and pass the video information
      to the kernel.  As a result of GOP protocol, an EFI framebuffer driver is
      needed for displaying console messages.  The patch adds a EFI framebuffer
      driver.  The EFI frame buffer driver in this patch is based on the Intel Mac
      framebuffer driver.
      
      The ELILO bootloader takes care of passing the video information as
      appropriate for EFI firmware.
      
      The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI
      platform.
      Signed-off-by: default avatarChandramouli Narayanan <mouli@linux.intel.com>
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7c83172b
  16. 16 Oct, 2007 2 commits
    • Michael Hennerich's avatar
      bf54x-lq043fb: framebuffer driver for Blackfin BF54x framebuffer device driver · e9fa7c43
      Michael Hennerich authored
      Blackfin BF54x framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD
      
      [adaplas]
      Add 'fb' suffix to driver name.
      Move Makefile entry under platform device section
      Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarBryan Wu <bryan.wu@analog.com>
      Signed-off-by: default avatarAntonino Daplas <adaplas@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e9fa7c43
    • Michal Januszewski's avatar
      uvesafb: the driver core · 8bdb3a2d
      Michal Januszewski authored
      uvesafb is an enhanced version of vesafb.  It uses a userspace helper (v86d)
      to execute calls to the x86 Video BIOS functions.  The driver is not limited
      to any specific arch and whether it works on a given arch or not depends on
      that arch being supported by the userspace daemon.  It has been tested on
      x86_32 and x86_64.
      
      A single BIOS call is represented by an instance of the uvesafb_ktask
      structure.  This structure contains a buffer, a completion struct and a
      uvesafb_task substructure, containing the values of the x86 registers, a flags
      field and a field indicating the length of the buffer.  Whenever a BIOS call
      is made in the driver, uvesafb_exec() builds a message using the uvesafb_task
      substructure and the contents of the buffer.  This message is then assigned a
      random ack number and sent to the userspace daemon using the connector
      interface.
      
      The message's sequence number is used as an index for the uvfb_tasks array,
      which provides a mapping from the messages coming from userspace to the
      in-kernel uvesafb_ktask structs.
      
      The userspace daemon performs the requested operation and sends a reply in the
      form of a uvesafb_task struct and, optionally, a buffer.  The seq and ack
      numbers in the reply should be exactly the same as those in the request.
      
      Each message from userspace is processed by uvesafb_cn_callback() and after
      passing a few sanity checks leads to the completion of a BIOS call request.
      Signed-off-by: default avatarMichal Januszewski <spock@gentoo.org>
      Signed-off-by: default avatarAntonino Daplas <adaplas@gmail.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Paulo Marques <pmarques@grupopie.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8bdb3a2d
  17. 31 Jul, 2007 1 commit
  18. 17 Jul, 2007 1 commit
  19. 11 May, 2007 1 commit
  20. 10 May, 2007 1 commit
    • Luming Yu's avatar
      ACPI: video: output switch sysfs support · 23b0f015
      Luming Yu authored
      Requires CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO.
      
      After loading output.ko and video.ko, you would have
      /sys/class/video_output and several device acpi_videoNum there.
      
      For example, I got acpi_video0, acpi_video1,acpi_video2,and acpi_video3
      under /sys/class/video_output on my T40.
      I can query the status of  output device0 by running " cat
      /sys/class/video_output/acpi_video0
      " The return value is defined in ACPI SPEC B.5.5 _DCS(Return the
      Status of Output Device).  Also you can turn off video1 and turn on
      video0  by " echo 0 > acpi_video1; echo 0x80000000 > acpi_video0".
      Please reference ACPI SPEC  B.5.7 _DSS for the parameter definition.
      
      Please note that it may or may NOT works purely depending on if
      your vendor providing correct ACPI video extension support in bios.
      the driver output.ko and video.ko just works like a interface to
      invoke BIOS.
      Signed-off-by: default avatarLuming Yu <Luming.yu@intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      23b0f015
  21. 09 May, 2007 2 commits
  22. 08 May, 2007 9 commits