dasharo/linux
0
0
Fork 0
mirror of https://github.com/Dasharo/linux.git synced 2026-03-06 15:25:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

docs: fb: convert docs to ReST and rename to *.rst

Browse Source 
The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Also, removed the Maintained by, as requested by Geert.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Mauro Carvalho Chehab
2019-06-12 14:52:45 -03:00
committed by Jonathan Corbet
parent 10ffebbed5
commit ab42b81895
47 changed files with 1945 additions and 1658 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -5024,7 +5024,7 @@
vector=percpu: enable percpu vector domain
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.txt.
See Documentation/fb/modedb.rst.
video.brightness_switch_enabled= [0,1]
If set to 1, on receiving an ACPI notify event

29
Documentation/fb/api.txt → Documentation/fb/api.rst
View File

@@ -1,5 +1,6 @@
The Frame Buffer Device API
---------------------------
===========================
The Frame Buffer Device API
===========================
Last revised: June 21, 2011
@@ -21,13 +22,13 @@ deal with different behaviours.
---------------
Device and driver capabilities are reported in the fixed screen information
capabilities field.
capabilities field::
struct fb_fix_screeninfo {
struct fb_fix_screeninfo {
...
__u16 capabilities; /* see FB_CAP_* */
...
};
};
Application should use those capabilities to find out what features they can
expect from the device and driver.
@@ -151,9 +152,9 @@ fb_fix_screeninfo and fb_var_screeninfo structure respectively.
struct fb_fix_screeninfo stores device independent unchangeable information
about the frame buffer device and the current format. Those information can't
be directly modified by applications, but can be changed by the driver when an
application modifies the format.
application modifies the format::
struct fb_fix_screeninfo {
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
unsigned long smem_start; /* Start of frame buffer mem */
/* (physical address) */
@@ -172,13 +173,13 @@ struct fb_fix_screeninfo {
/* specific chip/card we have */
__u16 capabilities; /* see FB_CAP_* */
__u16 reserved[2]; /* Reserved for future compatibility */
};
};
struct fb_var_screeninfo stores device independent changeable information
about a frame buffer device, its current format and video mode, as well as
other miscellaneous parameters.
other miscellaneous parameters::
struct fb_var_screeninfo {
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
@@ -216,7 +217,7 @@ struct fb_var_screeninfo {
__u32 rotate; /* angle we rotate counter clockwise */
__u32 colorspace; /* colorspace for FOURCC-based modes */
__u32 reserved[4]; /* Reserved for future compatibility */
};
};
To modify variable information, applications call the FBIOPUT_VSCREENINFO
ioctl with a pointer to a fb_var_screeninfo structure. If the call is
@@ -255,14 +256,14 @@ monochrome, grayscale or pseudocolor visuals, although this is not required.
- For truecolor and directcolor formats, applications set the grayscale field
to zero, and the red, blue, green and transp fields to describe the layout of
color components in memory.
color components in memory::
struct fb_bitfield {
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
};
Pixel values are bits_per_pixel wide and are split in non-overlapping red,
green, blue and alpha (transparency) components. Location and size of each

8
Documentation/fb/arkfb.txt → Documentation/fb/arkfb.rst
View File

@@ -1,6 +1,6 @@
arkfb - fbdev driver for ARK Logic chips
========================================
========================================
arkfb - fbdev driver for ARK Logic chips
========================================
Supported Hardware
@@ -47,7 +47,7 @@ Missing Features
(alias TODO list)
* secondary (not initialized by BIOS) device support
* big endian support
* big endian support
* DPMS support
* MMIO support
* interlaced mode variant

35
Documentation/fb/aty128fb.txt → Documentation/fb/aty128fb.rst
View File

