Commit Graph

59 Commits

Author SHA1 Message Date
Antonino A. Daplas
96fe6a2109 [PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support
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:

<xres>x<yres>[M][R][-<bpp>][<at-sign><refresh>][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 - <pix>M<n>[-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 <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 14:03:39 -07:00
Thomas Winischhofer
544393fe58 [PATCH] sisfb update
This lifts sisfb from version 1.7.17 to version 1.8.9. Changes include:

- Added support for XGI V3XT, V5, V8, Z7 chipsets, including POSTing of
  all of these chipsets.

- Added support for latest SiS chipsets (761).

- Added support for SiS76x memory "hybrid" mode.

- Added support for new LCD resolutions (eg 1280x854, 856x480).

- Fixed support for 320x240 STN panels (for embedded devices).

- Fixed many HDTV modes (525p, 750p, 1080i).

- Fixed PCI config register reading/writing to use proper kernel
  functions for this purpose.

- Fixed PCI ROM handling to use the kernel's proper functions.

- Removed lots of "typedef"s.

- Removed lots of code which was for X.org/XFree86 only.

- Fixed coding style in many places.

- Removed lots of 2.4 cruft.

- Reduced stack size by unifying two previously separate structs into
  one.

- Added new hooks for memory allocation (for DRM).  Now the driver can
  truly handle multiple cards, including memory management.

- Fixed numerous minor bugs.

Signed-off-by: Thomas Winischhofer <thomas@winischhofer.net>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:58:01 -07:00
Antonino A. Daplas
b8c909454f [PATCH] fbdev: Fix greater than 1 bit monochrome color handling
Currently, fbcon assumes that the visual FB_VISUAL_MONO* is always 1 bit.
According to Geert, there are old hardware where it's possible to have
monochrome at 8-bit, but has only 2 colors, black - 0x00 and white - 0xff.
Fix color handlers (fb_get_color_depth, and get_color) for this special case.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:58:00 -07:00
Antonino A. Daplas
5e518d7672 [PATCH] fbdev: Resurrect hooks to get EDID from firmware
For the i386, code is already present in video.S that gets the EDID from the
video BIOS.  Make this visible so drivers can also use this data as fallback
when i2c does not work.

To ensure that the EDID block is returned for the primary graphics adapter
only, by check if the IORESOURCE_ROM_SHADOW flag is set.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:57:59 -07:00
Antonino A. Daplas
7726e9e10f [PATCH] fbdev: Add fbset -a support
Add capability to fbdev to listen to the FB_ACTIVATE_ALL flag.  If set, it
notifies fbcon that all consoles must be set to the current var.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 13:57:58 -07:00
James Simmons
f1ab5dac25 [PATCH] fbdev: stack reduction
Shrink the stack when calling the drawing alignment functions.

Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 19:07:41 -07:00
James Simmons
f5a9951c94 [PATCH] fbdev: iomove removal
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console.  The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now.  If there is no objection please apply.  This is against Linus
latestr GIT tree.  Thank you.

Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 19:07:39 -07:00
Benjamin Herrenschmidt
7149437669 [PATCH] fbdev: Batch cmap changes at driver level
This patch adds to the fbdev interface a set_cmap callback that allow the
driver to "batch" palette changes.  This is useful for drivers like
radeonfb which might require lenghtly workarounds on palette accesses, thus
allowing to factor out those workarounds efficiently.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:59:22 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00