2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-22 20:23:57 +08:00
Commit Graph

9 Commits

Author SHA1 Message Date
Knut Petersen
44637a12f8 [PATCH] Update cyblafb driver
This is a major update to the cyblafb framebuffer driver. Most
of the stuff has been tested in the mm tree.

Main advantages:
============
  - vxres > xres support
  - ywrap and xpan support
  - much faster for almost all modes (e.g. 1280x1024-16bpp
     draws more than 41 full screens of text instead of about 25
     full screens of text per second on authors Epia 5000)
  - module init/exit code fixed
  - bugs triggered by console rotation fixed
  - lots of minor improvements
  - startup modes suitable for high performance scrolling
     in all directions

This diff  also contains a lot of white space fixes.

No side effects are possible, only one single graphics core is affected.

Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-09 10:00:36 -08:00
Antonino A. Daplas
efb985f6b2 [PATCH] fbcon: Console Rotation - Add framebuffer console documentation
Add documentation as Documentation/fb/fbcon.txt describing the framebuffer
console and its boot options.

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-11-09 07:56:35 -08:00
Antonino A. Daplas
8a0934f296 [PATCH] vesafb: Disable mtrr as the default
vesafb occassionally gets the size wrong when setting the mtrr.  When X or DRI
attempts to set the mtrr, it will fail due to range overlap significantly
affecting their performance.  Disable mtrr and let the user explicitly enable
it with the mtrr:n option.

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-11-07 07:53:52 -08:00
Antonino A. Daplas
c93a777103 [PATCH] i810fb: Update i810fb documentation
Update i810fb documentation to describe new features and configuration
changes.

Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-11 20:43:48 -07:00
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
Knut Petersen
9fa68eae9f [PATCH] framebuffer: new driver for cyberblade/i1 graphics core
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 <Knut_Petersen@t-online.de>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Acked-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:02 -07:00
Antonino A. Daplas
d7a465b474 [PATCH] vesafb: Document mtrr boot option usage
Document mtrr boot option usage to Documentation/fb/vesafb.txt.

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-07-30 10:14:47 -07:00
Sylvain Meyer
4ff45f5151 [PATCH] intelfb documentation
Add a small documentation of the driver parameters.

Signed-off-by: Sylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 19:07:40 -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