|
http://www.linuxquestions.org/questions/linux-newbie-8/vesa-question-738166/ Video Vesa Internals: >From arch/x86/boot/video.c: 307 void set_video(void) 308 { 309 u16 mode = boot_params.hdr.vid_mode; 310 311 RESET_HEAP(); 312 313 store_mode_params(); 314 save_screen(); 315 probe_cards(0); 316 317 for (;;) { 318 if (mode == ASK_VGA) 319 mode = mode_menu(); 320 321 if (!set_mode(mode)) 322 break; 323 324 printf("Undefined video mode number: %x\n", mode); 325 mode = ASK_VGA; 326 } 327 boot_params.hdr.vid_mode = mode; 328 vesa_store_edid(); 329 store_mode_params(); 330 331 if (do_restore) 332 restore_screen(); 333 } And this in turned in called from main.c (in the same boot directory): main(): 128 void main(void) 129 { 130 /* First, copy the boot header into the "zeropage" */ 131 copy_boot_params(); 132 133 /* End of heap check */ 134 init_heap(); 135 136 /* Make sure we have all the proper CPU support */ 137 if (validate_cpu()) { 138 puts("Unable to boot - please use a kernel appropriate " 139 "for your CPU.\n"); 140 die(); 141 } 142 143 /* Tell the BIOS what CPU mode we intend to run in. */ 144 set_bios_mode(); 145 146 /* Detect memory layout */ 147 detect_memory(); 148 149 /* Set keyboard repeat rate (why?) */ 150 keyboard_set_repeat(); 151 152 /* Query MCA information */ 153 query_mca(); 154 155 /* Query Intel SpeedStep (IST) information */ 156 query_ist(); 157 158 /* Query APM information */ 159 #if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE) 160 query_apm_bios(); 161 #endif 162 163 /* Query EDD information */ 164 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE) 165 query_edd(); 166 #endif 167 168 /* Set the video mode */ 169 set_video(); 170 171 /* Parse command line for 'quiet' and pass it to decompressor. */ 172 if (cmdline_find_option_bool("quiet")) 173 boot_params.hdr.loadflags |= QUIET_FLAG; 174 175 /* Do the last things and invoke protected mode */ 176 go_to_protected_mode(); 177 } And vesa_store_edid() execute as: "arch/x86/boot/video-vesa.c" 285L, 7024C 238 /* 239 * Save EDID information for the kernel; this is invoked, separately, 240 * after mode-setting. 241 */ 242 void vesa_store_edid(void) 243 { 244 #ifdef CONFIG_FIRMWARE_EDID 245 struct biosregs ireg, oreg; 246 247 /* Apparently used as a nonsense token... */ 248 memset(&boot_params.edid_info, 0x13, sizeof boot_params.edid_info); 249 250 if (vginfo.version < 0x0200) 251 return; /* EDID requires VBE 2.0+ */ 252 253 initregs(&ireg); 254 ireg.ax = 0x4f15; /* VBE DDC */ 255 /* ireg.bx = 0x0000; */ /* Report DDC capabilities */ 256 /* ireg.cx = 0; */ /* Controller 0 */ 257 ireg.es = 0; /* ES:DI must be 0 by spec */ 258 intcall(0x10, &ireg, &oreg); 259 260 if (oreg.ax != 0x004f) 261 return; /* No EDID */ 262 263 /* BH = time in seconds to transfer EDD information */ 264 /* BL = DDC level supported */ 265 266 ireg.ax = 0x4f15; /* VBE DDC */ 267 ireg.bx = 0x0001; /* Read EDID */ 268 /* ireg.cx = 0; */ /* Controller 0 */ 269 /* ireg.dx = 0; */ /* EDID block number */ 270 ireg.es = ds(); 271 ireg.di =(size_t)&boot_params.edid_info; /* (ES:)Pointer to block */ 272 intcall(0x10, &ireg, &oreg); >From Documentation/fb/vesa.txt: What is vesafb? =============== This is a generic driver for a graphic framebuffer on intel boxes. The idea is simple: Turn on graphics mode at boot time with the help of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k (and other) ports do. This means we decide at boot time whenever we want to run in text or graphics mode. Switching mode later on (in protected mode) is impossible; BIOS calls work in real mode only. VESA BIOS Extensions Version 2.0 are required, because we need a linear frame buffer. Advantages: * It provides a nice large console (128 cols + 48 lines with 1024x768) without using tiny, unreadable fonts. * You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11 support for every VBE 2.0 compliant graphics board). * Most important: boot logo :-) Disadvantages: * graphic mode is slower than text mode... How to use it? ============== Switching modes is done using the vga=... boot parameter. Read Documentation/svga.txt for details. You should compile in both vgacon (for text mode) and vesafb (for graphics mode). Which of them takes over the console depends on whenever the specified mode is text or graphics. The graphic modes are NOT in the list which you get if you boot with vga=ask and hit return. The mode you wish to use is derived from the VESA mode number. Here are those VESA mode numbers: | 640x480 800x600 1024x768 1280x1024 ----+------------------------------------- 256 | 0x101 0x103 0x105 0x107 32k | 0x110 0x113 0x116 0x119 64k | 0x111 0x114 0x117 0x11A 16M | 0x112 0x115 0x118 0x11B The video mode number of the Linux kernel is the VESA mode number plus 0x200. Linux_kernel_mode_number = VESA_mode_number + 0x200 So the table for the Kernel mode numbers are: | 640x480 800x600 1024x768 1280x1024 ----+------------------------------------- 256 | 0x301 0x303 0x305 0x307 32k | 0x310 0x313 0x316 0x319 64k | 0x311 0x314 0x317 0x31A 16M | 0x312 0x315 0x318 0x31B To enable one of those modes you have to specify "vga=ask" in the lilo.conf file and rerun LILO. Then you can type in the desired mode at the "vga=ask" prompt. For example if you like to use 1024x768x256 colors you have to say "305" at this prompt. If this does not work, this might be because your BIOS does not support linear framebuffers or because it does not support this mode at all. Even if your board does, it might be the BIOS which does not. VESA BIOS Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a "bad mode number" message if something goes wrong. 1. Note: LILO cannot handle hex, for booting directly with "vga=mode-number" you have to transform the numbers to decimal. 2. Note: Some newer versions of LILO appear to work with those hex values, if you set the 0x in front of the numbers. X11 === XF68_FBDev should work just fine, but it is non-accelerated. Running another (accelerated) X-Server like XF86_SVGA might or might not work. It depends on X-Server and graphics board. The X-Server must restore the video mode correctly, else you end up with a broken console (and vesafb cannot do anything about this). Refresh rates ============= There is no way to change the vesafb video mode and/or timings after booting linux. If you are not happy with the 60 Hz refresh rate, you have these options: * configure and load the DOS-Tools for the graphics board (if available) and boot linux with loadlin. * use a native driver (matroxfb/atyfb) instead if vesafb. If none is available, write a new one! * VBE 3.0 might work too. I have neither a gfx board with VBE 3.0 support nor the specs, so I have not checked this yet. Configuration ============= The VESA BIOS provides protected mode interface for changing some parameters. vesafb can use it for palette changes and to pan the display. It is turned off by default because it seems not to work with some BIOS versions, but there are options to turn it on. You can pass options to vesafb using "video=vesafb:option" on the kernel command line. Multiple options should be separated by comma, like this: "video=vesafb:ypan,invers" Accepted options: invers no comment... ypan enable display panning using the VESA protected mode interface. The visible screen is just a window of the video memory, console scrolling is done by changing the start of the window. pro: * scrolling (fullscreen) is fast, because there is no need to copy around data. * You'll get scrollback (the Shift-PgUp thing), the video memory can be used as scrollback buffer kontra: * scrolling only parts of the screen causes some ugly flicker effects (boot logo flickers for example). ywrap Same as ypan, but assumes your gfx board can wrap-around the video memory (i.e. starts reading from top if it reaches the end of video memory). Faster than ypan. redraw scroll by redrawing the affected part of the screen, this is the safe (and slow) default. vgapal Use the standard vga registers for palette changes. This is the default. pmipal Use the protected mode interface for palette changes. mtrr:n setup memory type range registers for the vesafb framebuffer where n: 0 - disabled (equivalent to nomtrr) (default) 1 - uncachable 2 - write-back 3 - write-combining 4 - write-through If you see the following in dmesg, choose the type that matches the old one. In this example, use "mtrr:2". ... mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining ... nomtrr disable mtrr vremap:n remap 'n' MiB of video RAM. If 0 or not specified, remap memory according to video mode. (2.5.66 patch/idea by Antonino Daplas reversed to give override possibility (allocate more fb memory than the kernel would) to 2.4 by [email protected]) vtotal:n if the video BIOS of your card incorrectly determines the total amount of video RAM, use this option to override the BIOS (in MiB). And more info on CONFIG: http://cateee.net/lkddb/web-lkddb/FB_VESA.html And all of the above is executed whether CONFIG_FB_VESA is set or not. More CONFIG_FB_VESA internals next. |
