]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | |
2 | What is vesafb? | |
3 | =============== | |
4 | ||
5 | This is a generic driver for a graphic framebuffer on intel boxes. | |
6 | ||
7 | The idea is simple: Turn on graphics mode at boot time with the help | |
8 | of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k | |
9 | (and other) ports do. | |
10 | ||
11 | This means we decide at boot time whenever we want to run in text or | |
12 | graphics mode. Switching mode later on (in protected mode) is | |
13 | impossible; BIOS calls work in real mode only. VESA BIOS Extensions | |
14 | Version 2.0 are required, because we need a linear frame buffer. | |
15 | ||
16 | Advantages: | |
17 | ||
18 | * It provides a nice large console (128 cols + 48 lines with 1024x768) | |
19 | without using tiny, unreadable fonts. | |
20 | * You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11 | |
21 | support for every VBE 2.0 compliant graphics board). | |
22 | * Most important: boot logo :-) | |
23 | ||
24 | Disadvantages: | |
25 | ||
26 | * graphic mode is slower than text mode... | |
27 | ||
28 | ||
29 | How to use it? | |
30 | ============== | |
31 | ||
32 | Switching modes is done using the vga=... boot parameter. Read | |
33 | Documentation/svga.txt for details. | |
34 | ||
35 | You should compile in both vgacon (for text mode) and vesafb (for | |
36 | graphics mode). Which of them takes over the console depends on | |
37 | whenever the specified mode is text or graphics. | |
38 | ||
39 | The graphic modes are NOT in the list which you get if you boot with | |
40 | vga=ask and hit return. The mode you wish to use is derived from the | |
41 | VESA mode number. Here are those VESA mode numbers: | |
42 | ||
43 | | 640x480 800x600 1024x768 1280x1024 | |
44 | ----+------------------------------------- | |
45 | 256 | 0x101 0x103 0x105 0x107 | |
46 | 32k | 0x110 0x113 0x116 0x119 | |
47 | 64k | 0x111 0x114 0x117 0x11A | |
48 | 16M | 0x112 0x115 0x118 0x11B | |
49 | ||
50 | The video mode number of the Linux kernel is the VESA mode number plus | |
51 | 0x200. | |
52 | ||
53 | Linux_kernel_mode_number = VESA_mode_number + 0x200 | |
54 | ||
55 | So the table for the Kernel mode numbers are: | |
56 | ||
57 | | 640x480 800x600 1024x768 1280x1024 | |
58 | ----+------------------------------------- | |
59 | 256 | 0x301 0x303 0x305 0x307 | |
60 | 32k | 0x310 0x313 0x316 0x319 | |
61 | 64k | 0x311 0x314 0x317 0x31A | |
62 | 16M | 0x312 0x315 0x318 0x31B | |
63 | ||
64 | To enable one of those modes you have to specify "vga=ask" in the | |
65 | lilo.conf file and rerun LILO. Then you can type in the desired | |
66 | mode at the "vga=ask" prompt. For example if you like to use | |
67 | 1024x768x256 colors you have to say "305" at this prompt. | |
68 | ||
69 | If this does not work, this might be because your BIOS does not support | |
70 | linear framebuffers or because it does not support this mode at all. | |
71 | Even if your board does, it might be the BIOS which does not. VESA BIOS | |
72 | Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a | |
73 | "bad mode number" message if something goes wrong. | |
74 | ||
75 | 1. Note: LILO cannot handle hex, for booting directly with | |
76 | "vga=mode-number" you have to transform the numbers to decimal. | |
77 | 2. Note: Some newer versions of LILO appear to work with those hex values, | |
78 | if you set the 0x in front of the numbers. | |
79 | ||
80 | X11 | |
81 | === | |
82 | ||
83 | XF68_FBDev should work just fine, but it is non-accelerated. Running | |
84 | another (accelerated) X-Server like XF86_SVGA might or might not work. | |
85 | It depends on X-Server and graphics board. | |
86 | ||
87 | The X-Server must restore the video mode correctly, else you end up | |
88 | with a broken console (and vesafb cannot do anything about this). | |
89 | ||
90 | ||
91 | Refresh rates | |
92 | ============= | |
93 | ||
94 | There is no way to change the vesafb video mode and/or timings after | |
95 | booting linux. If you are not happy with the 60 Hz refresh rate, you | |
96 | have these options: | |
97 | ||
2d9d2fdf | 98 | * configure and load the DOS-Tools for the graphics board (if |
1da177e4 LT |
99 | available) and boot linux with loadlin. |
100 | * use a native driver (matroxfb/atyfb) instead if vesafb. If none | |
101 | is available, write a new one! | |
102 | * VBE 3.0 might work too. I have neither a gfx board with VBE 3.0 | |
103 | support nor the specs, so I have not checked this yet. | |
104 | ||
105 | ||
106 | Configuration | |
107 | ============= | |
108 | ||
109 | The VESA BIOS provides protected mode interface for changing | |
110 | some parameters. vesafb can use it for palette changes and | |
111 | to pan the display. It is turned off by default because it | |
112 | seems not to work with some BIOS versions, but there are options | |
113 | to turn it on. | |
114 | ||
115 | You can pass options to vesafb using "video=vesafb:option" on | |
116 | the kernel command line. Multiple options should be separated | |
117 | by comma, like this: "video=vesafb:ypan,invers" | |
118 | ||
119 | Accepted options: | |
120 | ||
121 | invers no comment... | |
122 | ||
123 | ypan enable display panning using the VESA protected mode | |
124 | interface. The visible screen is just a window of the | |
125 | video memory, console scrolling is done by changing the | |
126 | start of the window. | |
127 | pro: * scrolling (fullscreen) is fast, because there is | |
128 | no need to copy around data. | |
129 | * You'll get scrollback (the Shift-PgUp thing), | |
130 | the video memory can be used as scrollback buffer | |
131 | kontra: * scrolling only parts of the screen causes some | |
132 | ugly flicker effects (boot logo flickers for | |
133 | example). | |
134 | ||
135 | ywrap Same as ypan, but assumes your gfx board can wrap-around | |
136 | the video memory (i.e. starts reading from top if it | |
137 | reaches the end of video memory). Faster than ypan. | |
138 | ||
139 | redraw scroll by redrawing the affected part of the screen, this | |
140 | is the safe (and slow) default. | |
141 | ||
142 | ||
143 | vgapal Use the standard vga registers for palette changes. | |
144 | This is the default. | |
145 | pmipal Use the protected mode interface for palette changes. | |
146 | ||
d7a465b4 AD |
147 | mtrr:n setup memory type range registers for the vesafb framebuffer |
148 | where n: | |
8a0934f2 | 149 | 0 - disabled (equivalent to nomtrr) (default) |
d7a465b4 AD |
150 | 1 - uncachable |
151 | 2 - write-back | |
8a0934f2 | 152 | 3 - write-combining |
d7a465b4 AD |
153 | 4 - write-through |
154 | ||
155 | If you see the following in dmesg, choose the type that matches the | |
156 | old one. In this example, use "mtrr:2". | |
157 | ... | |
158 | mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining | |
159 | ... | |
160 | ||
161 | nomtrr disable mtrr | |
1da177e4 LT |
162 | |
163 | vremap:n | |
164 | remap 'n' MiB of video RAM. If 0 or not specified, remap memory | |
165 | according to video mode. (2.5.66 patch/idea by Antonino Daplas | |
166 | reversed to give override possibility (allocate more fb memory | |
167 | than the kernel would) to 2.4 by [email protected]) | |
168 | ||
169 | vtotal:n | |
170 | if the video BIOS of your card incorrectly determines the total | |
171 | amount of video RAM, use this option to override the BIOS (in MiB). | |
172 | ||
173 | Have fun! | |
174 | ||
175 | Gerd | |
176 | ||
177 | -- | |
178 | Gerd Knorr <[email protected]> | |
179 | ||
180 | Minor (mostly typo) changes | |
181 | by Nico Schmoigl <[email protected]> |