@@ -1,8 +1,9 @@
[This file is cloned from VesaFB/matroxfb]
=================
What is aty128fb?
=================
.. [This file is cloned from VesaFB/matroxfb]
This is a driver for a graphic framebuffer for ATI Rage128 based devices
on Intel and PPC boxes.
@@ -24,15 +25,15 @@ How to use it?
==============
Switching modes is done using the video=aty128fb:<resolution>... modedb
boot parameter or using `fbset' program.
boot parameter or using `fbset` program.
See Documentation/fb/modedb.txt for more information on modedb
See Documentation/fb/modedb.rst for more information on modedb
resolutions.
You should compile in both vgacon (to boot if you remove your Rage128 from
box) and aty128fb (for graphics mode). You should not compile-in vesafb
unless you have primary display on non-Rage128 VBE2.0 device (see
Documentation/fb/vesafb.txt for details).
unless you have primary display on non-Rage128 VBE2.0 device (see
Documentation/fb/vesafb.rst for details).
X11
@@ -48,16 +49,18 @@ Configuration
=============
You can pass kernel command line options to vesafb with
`video=aty128fb:option1,option2:value2,option3' (multiple options should
be separated by comma, values are separated from options by `:').
`video=aty128fb:option1,option2:value2,option3` (multiple options should
be separated by comma, values are separated from options by `:`).
Accepted options:
noaccel - do not use acceleration engine. It is default.
accel - use acceleration engine. Not finished.
vmode:x - chooses PowerMacintosh video mode <x>. Deprecated.
cmode:x - chooses PowerMacintosh colour mode <x>. Deprecated.
<XxX@X> - selects startup videomode. See modedb.txt for detailed
explanation. Default is 640x480x8bpp.
========= =======================================================
noaccel do not use acceleration engine. It is default.
accel use acceleration engine. Not finished.
vmode:x chooses PowerMacintosh video mode <x>. Deprecated.
cmode:x chooses PowerMacintosh colour mode <x>. Deprecated.
<XxX@X> selects startup videomode. See modedb.txt for detailed
explanation. Default is 640x480x8bpp.
========= =======================================================
Limitations
@@ -65,8 +68,8 @@ Limitations
There are known and unknown bugs, features and misfeatures.
Currently there are following known bugs:
+ This driver is still experimental and is not finished. Too many
- This driver is still experimental and is not finished. Too many
bugs/errata to list here.
--
Brad Douglas <brad@neruo.com>

47
Documentation/fb/cirrusfb.txt → Documentation/fb/cirrusfb.rst
View File

@@ -1,32 +1,32 @@
============================================
Framebuffer driver for Cirrus Logic chipsets
============================================
Framebuffer driver for Cirrus Logic chipsets
Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
{ just a little something to get people going; contributors welcome! }
.. just a little something to get people going; contributors welcome!
Chip families supported:
SD64
Piccolo
Picasso
Spectrum
Alpine (GD-543x/4x)
Picasso4 (GD-5446)
GD-5480
Laguna (GD-546x)
- SD64
- Piccolo
- Picasso
- Spectrum
- Alpine (GD-543x/4x)
- Picasso4 (GD-5446)
- GD-5480
- Laguna (GD-546x)
Bus's supported:
PCI
Zorro
- PCI
- Zorro
Architectures supported:
i386
Alpha
PPC (Motorola Powerstack)
m68k (Amiga)
- i386
- Alpha
- PPC (Motorola Powerstack)
- m68k (Amiga)
@@ -34,10 +34,9 @@ Default video modes
-------------------
At the moment, there are two kernel command line arguments supported:
mode:640x480
mode:800x600
or
mode:1024x768
- mode:640x480
- mode:800x600
- mode:1024x768
Full support for startup video modes (modedb) will be integrated soon.
@@ -93,5 +92,3 @@ Version 1.9.4
Version 1.9.3
-------------
* Bundled with kernel 2.3.14-pre1 or later.

59
Documentation/fb/cmap_xfbdev.txt → Documentation/fb/cmap_xfbdev.rst
View File

@@ -1,26 +1,29 @@
==========================
Understanding fbdev's cmap
--------------------------
==========================
These notes explain how X's dix layer uses fbdev's cmap structures.
*. example of relevant structures in fbdev as used for a 3-bit grayscale cmap
struct fb_var_screeninfo {
.bits_per_pixel = 8,
.grayscale = 1,
.red = { 4, 3, 0 },
.green = { 0, 0, 0 },
.blue = { 0, 0, 0 },
}
struct fb_fix_screeninfo {
.visual = FB_VISUAL_STATIC_PSEUDOCOLOR,
}
for (i = 0; i < 8; i++)
info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16;
memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8);
memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8);
- example of relevant structures in fbdev as used for a 3-bit grayscale cmap::
*. X11 apps do something like the following when trying to use grayscale.
for (i=0; i < 8; i++) {
struct fb_var_screeninfo {
.bits_per_pixel = 8,
.grayscale = 1,
.red = { 4, 3, 0 },
.green = { 0, 0, 0 },
.blue = { 0, 0, 0 },
}
struct fb_fix_screeninfo {
.visual = FB_VISUAL_STATIC_PSEUDOCOLOR,
}
for (i = 0; i < 8; i++)
info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16;
memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8);
memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8);
- X11 apps do something like the following when trying to use grayscale::
for (i=0; i < 8; i++) {
char colorspec[64];
memset(colorspec,0,64);
sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36);
@@ -28,26 +31,26 @@ for (i=0; i < 8; i++) {
printf("Can't get color %s\n",colorspec);
XAllocColor(outputDisplay, testColormap, &wantedColor);
grays[i] = wantedColor;
}
}
There's also named equivalents like gray1..x provided you have an rgb.txt.
Somewhere in X's callchain, this results in a call to X code that handles the
colormap. For example, Xfbdev hits the following:
xc-011010/programs/Xserver/dix/colormap.c:
xc-011010/programs/Xserver/dix/colormap.c::
FindBestPixel(pentFirst, size, prgb, channel)
FindBestPixel(pentFirst, size, prgb, channel)
dr = (long) pent->co.local.red - prgb->red;
dg = (long) pent->co.local.green - prgb->green;
db = (long) pent->co.local.blue - prgb->blue;
sq = dr * dr;
UnsignedToBigNum (sq, &sum);
BigNumAdd (&sum, &temp, &sum);
dr = (long) pent->co.local.red - prgb->red;
dg = (long) pent->co.local.green - prgb->green;
db = (long) pent->co.local.blue - prgb->blue;
sq = dr * dr;
UnsignedToBigNum (sq, &sum);
BigNumAdd (&sum, &temp, &sum);
co.local.red are entries that were brought in through FBIOGETCMAP which come
directly from the info->cmap.red that was listed above. The prgb is the rgb
that the app wants to match to. The above code is doing what looks like a least
squares matching function. That's why the cmap entries can't be set to the left
hand side boundaries of a color range.

28
Documentation/fb/deferred_io.txt → Documentation/fb/deferred_io.rst
View File

@@ -1,5 +1,6 @@
===========
Deferred IO
-----------
===========
Deferred IO is a way to delay and repurpose IO. It uses host memory as a
buffer and the MMU pagefault as a pretrigger for when to perform the device
@@ -16,7 +17,7 @@ works:
- app continues writing to that page with no additional cost. this is
the key benefit.
- the workqueue task comes in and mkcleans the pages on the list, then
completes the work associated with updating the framebuffer. this is
completes the work associated with updating the framebuffer. this is
the real work talking to the device.
- app tries to write to the address (that has now been mkcleaned)
- get pagefault and the above sequence occurs again
@@ -47,29 +48,32 @@ How to use it: (for fbdev drivers)
----------------------------------
The following example may be helpful.
1. Setup your structure. Eg:
1. Setup your structure. Eg::
static struct fb_deferred_io hecubafb_defio = {
.delay = HZ,
.deferred_io = hecubafb_dpy_deferred_io,
};
static struct fb_deferred_io hecubafb_defio = {
.delay = HZ,
.deferred_io = hecubafb_dpy_deferred_io,
};
The delay is the minimum delay between when the page_mkwrite trigger occurs
and when the deferred_io callback is called. The deferred_io callback is
explained below.
2. Setup your deferred IO callback. Eg:
static void hecubafb_dpy_deferred_io(struct fb_info *info,
struct list_head *pagelist)
2. Setup your deferred IO callback. Eg::
static void hecubafb_dpy_deferred_io(struct fb_info *info,
struct list_head *pagelist)
The deferred_io callback is where you would perform all your IO to the display
device. You receive the pagelist which is the list of pages that were written
to during the delay. You must not modify this list. This callback is called
from a workqueue.
3. Call init
3. Call init::
info->fbdefio = &hecubafb_defio;
fb_deferred_io_init(info);
4. Call cleanup
4. Call cleanup::
fb_deferred_io_cleanup(info);

18
Documentation/fb/efifb.txt → Documentation/fb/efifb.rst
View File

@@ -1,6 +1,6 @@
==============
What is efifb?
===============
==============
This is a generic EFI platform driver for Intel based Apple computers.
efifb is only for EFI booted Intel Macs.
@@ -8,16 +8,17 @@ efifb is only for EFI booted Intel Macs.
Supported Hardware
==================
iMac 17"/20"
Macbook
Macbook Pro 15"/17"
MacMini
- iMac 17"/20"
- Macbook
- Macbook Pro 15"/17"
- MacMini
How to use it?
==============
efifb does not have any kind of autodetection of your machine.
You have to add the following kernel parameters in your elilo.conf:
You have to add the following kernel parameters in your elilo.conf::
Macbook :
video=efifb:macbook
MacMini :
@@ -29,9 +30,10 @@ You have to add the following kernel parameters in your elilo.conf:
Accepted options:
======= ===========================================================
nowc Don't map the framebuffer write combined. This can be used
to workaround side-effects and slowdowns on other CPU cores
when large amounts of console data are written.
======= ===========================================================
--
Edgar Hucek <gimli@dark-green.com>

27
Documentation/fb/ep93xx-fb.txt → Documentation/fb/ep93xx-fb.rst
View File

@@ -4,7 +4,7 @@ Driver for EP93xx LCD controller
The EP93xx LCD controller can drive both standard desktop monitors and
embedded LCD displays. If you have a standard desktop monitor then you
can use the standard Linux video mode database. In your board file:
can use the standard Linux video mode database. In your board file::
static struct ep93xxfb_mach_info some_board_fb_info = {
.num_modes = EP93XXFB_USE_MODEDB,
@@ -12,7 +12,7 @@ can use the standard Linux video mode database. In your board file:
};
If you have an embedded LCD display then you need to define a video
mode for it as follows:
mode for it as follows::
static struct fb_videomode some_board_video_modes[] = {
{
@@ -23,11 +23,11 @@ mode for it as follows:
Note that the pixel clock value is in pico-seconds. You can use the
KHZ2PICOS macro to convert the pixel clock value. Most other values
are in pixel clocks. See Documentation/fb/framebuffer.txt for further
are in pixel clocks. See Documentation/fb/framebuffer.rst for further
details.
The ep93xxfb_mach_info structure for your board should look like the
following:
following::
static struct ep93xxfb_mach_info some_board_fb_info = {
.num_modes = ARRAY_SIZE(some_board_video_modes),
@@ -37,7 +37,7 @@ following:
};
The framebuffer device can be registered by adding the following to
your board initialisation function:
your board initialisation function::
ep93xx_register_fb(&some_board_fb_info);
@@ -50,6 +50,7 @@ to configure the controller. The video attributes flags are fully
documented in section 7 of the EP93xx users' guide. The following
flags are available:
=============================== ==========================================
EP93XXFB_PCLK_FALLING Clock data on the falling edge of the
pixel clock. The default is to clock
data on the rising edge.
@@ -62,10 +63,12 @@ EP93XXFB_SYNC_HORIZ_HIGH Horizontal sync is active high. By
EP93XXFB_SYNC_VERT_HIGH Vertical sync is active high. By
default the vertical sync is active high.
=============================== ==========================================
The physical address of the framebuffer can be controlled using the
following flags:
=============================== ======================================
EP93XXFB_USE_SDCSN0 Use SDCSn[0] for the framebuffer. This
is the default setting.
@@ -74,6 +77,7 @@ EP93XXFB_USE_SDCSN1 Use SDCSn[1] for the framebuffer.
EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer.
EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer.
=============================== ======================================
==================
Platform callbacks
@@ -87,7 +91,7 @@ blanked or unblanked.
The setup and teardown devices pass the platform_device structure as
an argument. The fb_info and ep93xxfb_mach_info structures can be
obtained as follows:
obtained as follows::
static int some_board_fb_setup(struct platform_device *pdev)
{
@@ -101,17 +105,17 @@ obtained as follows:
Setting the video mode
======================
The video mode is set using the following syntax:
The video mode is set using the following syntax::
video=XRESxYRES[-BPP][@REFRESH]
If the EP93xx video driver is built-in then the video mode is set on
the Linux kernel command line, for example:
the Linux kernel command line, for example::
video=ep93xx-fb:800x600-16@60
If the EP93xx video driver is built as a module then the video mode is
set when the module is installed:
set when the module is installed::
modprobe ep93xx-fb video=320x240
@@ -121,13 +125,14 @@ Screenpage bug
At least on the EP9315 there is a silicon bug which causes bit 27 of
the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is
an unofficial errata for this bug at:
an unofficial errata for this bug at::
http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
By default the EP93xx framebuffer driver checks if the allocated physical
address has bit 27 set. If it does, then the memory is freed and an
error is returned. The check can be disabled by adding the following
option when loading the driver:
option when loading the driver::
ep93xx-fb.check_screenpage_bug=0

177
Documentation/fb/fbcon.txt → Documentation/fb/fbcon.rst
View File

@@ -1,39 +1,41 @@
=======================
The Framebuffer Console
=======================
The framebuffer console (fbcon), as its name implies, is a text
The framebuffer console (fbcon), as its name implies, is a text
console running on top of the framebuffer device. It has the functionality of
any standard text console driver, such as the VGA console, with the added
features that can be attributed to the graphical nature of the framebuffer.
In the x86 architecture, the framebuffer console is optional, and
In the x86 architecture, the framebuffer console is optional, and
some even treat it as a toy. For other architectures, it is the only available
display device, text or graphical.
What are the features of fbcon? The framebuffer console supports
What are the features of fbcon? The framebuffer console supports
high resolutions, varying font types, display rotation, primitive multihead,
etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature
made available by the underlying graphics card are also possible.
A. Configuration
================
The framebuffer console can be enabled by using your favorite kernel
The framebuffer console can be enabled by using your favorite kernel
configuration tool. It is under Device Drivers->Graphics Support->Frame
buffer Devices->Console display driver support->Framebuffer Console Support.
Select 'y' to compile support statically or 'm' for module support. The
module will be fbcon.
In order for fbcon to activate, at least one framebuffer driver is
In order for fbcon to activate, at least one framebuffer driver is
required, so choose from any of the numerous drivers available. For x86
systems, they almost universally have VGA cards, so vga16fb and vesafb will
always be available. However, using a chipset-specific driver will give you
more speed and features, such as the ability to change the video mode
dynamically.
To display the penguin logo, choose any logo available in Graphics
To display the penguin logo, choose any logo available in Graphics
support->Bootup logo.
Also, you will need to select at least one compiled-in font, but if
Also, you will need to select at least one compiled-in font, but if
you don't do anything, the kernel configuration tool will select one for you,
usually an 8x16 font.
@@ -44,6 +46,7 @@ fortunate to have a driver that does not alter the graphics chip, then you
will still get a VGA console.
B. Loading
==========
Possible scenarios:
@@ -72,33 +75,33 @@ Possible scenarios:
C. Boot options
The framebuffer console has several, largely unknown, boot options
that can change its behavior.
The framebuffer console has several, largely unknown, boot options
that can change its behavior.
1. fbcon=font:<name>
Select the initial font to use. The value 'name' can be any of the
compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, VGA8x16, VGA8x8.
Select the initial font to use. The value 'name' can be any of the
compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, VGA8x16, VGA8x8.
Note, not all drivers can handle font with widths not divisible by 8,
such as vga16fb.
such as vga16fb.
2. fbcon=scrollback:<value>[k]
The scrollback buffer is memory that is used to preserve display
contents that has already scrolled past your view. This is accessed
by using the Shift-PageUp key combination. The value 'value' is any
integer. It defaults to 32KB. The 'k' suffix is optional, and will
multiply the 'value' by 1024.
The scrollback buffer is memory that is used to preserve display
contents that has already scrolled past your view. This is accessed
by using the Shift-PageUp key combination. The value 'value' is any
integer. It defaults to 32KB. The 'k' suffix is optional, and will
multiply the 'value' by 1024.
3. fbcon=map:<0123>
This is an interesting option. It tells which driver gets mapped to
which console. The value '0123' is a sequence that gets repeated until
the total length is 64 which is the number of consoles available. In
the above example, it is expanded to 012301230123... and the mapping
will be:
This is an interesting option. It tells which driver gets mapped to
which console. The value '0123' is a sequence that gets repeated until
the total length is 64 which is the number of consoles available. In
the above example, it is expanded to 012301230123... and the mapping
will be::
tty | 1 2 3 4 5 6 7 8 9 ...
fb | 0 1 2 3 0 1 2 3 0 ...
@@ -126,20 +129,20 @@ C. Boot options
4. fbcon=rotate:<n>
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
0 - normal orientation (0 degree)
1 - clockwise orientation (90 degrees)
2 - upside down orientation (180 degrees)
3 - counterclockwise orientation (270 degrees)
- 0 - normal orientation (0 degree)
- 1 - clockwise orientation (90 degrees)
- 2 - upside down orientation (180 degrees)
- 3 - counterclockwise orientation (270 degrees)
The angle can be changed anytime afterwards by 'echoing' the same
numbers to any one of the 2 attributes found in
/sys/class/graphics/fbcon:
rotate - rotate the display of the active console
rotate_all - rotate the display of all consoles
- rotate - rotate the display of the active console
- rotate_all - rotate the display of all consoles
Console rotation will only become available if Framebuffer Console
Rotation support is compiled in your kernel.
@@ -177,9 +180,9 @@ Before going on to how to attach, detach and unload the framebuffer console, an
illustration of the dependencies may help.
The console layer, as with most subsystems, needs a driver that interfaces with
the hardware. Thus, in a VGA console:
the hardware. Thus, in a VGA console::
console ---> VGA driver ---> hardware.
console ---> VGA driver ---> hardware.
Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
from the console layer before unloading the driver. The VGA driver cannot be
@@ -187,9 +190,9 @@ unloaded if it is still bound to the console layer. (See
Documentation/console/console.txt for more information).
This is more complicated in the case of the framebuffer console (fbcon),
because fbcon is an intermediate layer between the console and the drivers:
because fbcon is an intermediate layer between the console and the drivers::
console ---> fbcon ---> fbdev drivers ---> hardware
console ---> fbcon ---> fbdev drivers ---> hardware
The fbdev drivers cannot be unloaded if bound to fbcon, and fbcon cannot
be unloaded if it's bound to the console layer.
@@ -204,12 +207,12 @@ So, how do we unbind fbcon from the console? Part of the answer is in
Documentation/console/console.txt. To summarize:
Echo a value to the bind file that represents the framebuffer console
driver. So assuming vtcon1 represents fbcon, then:
driver. So assuming vtcon1 represents fbcon, then::
echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
console layer
echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
console layer
echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
console layer
echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
console layer
If fbcon is detached from the console layer, your boot console driver (which is
usually VGA text mode) will take over. A few drivers (rivafb and i810fb) will
@@ -223,19 +226,19 @@ restored properly. The following is one of the several methods that you can do:
2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.
3. Boot into text mode and as root run:
3. Boot into text mode and as root run::
vbetool vbestate save > <vga state file>
The above command saves the register contents of your graphics
hardware to <vga state file>. You need to do this step only once as
the state file can be reused.
The above command saves the register contents of your graphics
hardware to <vga state file>. You need to do this step only once as
the state file can be reused.
4. If fbcon is compiled as a module, load fbcon by doing:
4. If fbcon is compiled as a module, load fbcon by doing::
modprobe fbcon
5. Now to detach fbcon:
5. Now to detach fbcon::
vbetool vbestate restore < <vga state file> && \
echo 0 > /sys/class/vtconsole/vtcon1/bind
@@ -243,7 +246,7 @@ restored properly. The following is one of the several methods that you can do:
6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
you can unload it by 'rmmod fbcon'.
7. To reattach fbcon:
7. To reattach fbcon::
echo 1 > /sys/class/vtconsole/vtcon1/bind
@@ -266,82 +269,82 @@ the following:
Variation 1:
a. Before detaching fbcon, do
a. Before detaching fbcon, do::
vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
# the file can be reused
vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
# the file can be reused
b. Detach fbcon as in step 5.
c. Attach fbcon
c. Attach fbcon::
vbetool vbestate restore < <vesa state file> && \
vbetool vbestate restore < <vesa state file> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Variation 2:
a. Before detaching fbcon, do:
a. Before detaching fbcon, do::
echo <ID> > /sys/class/tty/console/bind
vbetool vbemode get
vbetool vbemode get
b. Take note of the mode number
b. Detach fbcon as in step 5.
c. Attach fbcon:
c. Attach fbcon::
vbetool vbemode set <mode number> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
vbetool vbemode set <mode number> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Samples:
========
Here are 2 sample bash scripts that you can use to bind or unbind the
framebuffer console driver if you are on an X86 box:
framebuffer console driver if you are on an X86 box::
---------------------------------------------------------------------------
#!/bin/bash
# Unbind fbcon
#!/bin/bash
# Unbind fbcon
# Change this to where your actual vgastate file is located
# Or Use VGASTATE=$1 to indicate the state file at runtime
VGASTATE=/tmp/vgastate
# Change this to where your actual vgastate file is located
# Or Use VGASTATE=$1 to indicate the state file at runtime
VGASTATE=/tmp/vgastate
# path to vbetool
VBETOOL=/usr/local/bin
# path to vbetool
VBETOOL=/usr/local/bin
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
if test -x $VBETOOL/vbetool; then
echo Unbinding vtcon$i
$VBETOOL/vbetool vbestate restore < $VGASTATE
echo 0 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
fi
done
fi
fi
done
---------------------------------------------------------------------------
#!/bin/bash
# Bind fbcon
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
::
#!/bin/bash
# Bind fbcon
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
echo Unbinding vtcon$i
echo 1 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
done
---------------------------------------------------------------------------
fi
fi
done
--
Antonino Daplas <adaplas@pol.net>

80
Documentation/fb/framebuffer.txt → Documentation/fb/framebuffer.rst
View File

@@ -1,7 +1,7 @@
The Frame Buffer Device
-----------------------
=======================
The Frame Buffer Device
=======================
Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
Last revised: May 10, 2001
@@ -26,7 +26,7 @@ other device in /dev. It's a character device using major 29; the minor
specifies the frame buffer number.
By convention, the following device nodes are used (numbers indicate the device
minor numbers):
minor numbers)::
0 = /dev/fb0 First frame buffer
1 = /dev/fb1 Second frame buffer
@@ -34,15 +34,15 @@ minor numbers):
31 = /dev/fb31 32nd frame buffer
For backwards compatibility, you may want to create the following symbolic
links:
links::
/dev/fb0current -> fb0
/dev/fb1current -> fb1
and so on...
The frame buffer devices are also `normal' memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by
The frame buffer devices are also `normal` memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by::
cp /dev/fb0 myfile
@@ -54,11 +54,11 @@ Application software that uses the frame buffer device (e.g. the X server) will
use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
an alternative frame buffer device by setting the environment variable
$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
users):
users)::
export FRAMEBUFFER=/dev/fb1
or (for csh users):
or (for csh users)::
setenv FRAMEBUFFER /dev/fb1
@@ -90,9 +90,9 @@ which data structures they work. Here's just a brief overview:
possible).
- You can get and set parts of the color map. Communication is done with 16
bits per color part (red, green, blue, transparency) to support all
existing hardware. The driver does all the computations needed to apply
it to the hardware (round it down to less bits, maybe throw away
bits per color part (red, green, blue, transparency) to support all
existing hardware. The driver does all the computations needed to apply
it to the hardware (round it down to less bits, maybe throw away
transparency).
All this hardware abstraction makes the implementation of application programs
@@ -113,10 +113,10 @@ much trouble...
3. Frame Buffer Resolution Maintenance
--------------------------------------
Frame buffer resolutions are maintained using the utility `fbset'. It can
Frame buffer resolutions are maintained using the utility `fbset`. It can
change the video mode properties of a frame buffer device. Its main usage is
to change the current video mode, e.g. during boot up in one of your /etc/rc.*
or /etc/init.d/* files.
to change the current video mode, e.g. during boot up in one of your `/etc/rc.*`
or `/etc/init.d/*` files.
Fbset uses a video mode database stored in a configuration file, so you can
easily add your own modes and refer to them with a simple identifier.
@@ -129,8 +129,8 @@ The X server (XF68_FBDev) is the most notable application program for the frame
buffer device. Starting with XFree86 release 3.2, the X server is part of
XFree86 and has 2 modes:
- If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
file contains a
- If the `Display` subsection for the `fbdev` driver in the /etc/XF86Config
file contains a::
Modes "default"
@@ -146,7 +146,7 @@ XFree86 and has 2 modes:
same virtual desktop size. The frame buffer device that's used is still
/dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
defined by /etc/XF86Config now. The disadvantage is that you have to
specify the timings in a different format (but `fbset -x' may help).
specify the timings in a different format (but `fbset -x` may help).
To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
work 100% with XF68_FBDev: the reported clock values are always incorrect.
@@ -172,29 +172,29 @@ retrace, the electron beam is turned off (blanked).
The speed at which the electron beam paints the pixels is determined by the
dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
of cycles per second), each pixel is 35242 ps (picoseconds) long:
of cycles per second), each pixel is 35242 ps (picoseconds) long::
1/(28.37516E6 Hz) = 35.242E-9 s
If the screen resolution is 640x480, it will take
If the screen resolution is 640x480, it will take::
640*35.242E-9 s = 22.555E-6 s
to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
also takes time (e.g. 272 `pixels'), so a full scanline takes
also takes time (e.g. 272 `pixels`), so a full scanline takes::
(640+272)*35.242E-9 s = 32.141E-6 s
We'll say that the horizontal scanrate is about 31 kHz:
We'll say that the horizontal scanrate is about 31 kHz::
1/(32.141E-6 s) = 31.113E3 Hz
A full screen counts 480 (yres) lines, but we have to consider the vertical
retrace too (e.g. 49 `lines'). So a full screen will take
retrace too (e.g. 49 `lines`). So a full screen will take::
(480+49)*32.141E-6 s = 17.002E-3 s
The vertical scanrate is about 59 Hz:
The vertical scanrate is about 59 Hz::
1/(17.002E-3 s) = 58.815 Hz
@@ -212,7 +212,7 @@ influenced by the moments at which the synchronization pulses occur.
The following picture summarizes all timings. The horizontal retrace time is
the sum of the left margin, the right margin and the hsync length, while the
vertical retrace time is the sum of the upper margin, the lower margin and the
vsync length.
vsync length::
+----------+---------------------------------------------+----------+-------+
| | ↑ | | |
@@ -256,7 +256,8 @@ The frame buffer device expects all horizontal timings in number of dotclocks
6. Converting XFree86 timing values info frame buffer device timings
--------------------------------------------------------------------
An XFree86 mode line consists of the following fields:
An XFree86 mode line consists of the following fields::
"800x600" 50 800 856 976 1040 600 637 643 666
< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
@@ -271,19 +272,27 @@ The frame buffer device uses the following fields:
- vsync_len: length of vertical sync
1) Pixelclock:
xfree: in MHz
fb: in picoseconds (ps)
pixclock = 1000000 / DCF
2) horizontal timings:
left_margin = HFL - SH2
right_margin = SH1 - HR
hsync_len = SH2 - SH1
3) vertical timings:
upper_margin = VFL - SV2
lower_margin = SV1 - VR
vsync_len = SV2 - SV1
Good examples for VESA timings can be found in the XFree86 source tree,
@@ -303,9 +312,10 @@ and to the following documentation:
- The manual pages for fbset: fbset(8), fb.modes(5)
- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
- The mighty kernel sources:
o linux/drivers/video/
o linux/include/linux/fb.h
o linux/include/video/
- linux/drivers/video/
- linux/include/linux/fb.h
- linux/include/video/
@@ -330,14 +340,14 @@ and on its mirrors.
The latest version of fbset can be found at
http://www.linux-fbdev.org/
http://www.linux-fbdev.org/
10. Credits
-----------
10. Credits
----------
This readme was written by Geert Uytterhoeven, partly based on the original
`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
`X-framebuffer.README` by Roman Hodek and Martin Schaller. Section 6 was
provided by Frank Neumann.
The frame buffer device abstraction was designed by Martin Schaller.

24
Documentation/fb/gxfb.txt → Documentation/fb/gxfb.rst
View File

@@ -1,7 +1,8 @@
[This file is cloned from VesaFB/aty128fb]
=============
What is gxfb?
=================
=============
.. [This file is cloned from VesaFB/aty128fb]
This is a graphics framebuffer driver for AMD Geode GX2 based processors.
@@ -23,9 +24,9 @@ How to use it?
==============
Switching modes is done using gxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
parameter or using `fbset` program.
See Documentation/fb/modedb.txt for more information on modedb
See Documentation/fb/modedb.rst for more information on modedb
resolutions.
@@ -42,11 +43,12 @@ You can pass kernel command line options to gxfb with gxfb.<option>.
For example, gxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
================ ==================================================
mode_option specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram size of video ram (normally auto-detected)
vt_switch enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
================ ==================================================
--
Andres Salomon <dilinger@debian.org>

50
Documentation/fb/index.rst Normal file
View File

@@ -0,0 +1,50 @@
:orphan:
============
Frame Buffer
============
.. toctree::
:maxdepth: 1
api
arkfb
aty128fb
cirrusfb
cmap_xfbdev
deferred_io
efifb
ep93xx-fb
fbcon
framebuffer
gxfb
intel810
intelfb
internals
lxfb
matroxfb
metronomefb
modedb
pvr2fb
pxafb
s3fb
sa1100fb
sh7760fb
sisfb
sm501
sm712fb
sstfb
tgafb
tridentfb
udlfb
uvesafb
vesafb
viafb
vt8623fb
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

79
Documentation/fb/intel810.txt → Documentation/fb/intel810.rst
View File

@@ -1,26 +1,31 @@
================================
Intel 810/815 Framebuffer driver
Tony Daplas <adaplas@pol.net>
http://i810fb.sourceforge.net
================================
March 17, 2002
Tony Daplas <adaplas@pol.net>
First Released: July 2001
Last Update: September 12, 2005
================================================================
http://i810fb.sourceforge.net
March 17, 2002
First Released: July 2001
Last Update: September 12, 2005
A. Introduction
===============
This is a framebuffer driver for various Intel 810/815 compatible
graphics devices. These include:
Intel 810
Intel 810E
Intel 810-DC100
Intel 815 Internal graphics only, 100Mhz FSB
Intel 815 Internal graphics only
Intel 815 Internal graphics and AGP
- Intel 810
- Intel 810E
- Intel 810-DC100
- Intel 815 Internal graphics only, 100Mhz FSB
- Intel 815 Internal graphics only
- Intel 815 Internal graphics and AGP
B. Features
============
- Choice of using Discrete Video Timings, VESA Generalized Timing
Formula, or a framebuffer specific database to set the video mode
@@ -45,10 +50,11 @@ B. Features
- Can concurrently run with xfree86 running with native i810 drivers
- Hardware Cursor Support
- Supports EDID probing either by DDC/I2C or through the BIOS
C. List of available options
=============================
a. "video=i810fb"
enables the i810 driver
@@ -158,7 +164,7 @@ C. List of available options
(default = not set)
n. "dcolor"
Use directcolor visual instead of truecolor for pixel depths greater
Use directcolor visual instead of truecolor for pixel depths greater
than 8 bpp. Useful for color tuning, such as gamma control.
Recommendation: do not set
@@ -167,35 +173,37 @@ C. List of available options
o. <xres>x<yres>[-<bpp>][@<refresh>]
The driver will now accept specification of boot mode option. If this
is specified, the options 'xres' and 'yres' will be ignored. See
Documentation/fb/modedb.txt for usage.
Documentation/fb/modedb.rst for usage.
D. Kernel booting
=================
Separate each option/option-pair by commas (,) and the option from its value
with a colon (:) as in the following:
with a colon (:) as in the following::
video=i810fb:option1,option2:value2
video=i810fb:option1,option2:value2
Sample Usage
------------
In /etc/lilo.conf, add the line:
In /etc/lilo.conf, add the line::
append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
vsync1:50,vsync2:85,accel,mtrr"
append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
vsync1:50,vsync2:85,accel,mtrr"
This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer
will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
IMPORTANT:
You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination
supports I2C and has an EDID block, you can safely exclude hsync1, hsync2,
vsync1 and vsync2 parameters. These parameters will be taken from the EDID
block.
You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination
supports I2C and has an EDID block, you can safely exclude hsync1, hsync2,
vsync1 and vsync2 parameters. These parameters will be taken from the EDID
block.
E. Module options
==================
The module parameters are essentially similar to the kernel
parameters. The main difference is that you need to include a Boolean value
@@ -206,31 +214,32 @@ Example, to enable MTRR, include "mtrr=1".
Sample Usage
------------
Using the same setup as described above, load the module like this:
Using the same setup as described above, load the module like this::
modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
vsync2=85 accel=1 mtrr=1
vsync2=85 accel=1 mtrr=1
Or just add the following to a configuration file in /etc/modprobe.d/
Or just add the following to a configuration file in /etc/modprobe.d/::
options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
vsync2=85 accel=1 mtrr=1
and just do a
and just do a::
modprobe i810fb
F. Setup
=========
a. Do your usual method of configuring the kernel.
a. Do your usual method of configuring the kernel
make menuconfig/xconfig/config
make menuconfig/xconfig/config
b. Under "Code maturity level options" enable "Prompt for development
and/or incomplete code/drivers".
c. Enable agpgart support for the Intel 810/815 on-board graphics.
c. Enable agpgart support for the Intel 810/815 on-board graphics.
This is required. The option is under "Character Devices".
d. Under "Graphics Support", select "Intel 810/815" either statically
@@ -242,7 +251,7 @@ F. Setup
set 'Enable DDC Support' to 'y'. To make this option appear, set
'use VESA Generalized Timing Formula' to 'y'.
f. If you want a framebuffer console, enable it under "Console
f. If you want a framebuffer console, enable it under "Console
Drivers".
g. Compile your kernel.
@@ -253,6 +262,7 @@ F. Setup
patch to see the chipset in action (or inaction :-).
G. Acknowledgment:
===================
1. Geert Uytterhoeven - his excellent howto and the virtual
framebuffer driver code made this possible.
@@ -269,10 +279,9 @@ G. Acknowledgment:
optimizations possible.
H. Home Page:
==============
A more complete, and probably updated information is provided at
http://i810fb.sourceforge.net.
###########################
Tony

62
Documentation/fb/intelfb.txt → Documentation/fb/intelfb.rst
View File

@@ -1,24 +1,28 @@
=============================================================
Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
================================================================
=============================================================
A. Introduction
This is a framebuffer driver for various Intel 8xx/9xx compatible
===============
This is a framebuffer driver for various Intel 8xx/9xx compatible
graphics devices. These would include:
Intel 830M
Intel 845G
Intel 852GM
Intel 855GM
Intel 865G
Intel 915G
Intel 915GM
Intel 945G
Intel 945GM
Intel 945GME
Intel 965G
Intel 965GM
- Intel 830M
- Intel 845G
- Intel 852GM
- Intel 855GM
- Intel 865G
- Intel 915G
- Intel 915GM
- Intel 945G
- Intel 945GM
- Intel 945GME
- Intel 965G
- Intel 965GM
B. List of available options
=============================
a. "video=intelfb"
enables the intelfb driver
@@ -39,12 +43,12 @@ B. List of available options
(default = 4 MB)
d. "voffset=<value>"
select at what offset in MB of the logical memory to allocate the
select at what offset in MB of the logical memory to allocate the
framebuffer memory. The intent is to avoid the memory blocks
used by standard graphics applications (XFree86). Depending on your
usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
for the least amount). Note, an arbitrary setting may conflict
with XFree86.
usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
for the least amount). Note, an arbitrary setting may conflict
with XFree86.
Recommendation: do not set
(default = 48 MB)
@@ -80,18 +84,19 @@ B. List of available options
The default parameter (not named) is the mode.
C. Kernel booting
=================
Separate each option/option-pair by commas (,) and the option from its value
with an equals sign (=) as in the following:
with an equals sign (=) as in the following::
video=intelfb:option1,option2=value2
video=intelfb:option1,option2=value2
Sample Usage
------------
In /etc/lilo.conf, add the line:
In /etc/lilo.conf, add the line::
append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
@@ -106,8 +111,9 @@ in this directory.
D. Module options
==================
The module parameters are essentially similar to the kernel
The module parameters are essentially similar to the kernel
parameters. The main difference is that you need to include a Boolean value
(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
@@ -116,23 +122,24 @@ Example, to enable MTRR, include "mtrr=1".
Sample Usage
------------
Using the same setup as described above, load the module like this:
Using the same setup as described above, load the module like this::
modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
Or just add the following to a configuration file in /etc/modprobe.d/
Or just add the following to a configuration file in /etc/modprobe.d/::
options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
and just do a
and just do a::
modprobe intelfb
E. Acknowledgment:
===================
1. Geert Uytterhoeven - his excellent howto and the virtual
framebuffer driver code made this possible.
framebuffer driver code made this possible.
2. Jeff Hartmann for his agpgart code.
@@ -145,5 +152,4 @@ E. Acknowledgment:
6. Andrew Morton for his kernel patches maintenance.
###########################
Sylvain

24
Documentation/fb/internals.txt → Documentation/fb/internals.rst
View File

@@ -1,13 +1,19 @@
=============================
Frame Buffer device internals
=============================
This is a first start for some documentation about frame buffer device
internals.
Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
James Simmons <jsimmons@user.sf.net>, Nov 26 2002
Authors:
- Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
- James Simmons <jsimmons@user.sf.net>, Nov 26 2002
--------------------------------------------------------------------------------
*** STRUCTURES USED BY THE FRAME BUFFER DEVICE API ***
Structures used by the frame buffer device API
==============================================
The following structures play a role in the game of frame buffer devices. They
are defined in <linux/fb.h>.
@@ -40,19 +46,18 @@ are defined in <linux/fb.h>.
Generic information, API and low level information about a specific frame
buffer device instance (slot number, board address, ...).
- struct `par'
- struct `par`
Device dependent information that uniquely defines the video mode for this
particular piece of hardware.
--------------------------------------------------------------------------------
*** VISUALS USED BY THE FRAME BUFFER DEVICE API ***
Visuals used by the frame buffer device API
===========================================
Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
-------------------------------------------------
--------------------------------------------------
Each pixel is either black or white.
@@ -70,7 +75,7 @@ The pixel value is broken up into red, green, and blue fields.
Direct color (FB_VISUAL_DIRECTCOLOR)
------------------------------------
The pixel value is broken up into red, green, and blue fields, each of which
The pixel value is broken up into red, green, and blue fields, each of which
are looked up in separate red, green, and blue lookup tables.
@@ -79,4 +84,3 @@ Grayscale displays
Grayscale and static grayscale are special variants of pseudo color and static
pseudo color, where the red, green and blue components are always equal to
each other.

25
Documentation/fb/lxfb.txt → Documentation/fb/lxfb.rst
View File

@@ -1,7 +1,9 @@
[This file is cloned from VesaFB/aty128fb]
=============
What is lxfb?
=================
=============
.. [This file is cloned from VesaFB/aty128fb]
This is a graphics framebuffer driver for AMD Geode LX based processors.
@@ -23,9 +25,9 @@ How to use it?
==============
Switching modes is done using lxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
parameter or using `fbset` program.
See Documentation/fb/modedb.txt for more information on modedb
See Documentation/fb/modedb.rst for more information on modedb
resolutions.
@@ -42,11 +44,12 @@ You can pass kernel command line options to lxfb with lxfb.<option>.
For example, lxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
================ ==================================================
mode_option specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram size of video ram (normally auto-detected)
vt_switch enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
================ ==================================================
--
Andres Salomon <dilinger@debian.org>

443
Documentation/fb/matroxfb.rst Normal file
View File

@@ -0,0 +1,443 @@
=================
What is matroxfb?
=================
.. [This file is cloned from VesaFB. Thanks go to Gerd Knorr]
This is a driver for a graphic framebuffer for Matrox devices on
Alpha, Intel and PPC boxes.
Advantages:
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode... but you should not notice
if you use same resolution as you used in textmode.
How to use it?
==============
Switching modes is done using the video=matroxfb:vesa:... boot parameter
or using `fbset` program.
If you want, for example, enable a resolution of 1280x1024x24bpp you should
pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
You should compile in both vgacon (to boot if you remove you Matrox from
box) and matroxfb (for graphics mode). You should not compile-in vesafb
unless you have primary display on non-Matrox VBE2.0 device (see
Documentation/fb/vesafb.rst for details).
Currently supported video modes are (through vesa:... interface, PowerMac
has [as addon] compatibility code):
Graphic modes
-------------
=== ======= ======= ======= ======= =======
bpp 640x400 640x480 768x576 800x600 960x720
=== ======= ======= ======= ======= =======
4 0x12 0x102
8 0x100 0x101 0x180 0x103 0x188
15 0x110 0x181 0x113 0x189
16 0x111 0x182 0x114 0x18A
24 0x1B2 0x184 0x1B5 0x18C
32 0x112 0x183 0x115 0x18B
=== ======= ======= ======= ======= =======
Graphic modes (continued)
-------------------------
=== ======== ======== ========= ========= =========
bpp 1024x768 1152x864 1280x1024 1408x1056 1600x1200
=== ======== ======== ========= ========= =========
4 0x104 0x106
8 0x105 0x190 0x107 0x198 0x11C
15 0x116 0x191 0x119 0x199 0x11D
16 0x117 0x192 0x11A 0x19A 0x11E
24 0x1B8 0x194 0x1BB 0x19C 0x1BF
32 0x118 0x193 0x11B 0x19B
=== ======== ======== ========= ========= =========
Text modes
----------
==== ======= ======= ======== ======== ========
text 640x400 640x480 1056x344 1056x400 1056x480
==== ======= ======= ======== ======== ========
8x8 0x1C0 0x108 0x10A 0x10B 0x10C
8x16 2, 3, 7 0x109
==== ======= ======= ======== ======== ========
You can enter these number either hexadecimal (leading `0x`) or decimal
(0x100 = 256). You can also use value + 512 to achieve compatibility
with your old number passed to vesafb.
Non-listed number can be achieved by more complicated command-line, for
example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32`.
X11
===
XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
works fine.
Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
XFree servers have big troubles in multihead configurations (even on first
head, not even talking about second). Running XFree86 4.x accelerated mga
driver is possible, but you must not enable DRI - if you do, resolution and
color depth of your X desktop must match resolution and color depths of your
virtual consoles, otherwise X will corrupt accelerator settings.
SVGALib
=======
Driver contains SVGALib compatibility code. It is turned on by choosing textual
mode for console. You can do it at boot time by using videomode
2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0` does this work.
Unfortunately, after SVGALib application exits, screen contents is corrupted.
Switching to another console and back fixes it. I hope that it is SVGALib's
problem and not mine, but I'm not sure.
Configuration
=============
You can pass kernel command line options to matroxfb with
`video=matroxfb:option1,option2:value2,option3` (multiple options should be
separated by comma, values are separated from options by `:`).
Accepted options:
============ ===================================================================
mem:X size of memory (X can be in megabytes, kilobytes or bytes)
You can only decrease value determined by driver because of
it always probe for memory. Default is to use whole detected
memory usable for on-screen display (i.e. max. 8 MB).
disabled do not load driver; you can use also `off`, but `disabled`
is here too.
enabled load driver, if you have `video=matroxfb:disabled` in LILO
configuration, you can override it by this (you cannot override
`off`). It is default.
noaccel do not use acceleration engine. It does not work on Alphas.
accel use acceleration engine. It is default.
nopan create initial consoles with vyres = yres, thus disabling virtual
scrolling.
pan create initial consoles as tall as possible (vyres = memory/vxres).
It is default.
nopciretry disable PCI retries. It is needed for some broken chipsets,
it is autodetected for intel's 82437. In this case device does
not comply to PCI 2.1 specs (it will not guarantee that every
transaction terminate with success or retry in 32 PCLK).
pciretry enable PCI retries. It is default, except for intel's 82437.
novga disables VGA I/O ports. It is default if BIOS did not enable
device. You should not use this option, some boards then do not
restart without power off.
vga preserve state of VGA I/O ports. It is default. Driver does not
enable VGA I/O if BIOS did not it (it is not safe to enable it in
most cases).
nobios disables BIOS ROM. It is default if BIOS did not enable BIOS
itself. You should not use this option, some boards then do not
restart without power off.
bios preserve state of BIOS ROM. It is default. Driver does not enable
BIOS if BIOS was not enabled before.
noinit tells driver, that devices were already initialized. You should use
it if you have G100 and/or if driver cannot detect memory, you see
strange pattern on screen and so on. Devices not enabled by BIOS
are still initialized. It is default.
init driver initializes every device it knows about.
memtype specifies memory type, implies 'init'. This is valid only for G200
and G400 and has following meaning:
G200:
- 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
- 1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
- 2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
- 3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
- 4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
- 5 -> same as above
- 6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
- 7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
G400:
- 0 -> 2x512Kx16 SDRAM, 16/32MB
- 2x512Kx32 SGRAM, 16/32MB
- 1 -> 2x256Kx32 SGRAM, 8/16MB
- 2 -> 4x128Kx32 SGRAM, 8/16MB
- 3 -> 4x512Kx32 SDRAM, 32MB
- 4 -> 4x256Kx32 SGRAM, 16/32MB
- 5 -> 2x1Mx32 SDRAM, 32MB
- 6 -> reserved
- 7 -> reserved
You should use sdram or sgram parameter in addition to memtype
parameter.
nomtrr disables write combining on frame buffer. This slows down driver
but there is reported minor incompatibility between GUS DMA and
XFree under high loads if write combining is enabled (sound
dropouts).
mtrr enables write combining on frame buffer. It speeds up video
accesses much. It is default. You must have MTRR support enabled
in kernel and your CPU must have MTRR (f.e. Pentium II have them).
sgram tells to driver that you have Gxx0 with SGRAM memory. It has no
effect without `init`.
sdram tells to driver that you have Gxx0 with SDRAM memory.
It is a default.
inv24 change timings parameters for 24bpp modes on Millennium and
Millennium II. Specify this if you see strange color shadows
around characters.
noinv24 use standard timings. It is the default.
inverse invert colors on screen (for LCD displays)
noinverse show true colors on screen. It is default.
dev:X bind driver to device X. Driver numbers device from 0 up to N,
where device 0 is first `known` device found, 1 second and so on.
lspci lists devices in this order.
Default is `every` known device.
nohwcursor disables hardware cursor (use software cursor instead).
hwcursor enables hardware cursor. It is default. If you are using
non-accelerated mode (`noaccel` or `fbset -accel false`), software
cursor is used (except for text mode).
noblink disables cursor blinking. Cursor in text mode always blinks (hw
limitation).
blink enables cursor blinking. It is default.
nofastfont disables fastfont feature. It is default.
fastfont:X enables fastfont feature. X specifies size of memory reserved for
font data, it must be >= (fontwidth*fontheight*chars_in_font)/8.
It is faster on Gx00 series, but slower on older cards.
grayscale enable grayscale summing. It works in PSEUDOCOLOR modes (text,
4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
displayed through putc/putcs. Direct accesses to framebuffer
can paint colors.
nograyscale disable grayscale summing. It is default.
cross4MB enables that pixel line can cross 4MB boundary. It is default for
non-Millennium.
nocross4MB pixel line must not cross 4MB boundary. It is default for
Millennium I or II, because of these devices have hardware
limitations which do not allow this. But this option is
incompatible with some (if not all yet released) versions of
XF86_FBDev.
dfp enables digital flat panel interface. This option is incompatible
with secondary (TV) output - if DFP is active, TV output must be
inactive and vice versa. DFP always uses same timing as primary
(monitor) output.
dfp:X use settings X for digital flat panel interface. X is number from
0 to 0xFF, and meaning of each individual bit is described in
G400 manual, in description of DAC register 0x1F. For normal
operation you should set all bits to zero, except lowest bit. This
lowest bit selects who is source of display clocks, whether G400,
or panel. Default value is now read back from hardware - so you
should specify this value only if you are also using `init`
parameter.
outputs:XYZ set mapping between CRTC and outputs. Each letter can have value
of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter
corresponds to primary analog output, second letter to the
secondary analog output and third letter to the DVI output.
Default setting is 100 for cards below G400 or G400 without DFP,
101 for G400 with DFP, and 111 for G450 and G550. You can set
mapping only on first card, use matroxset for setting up other
devices.
vesa:X selects startup videomode. X is number from 0 to 0x1FF, see table
above for detailed explanation. Default is 640x480x8bpp if driver
has 8bpp support. Otherwise first available of 640x350x4bpp,
640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
(80x25 text is always available).
============ ===================================================================
If you are not satisfied with videomode selected by `vesa` option, you
can modify it with these options:
============ ===================================================================
xres:X horizontal resolution, in pixels. Default is derived from `vesa`
option.
yres:X vertical resolution, in pixel lines. Default is derived from `vesa`
option.
upper:X top boundary: lines between end of VSYNC pulse and start of first
pixel line of picture. Default is derived from `vesa` option.
lower:X bottom boundary: lines between end of picture and start of VSYNC
pulse. Default is derived from `vesa` option.
vslen:X length of VSYNC pulse, in lines. Default is derived from `vesa`
option.
left:X left boundary: pixels between end of HSYNC pulse and first pixel.
Default is derived from `vesa` option.
right:X right boundary: pixels between end of picture and start of HSYNC
pulse. Default is derived from `vesa` option.
hslen:X length of HSYNC pulse, in pixels. Default is derived from `vesa`
option.
pixclock:X dotclocks, in ps (picoseconds). Default is derived from `vesa`
option and from `fh` and `fv` options.
sync:X sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
generated. If bit 5 (value 0x20) is set, sync on green is turned
on. Do not forget that if you want sync on green, you also probably
want composite sync.
Default depends on `vesa`.
depth:X Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
`vesa`.
============ ===================================================================
If you know capabilities of your monitor, you can specify some (or all) of
`maxclk`, `fh` and `fv`. In this case, `pixclock` is computed so that
pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
============ ==================================================================
maxclk:X maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
`don`t care`.
fh:X maximum horizontal synchronization frequency. X can be specified
in kHz or Hz. Default is `don't care`.
fv:X maximum vertical frequency. X must be specified in Hz. Default is
70 for modes derived from `vesa` with yres <= 400, 60Hz for
yres > 400.
============ ==================================================================
Limitations
===========
There are known and unknown bugs, features and misfeatures.
Currently there are following known bugs:
- SVGALib does not restore screen on exit
- generic fbcon-cfbX procedures do not work on Alphas. Due to this,
`noaccel` (and cfb4 accel) driver does not work on Alpha. So everyone
with access to `/dev/fb*` on Alpha can hang machine (you should restrict
access to `/dev/fb*` - everyone with access to this device can destroy
your monitor, believe me...).
- 24bpp does not support correctly XF-FBDev on big-endian architectures.
- interlaced text mode is not supported; it looks like hardware limitation,
but I'm not sure.
- Gxx0 SGRAM/SDRAM is not autodetected.
- If you are using more than one framebuffer device, you must boot kernel
with 'video=scrollback:0'.
- maybe more...
And following misfeatures:
- SVGALib does not restore screen on exit.
- pixclock for text modes is limited by hardware to
- 83 MHz on G200
- 66 MHz on Millennium I
- 60 MHz on Millennium II
Because I have no access to other devices, I do not know specific
frequencies for them. So driver does not check this and allows you to
set frequency higher that this. It causes sparks, black holes and other
pretty effects on screen. Device was not destroyed during tests. :-)
- my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
(and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
them (maybe that chip overheats, but it has a very big cooler (G100 has
none), so it should work).
- special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
G16V16 are not supported
- color keying is not supported
- feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
by BIOS)
- DDC (monitor detection) is supported through dualhead driver
- some check for input values are not so strict how it should be (you can
specify vslen=4000 and so on).
- maybe more...
And following features:
- 4bpp is available only on Millennium I and Millennium II. It is hardware
limitation.
- selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba
option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
else selects 5:6:5 mode.
- text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
instead of one of 16M colors). It is due to hardware limitation of
Millennium I/II and SVGALib compatibility.
Benchmarks
==========
It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
time for draw 6144000 characters on screen through /dev/vcsa
(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in
16 seconds, i.e. 187 MBps).
Times were obtained from one older version of driver, now they are about 3%
faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
PCI slot, G200 in AGP 2x slot. I did not test vgacon::
NOACCEL
8x16 12x22
Millennium I G200 Millennium I G200
8bpp 16.42 9.54 12.33 9.13
16bpp 21.00 15.70 19.11 15.02
24bpp 36.66 36.66 35.00 35.00
32bpp 35.00 30.00 33.85 28.66
ACCEL, nofastfont
8x16 12x22 6x11
Millennium I G200 Millennium I G200 Millennium I G200
8bpp 7.79 7.24 13.55 7.78 30.00 21.01
16bpp 9.13 7.78 16.16 7.78 30.00 21.01
24bpp 14.17 10.72 18.69 10.24 34.99 21.01
32bpp 16.15 16.16 18.73 13.09 34.99 21.01
ACCEL, fastfont
8x16 12x22 6x11
Millennium I G200 Millennium I G200 Millennium I G200
8bpp 8.41 6.01 6.54 4.37 16.00 10.51
16bpp 9.54 9.12 8.76 6.17 17.52 14.01
24bpp 15.00 12.36 11.67 10.00 22.01 18.32
32bpp 16.18 18.29* 12.71 12.74 24.44 21.00
TEXT
8x16
Millennium I G200
TEXT 3.29 1.50
* Yes, it is slower than Millennium I.
Dualhead G400
=============
Driver supports dualhead G400 with some limitations:
+ secondary head shares videomemory with primary head. It is not problem
if you have 32MB of videoram, but if you have only 16MB, you may have
to think twice before choosing videomode (for example twice 1880x1440x32bpp
is not possible).
+ due to hardware limitation, secondary head can use only 16 and 32bpp
videomodes.
+ secondary head is not accelerated. There were bad problems with accelerated
XFree when secondary head used to use acceleration.
+ secondary head always powerups in 640x480@60-32 videomode. You have to use
fbset to change this mode.
+ secondary head always powerups in monitor mode. You have to use fbmatroxset
to change it to TV mode. Also, you must select at least 525 lines for
NTSC output and 625 lines for PAL output.
+ kernel is not fully multihead ready. So some things are impossible to do.
+ if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
and matroxfb_crtc2 into kernel.
Dualhead G450
=============
Driver supports dualhead G450 with some limitations:
+ secondary head shares videomemory with primary head. It is not problem
if you have 32MB of videoram, but if you have only 16MB, you may have
to think twice before choosing videomode.
+ due to hardware limitation, secondary head can use only 16 and 32bpp
videomodes.
+ secondary head is not accelerated.
+ secondary head always powerups in 640x480@60-32 videomode. You have to use
fbset to change this mode.
+ TV output is not supported
+ kernel is not fully multihead ready, so some things are impossible to do.
+ if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
into kernel.
Petr Vandrovec <vandrove@vc.cvut.cz>

413
Documentation/fb/matroxfb.txt
View File

@@ -1,413 +0,0 @@
[This file is cloned from VesaFB. Thanks go to Gerd Knorr]
What is matroxfb?
=================
This is a driver for a graphic framebuffer for Matrox devices on
Alpha, Intel and PPC boxes.
Advantages:
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode... but you should not notice
if you use same resolution as you used in textmode.
How to use it?
==============
Switching modes is done using the video=matroxfb:vesa:... boot parameter
or using `fbset' program.
If you want, for example, enable a resolution of 1280x1024x24bpp you should
pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
You should compile in both vgacon (to boot if you remove you Matrox from
box) and matroxfb (for graphics mode). You should not compile-in vesafb
unless you have primary display on non-Matrox VBE2.0 device (see
Documentation/fb/vesafb.txt for details).
Currently supported video modes are (through vesa:... interface, PowerMac
has [as addon] compatibility code):
[Graphic modes]
bpp | 640x400 640x480 768x576 800x600 960x720
----+--------------------------------------------
4 | 0x12 0x102
8 | 0x100 0x101 0x180 0x103 0x188
15 | 0x110 0x181 0x113 0x189
16 | 0x111 0x182 0x114 0x18A
24 | 0x1B2 0x184 0x1B5 0x18C
32 | 0x112 0x183 0x115 0x18B
[Graphic modes (continued)]
bpp | 1024x768 1152x864 1280x1024 1408x1056 1600x1200
----+------------------------------------------------
4 | 0x104 0x106
8 | 0x105 0x190 0x107 0x198 0x11C
15 | 0x116 0x191 0x119 0x199 0x11D
16 | 0x117 0x192 0x11A 0x19A 0x11E
24 | 0x1B8 0x194 0x1BB 0x19C 0x1BF
32 | 0x118 0x193 0x11B 0x19B
[Text modes]
text | 640x400 640x480 1056x344 1056x400 1056x480
-----+------------------------------------------------
8x8 | 0x1C0 0x108 0x10A 0x10B 0x10C
8x16 | 2, 3, 7 0x109
You can enter these number either hexadecimal (leading `0x') or decimal
(0x100 = 256). You can also use value + 512 to achieve compatibility
with your old number passed to vesafb.
Non-listed number can be achieved by more complicated command-line, for
example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.
X11
===
XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
works fine.
Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
XFree servers have big troubles in multihead configurations (even on first
head, not even talking about second). Running XFree86 4.x accelerated mga
driver is possible, but you must not enable DRI - if you do, resolution and
color depth of your X desktop must match resolution and color depths of your
virtual consoles, otherwise X will corrupt accelerator settings.
SVGALib
=======
Driver contains SVGALib compatibility code. It is turned on by choosing textual
mode for console. You can do it at boot time by using videomode
2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0' does this work.
Unfortunately, after SVGALib application exits, screen contents is corrupted.
Switching to another console and back fixes it. I hope that it is SVGALib's
problem and not mine, but I'm not sure.
Configuration
=============
You can pass kernel command line options to matroxfb with
`video=matroxfb:option1,option2:value2,option3' (multiple options should be
separated by comma, values are separated from options by `:').
Accepted options:
mem:X - size of memory (X can be in megabytes, kilobytes or bytes)
You can only decrease value determined by driver because of
it always probe for memory. Default is to use whole detected
memory usable for on-screen display (i.e. max. 8 MB).
disabled - do not load driver; you can use also `off', but `disabled'
is here too.
enabled - load driver, if you have `video=matroxfb:disabled' in LILO
configuration, you can override it by this (you cannot override
`off'). It is default.
noaccel - do not use acceleration engine. It does not work on Alphas.
accel - use acceleration engine. It is default.
nopan - create initial consoles with vyres = yres, thus disabling virtual
scrolling.
pan - create initial consoles as tall as possible (vyres = memory/vxres).
It is default.
nopciretry - disable PCI retries. It is needed for some broken chipsets,
it is autodetected for intel's 82437. In this case device does
not comply to PCI 2.1 specs (it will not guarantee that every
transaction terminate with success or retry in 32 PCLK).
pciretry - enable PCI retries. It is default, except for intel's 82437.
novga - disables VGA I/O ports. It is default if BIOS did not enable device.
You should not use this option, some boards then do not restart
without power off.
vga - preserve state of VGA I/O ports. It is default. Driver does not
enable VGA I/O if BIOS did not it (it is not safe to enable it in
most cases).
nobios - disables BIOS ROM. It is default if BIOS did not enable BIOS itself.
You should not use this option, some boards then do not restart
without power off.
bios - preserve state of BIOS ROM. It is default. Driver does not enable
BIOS if BIOS was not enabled before.
noinit - tells driver, that devices were already initialized. You should use
it if you have G100 and/or if driver cannot detect memory, you see
strange pattern on screen and so on. Devices not enabled by BIOS
are still initialized. It is default.
init - driver initializes every device it knows about.
memtype - specifies memory type, implies 'init'. This is valid only for G200
and G400 and has following meaning:
G200: 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
5 -> same as above
6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
G400: 0 -> 2x512Kx16 SDRAM, 16/32MB
2x512Kx32 SGRAM, 16/32MB
1 -> 2x256Kx32 SGRAM, 8/16MB
2 -> 4x128Kx32 SGRAM, 8/16MB
3 -> 4x512Kx32 SDRAM, 32MB
4 -> 4x256Kx32 SGRAM, 16/32MB
5 -> 2x1Mx32 SDRAM, 32MB
6 -> reserved
7 -> reserved
You should use sdram or sgram parameter in addition to memtype
parameter.
nomtrr - disables write combining on frame buffer. This slows down driver but
there is reported minor incompatibility between GUS DMA and XFree
under high loads if write combining is enabled (sound dropouts).
mtrr - enables write combining on frame buffer. It speeds up video accesses
much. It is default. You must have MTRR support enabled in kernel
and your CPU must have MTRR (f.e. Pentium II have them).
sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
effect without `init'.
sdram - tells to driver that you have Gxx0 with SDRAM memory.
It is a default.
inv24 - change timings parameters for 24bpp modes on Millennium and
Millennium II. Specify this if you see strange color shadows around
characters.
noinv24 - use standard timings. It is the default.
inverse - invert colors on screen (for LCD displays)
noinverse - show true colors on screen. It is default.
dev:X - bind driver to device X. Driver numbers device from 0 up to N,
where device 0 is first `known' device found, 1 second and so on.
lspci lists devices in this order.
Default is `every' known device.
nohwcursor - disables hardware cursor (use software cursor instead).
hwcursor - enables hardware cursor. It is default. If you are using
non-accelerated mode (`noaccel' or `fbset -accel false'), software
cursor is used (except for text mode).
noblink - disables cursor blinking. Cursor in text mode always blinks (hw
limitation).
blink - enables cursor blinking. It is default.
nofastfont - disables fastfont feature. It is default.
fastfont:X - enables fastfont feature. X specifies size of memory reserved for
font data, it must be >= (fontwidth*fontheight*chars_in_font)/8.
It is faster on Gx00 series, but slower on older cards.
grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
displayed through putc/putcs. Direct accesses to framebuffer
can paint colors.
nograyscale - disable grayscale summing. It is default.
cross4MB - enables that pixel line can cross 4MB boundary. It is default for
non-Millennium.
nocross4MB - pixel line must not cross 4MB boundary. It is default for
Millennium I or II, because of these devices have hardware
limitations which do not allow this. But this option is
incompatible with some (if not all yet released) versions of
XF86_FBDev.
dfp - enables digital flat panel interface. This option is incompatible with
secondary (TV) output - if DFP is active, TV output must be
inactive and vice versa. DFP always uses same timing as primary
(monitor) output.
dfp:X - use settings X for digital flat panel interface. X is number from
0 to 0xFF, and meaning of each individual bit is described in
G400 manual, in description of DAC register 0x1F. For normal operation
you should set all bits to zero, except lowest bit. This lowest bit
selects who is source of display clocks, whether G400, or panel.
Default value is now read back from hardware - so you should specify
this value only if you are also using `init' parameter.
outputs:XYZ - set mapping between CRTC and outputs. Each letter can have value
of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter corresponds
to primary analog output, second letter to the secondary analog output
and third letter to the DVI output. Default setting is 100 for
cards below G400 or G400 without DFP, 101 for G400 with DFP, and
111 for G450 and G550. You can set mapping only on first card,
use matroxset for setting up other devices.
vesa:X - selects startup videomode. X is number from 0 to 0x1FF, see table
above for detailed explanation. Default is 640x480x8bpp if driver
has 8bpp support. Otherwise first available of 640x350x4bpp,
640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
(80x25 text is always available).
If you are not satisfied with videomode selected by `vesa' option, you
can modify it with these options:
xres:X - horizontal resolution, in pixels. Default is derived from `vesa'
option.
yres:X - vertical resolution, in pixel lines. Default is derived from `vesa'
option.
upper:X - top boundary: lines between end of VSYNC pulse and start of first
pixel line of picture. Default is derived from `vesa' option.
lower:X - bottom boundary: lines between end of picture and start of VSYNC
pulse. Default is derived from `vesa' option.
vslen:X - length of VSYNC pulse, in lines. Default is derived from `vesa'
option.
left:X - left boundary: pixels between end of HSYNC pulse and first pixel.
Default is derived from `vesa' option.
right:X - right boundary: pixels between end of picture and start of HSYNC
pulse. Default is derived from `vesa' option.
hslen:X - length of HSYNC pulse, in pixels. Default is derived from `vesa'
option.
pixclock:X - dotclocks, in ps (picoseconds). Default is derived from `vesa'
option and from `fh' and `fv' options.
sync:X - sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
generated. If bit 5 (value 0x20) is set, sync on green is turned on.
Do not forget that if you want sync on green, you also probably
want composite sync.
Default depends on `vesa'.
depth:X - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
`vesa'.
If you know capabilities of your monitor, you can specify some (or all) of
`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that
pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
`don't care'.
fh:X - maximum horizontal synchronization frequency. X can be specified
in kHz or Hz. Default is `don't care'.
fv:X - maximum vertical frequency. X must be specified in Hz. Default is
70 for modes derived from `vesa' with yres <= 400, 60Hz for
yres > 400.
Limitations
===========
There are known and unknown bugs, features and misfeatures.
Currently there are following known bugs:
+ SVGALib does not restore screen on exit
+ generic fbcon-cfbX procedures do not work on Alphas. Due to this,
`noaccel' (and cfb4 accel) driver does not work on Alpha. So everyone
with access to /dev/fb* on Alpha can hang machine (you should restrict
access to /dev/fb* - everyone with access to this device can destroy
your monitor, believe me...).
+ 24bpp does not support correctly XF-FBDev on big-endian architectures.
+ interlaced text mode is not supported; it looks like hardware limitation,
but I'm not sure.
+ Gxx0 SGRAM/SDRAM is not autodetected.
+ If you are using more than one framebuffer device, you must boot kernel
with 'video=scrollback:0'.
+ maybe more...
And following misfeatures:
+ SVGALib does not restore screen on exit.
+ pixclock for text modes is limited by hardware to
83 MHz on G200
66 MHz on Millennium I
60 MHz on Millennium II
Because I have no access to other devices, I do not know specific
frequencies for them. So driver does not check this and allows you to
set frequency higher that this. It causes sparks, black holes and other
pretty effects on screen. Device was not destroyed during tests. :-)
+ my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
(and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
them (maybe that chip overheats, but it has a very big cooler (G100 has
none), so it should work).
+ special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
G16V16 are not supported
+ color keying is not supported
+ feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
by BIOS)
+ DDC (monitor detection) is supported through dualhead driver
+ some check for input values are not so strict how it should be (you can
specify vslen=4000 and so on).
+ maybe more...
And following features:
+ 4bpp is available only on Millennium I and Millennium II. It is hardware
limitation.
+ selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba
option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
else selects 5:6:5 mode.
+ text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
instead of one of 16M colors). It is due to hardware limitation of
Millennium I/II and SVGALib compatibility.
Benchmarks
==========
It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
time for draw 6144000 characters on screen through /dev/vcsa
(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in
16 seconds, i.e. 187 MBps).
Times were obtained from one older version of driver, now they are about 3%
faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
PCI slot, G200 in AGP 2x slot. I did not test vgacon.
NOACCEL
8x16 12x22
Millennium I G200 Millennium I G200
8bpp 16.42 9.54 12.33 9.13
16bpp 21.00 15.70 19.11 15.02
24bpp 36.66 36.66 35.00 35.00
32bpp 35.00 30.00 33.85 28.66
ACCEL, nofastfont
8x16 12x22 6x11
Millennium I G200 Millennium I G200 Millennium I G200
8bpp 7.79 7.24 13.55 7.78 30.00 21.01
16bpp 9.13 7.78 16.16 7.78 30.00 21.01
24bpp 14.17 10.72 18.69 10.24 34.99 21.01
32bpp 16.15 16.16 18.73 13.09 34.99 21.01
ACCEL, fastfont
8x16 12x22 6x11
Millennium I G200 Millennium I G200 Millennium I G200
8bpp 8.41 6.01 6.54 4.37 16.00 10.51
16bpp 9.54 9.12 8.76 6.17 17.52 14.01
24bpp 15.00 12.36 11.67 10.00 22.01 18.32
32bpp 16.18 18.29* 12.71 12.74 24.44 21.00
TEXT
8x16
Millennium I G200
TEXT 3.29 1.50
* Yes, it is slower than Millennium I.
Dualhead G400
=============
Driver supports dualhead G400 with some limitations:
+ secondary head shares videomemory with primary head. It is not problem
if you have 32MB of videoram, but if you have only 16MB, you may have
to think twice before choosing videomode (for example twice 1880x1440x32bpp
is not possible).
+ due to hardware limitation, secondary head can use only 16 and 32bpp
videomodes.
+ secondary head is not accelerated. There were bad problems with accelerated
XFree when secondary head used to use acceleration.
+ secondary head always powerups in 640x480@60-32 videomode. You have to use
fbset to change this mode.
+ secondary head always powerups in monitor mode. You have to use fbmatroxset
to change it to TV mode. Also, you must select at least 525 lines for
NTSC output and 625 lines for PAL output.
+ kernel is not fully multihead ready. So some things are impossible to do.
+ if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
and matroxfb_crtc2 into kernel.
Dualhead G450
=============
Driver supports dualhead G450 with some limitations:
+ secondary head shares videomemory with primary head. It is not problem
if you have 32MB of videoram, but if you have only 16MB, you may have
to think twice before choosing videomode.
+ due to hardware limitation, secondary head can use only 16 and 32bpp
videomodes.
+ secondary head is not accelerated.
+ secondary head always powerups in 640x480@60-32 videomode. You have to use
fbset to change this mode.
+ TV output is not supported
+ kernel is not fully multihead ready, so some things are impossible to do.
+ if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
into kernel.
--
Petr Vandrovec <vandrove@vc.cvut.cz>

8
Documentation/fb/metronomefb.txt → Documentation/fb/metronomefb.rst
View File

@@ -1,6 +1,9 @@
Metronomefb
-----------
===========
Metronomefb
===========
Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
Last revised: Mar 10, 2008
Metronomefb is a driver for the Metronome display controller. The controller
@@ -33,4 +36,3 @@ the physical media.
Metronomefb uses the deferred IO interface so that it can provide a memory
mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known
to work at this time with xeyes, xclock, xloadimage, xpdf.

Some files were not shown because too many files have changed in this diff Show More