diff --git a/Documentation/fb/vesafb.txt b/Documentation/fb/vesafb.txt index ee277dd..93d6e6e 100644 --- a/Documentation/fb/vesafb.txt +++ b/Documentation/fb/vesafb.txt @@ -2,16 +2,18 @@ What is vesafb? =============== -This is a generic driver for a graphic framebuffer on intel boxes. +Vesafb is a generic framebuffer driver for x86 and x86_64 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. +VESA BIOS Extensions Version 2.0 are required, because we need access to +a linear frame buffer. VBE 3.0 is required if you want to use modes with a +higher (than the standard 60 Hz) refresh rate. -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. +The VESA framebuffer driver comes in two flavors - the standard 'vesafb' +and 'vesafb-tng'. Vesafb-tng is available only on 32-bit x86 due to the +technology it uses (vm86). Vesafb-tng has more features than vesafb +(adjusting the refresh rate on VBE 3.0 compliant boards, switching the +video mode without rebooting, selecting a mode by providing its +modedb name, and more). Advantages: @@ -29,26 +31,35 @@ Disadvantages: How to use it? ============== -Switching modes is done using the vga=... boot parameter. Read -Documentation/svga.txt for details. +If you are running a 32-bit x86 system and you decide to use vesafb-tng, +you can either compile the driver into the kernel or use it as a module. +The graphics mode you want to use is in both cases specified using the +standard modedb format. -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. +If your system doesn't support vm86 calls, things get a little more tricky. +Since on such systems you can't do BIOS calls from protected mode in which +kernel runs, you have to decide at boot time whenever you want to run in text +or in graphics mode. Switching mode later on is impossible. Switching modes +is done using the vga=... boot parameter. Read Documentation/svga.txt for +details. Below is a more detailed description of what to do on systems using +the standard vesafb driver. -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: +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 +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. +The video mode number of the Linux kernel is the VESA mode number plus 0x200. Linux_kernel_mode_number = VESA_mode_number + 0x200 @@ -56,15 +67,15 @@ 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 +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. +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. @@ -72,11 +83,12 @@ 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 +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 === @@ -84,98 +96,164 @@ 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 +The X-Server must restore the video mode correctly, or else you end up with a broken console (and vesafb cannot do anything about this). +With vesafb-tng chances are that the console will be restored properly +even if the X server messes up the video mode. 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: +With VBE 3.0 compatible BIOSes and vesafb-tng it is possible to change +the refresh rate either at boot time (by specifying the @ part of +the mode name) or later, using the fbset utility. + +If you want to use the default BIOS refresh rate while switching modes +on a running system, set pixclock to 0. - * configure and load the DOS-Tools for your the graphics board (if - available) and boot linux with loadlin. - * use a native driver (matroxfb/atyfb) instead if vesafb. If none +With VBE 2.0 there is no way to change the mode timings after booting +Linux. If you are not happy with the 60 Hz refresh rate, you have +the following options: + + * Configure and load the DOS tools for your the graphics board (if + available) and boot Linux with loadlin. + * Use a native driver (matroxfb/atyfb) instead of 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. + * Use a BIOS editor to change the default refresh rate (such an + editor does exist at least for ATI Radeon BIOSes). + * If you're running a non-vm86 and VBE 3.0 compatible system, you can + use a kernel patch (vesafb-rrc) to hard-code some mode timings in + the kernel and use these while setting the video mode at boot time. + +Note that there are some boards (nVidia 59**, 57** and newer models) +claiming that their Video BIOS is VBE 3.0 compliant, while ignoring the +CRTC values provided by software such as vesafb-tng. You'll not be able +to adjust the refresh rate if you're using one of these boards. 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". +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 a comma, like this: +"video=vesafb:ypan,1024x768-32@85" + +Note that vesafb-tng still uses the "video=vesafb:option" format of the +kernel command line video parameter. "video=vesafb-tng:xxx" is incorrect. + +Accepted options (both vesafb and vesafb-tng): + +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 + con: * 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. + +pmipal Use the protected mode interface for palette changes. + This is the default is the protected mode interface is available. + +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 +nomtrr Do not use memory type range registers for vesafb. 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 tmb@iki.fi) + 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 tmb@iki.fi) 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). -Have fun! +Options accepted only by vesafb-tng: + + The mode you want to set, in the standard modedb format. Refer to + modedb.txt for a detailed description. If you specify a mode that is + not supported by your board's BIOS, vesafb-tng will attempt to set a + similar mode. The list of supported modes can be found in + /proc/fbx/modes, where x is the framebuffer number (usually 0). + When vesafb-tng is compiled as a module, the mode string should be + provided as a value of the parameter 'mode'. + +vbemode:x + Force the use of VBE mode x. The mode will only be set if it's + found in the VBE-provided list of supported modes. + NOTE: The mode number 'x' should be specified in VESA mode number + notation, not the Linux kernel one (eg. 257 instead of 769). + HINT: If you use this option because normal parameter does + not work for you and you use a X server, you'll probably want to + set the 'nocrtc' option to ensure that the video mode is properly + restored after console <-> X switches. + +nocrtc Do not use CRTC timings while setting the video mode. This option + makes sence only with VBE 3.0 compliant systems. Use it if you have + problems with modes set in the standard way. Note that using this + option means that any refresh rate adjustments will be ignored + and the refresh rate will stay at your BIOS default (60 Hz). + +noedid Do not try to fetch and use EDID-provided modes. + +noblank Disable hardware blanking. + +gtf Force the use of VESA's GTF (Generalized Timing Formula). Specifying + this will cause vesafb to skip its internal modedb and EDID-modedb + and jump straight to the GTF part of the code (normally used only if + everything else failed). This can be useful if you want to get as + much as possible from your graphics board but your BIOS doesn't + support modes with the refresh rates you require. Note that you may + need to specify the maxhf, maxvf and maxclk parameters if they are not + provided by the EDID block. + +Additionally, the following parameters may be provided. They all override the +EDID-provided values and BIOS defaults. Refer to your monitor's specs to get +the correct values for maxhf, maxvf and maxclk for your hardware. + +maxhf:n Maximum horizontal frequency (in kHz). +maxvf:n Maximum vertical frequency (in Hz). +maxclk:n Maximum pixel clock (in MHz). - Gerd +Have fun! -- +Original document for the vesafb driver by Gerd Knorr -Minor (mostly typo) changes -by Nico Schmoigl +Minor (mostly typo) changes by +Nico Schmoigl + +Extended documentation for vm86, VBE 3.0 and vesafb-tng by +Michal Januszewski + diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S index 2c5b5cc..2c2d4b5 100644 --- a/arch/i386/boot/video.S +++ b/arch/i386/boot/video.S @@ -163,10 +163,12 @@ basret: ret # parameters in the default 80x25 mode -- these are set directly, # because some very obscure BIOSes supply insane values. mode_params: +#ifdef CONFIG_FB_VESA_STD #ifdef CONFIG_VIDEO_SELECT cmpb $0, graphic_mode jnz mopar_gr #endif +#endif movb $0x03, %ah # Read cursor position xorb %bh, %bh int $0x10 @@ -199,6 +201,7 @@ mopar2: movb %al, %fs:(PARAM_VIDEO_LINES) ret #ifdef CONFIG_VIDEO_SELECT +#ifdef CONFIG_FB_VESA_STD # Fetching of VESA frame buffer parameters mopar_gr: leaw modelist+1024, %di @@ -281,6 +284,7 @@ dac_done: movw %es, %fs:(PARAM_VESAPM_SEG) movw %di, %fs:(PARAM_VESAPM_OFF) no_pm: ret +#endif # The video mode menu mode_menu: @@ -495,10 +499,12 @@ mode_set: cmpb $VIDEO_FIRST_V7>>8, %ah jz setv7 - + +#ifdef CONFIG_FB_VESA_STD cmpb $VIDEO_FIRST_VESA>>8, %ah jnc check_vesa - +#endif + orb %ah, %ah jz setmenu @@ -570,6 +576,7 @@ setr1: lodsw movw -4(%si), %ax # Fetch mode ID jmp _m_s +#ifdef CONFIG_FB_VESA_STD check_vesa: leaw modelist+1024, %di subb $VIDEO_FIRST_VESA>>8, %bh @@ -603,6 +610,7 @@ check_vesa: ret _setbad: jmp setbad # Ugly... +#endif # Recalculate vertical display end registers -- this fixes various # inconsistencies of extended modes on many adapters. Called when diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c index 1393523..8a05f95 100644 --- a/drivers/char/sysrq.c +++ b/drivers/char/sysrq.c @@ -240,7 +240,7 @@ static void send_sig_all(int sig) struct task_struct *p; for_each_process(p) { - if (p->mm && !is_init(p)) + if (p->mm && !is_init(p) && !(p->flags & PF_BORROWED_MM)) /* Not swapper, init nor kernel thread */ force_sig(sig, p); } diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 4e83f01..ae122fd 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -547,8 +547,22 @@ config FB_TGA cards. Say Y if you have one of those. config FB_VESA - bool "VESA VGA graphics support" - depends on (FB = y) && X86 + tristate "VESA VGA graphics support" + depends on (FB = y) && (X86 || X86_64) + help + This is the frame buffer device driver for generic VESA 2.0 + compliant graphic cards. The older VESA 1.2 cards are not supported. + You will get a boot time penguin logo at no additional cost. Please + read . If unsure, say Y. + +choice + prompt "VESA driver type" + depends on FB_VESA + default FB_VESA_STD if X86_64 + default FB_VESA_TNG if X86 + +config FB_VESA_STD + bool "vesafb" select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -557,7 +571,43 @@ config FB_VESA This is the frame buffer device driver for generic VESA 2.0 compliant graphic cards. The older VESA 1.2 cards are not supported. You will get a boot time penguin logo at no additional cost. Please - read . If unsure, say Y. + read . Choose this driver if you + are experiencing problems with vesafb-tng or if you own a 64-bit system. + + Note that this driver cannot be compiled as a module. + +config FB_VESA_TNG + bool "vesafb-tng" + depends on !X86_64 + select FB_MODE_HELPERS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + help + This is an enhanced generic frame buffer device driver for + VBE 2.0 compliant graphic cards. It can take advantage of VBE 3.0 + features (refresh rate adjustment) when these are available. + The driver also makes it possible to change the video mode + on the fly and to switch back to text mode when it's unloaded. + + If the driver is compiled as a module, the module will be called + vesafb-tng. + +endchoice + +config FB_VESA_DEFAULT_MODE + string "VESA default mode" + depends on FB_VESA_TNG + default "640x480@60" + help + This option is used to determine the default mode vesafb is + supposed to switch to in case no mode is provided as a kernel + command line parameter. + +config VIDEO_SELECT + bool + depends on FB_VESA + default y config FB_IMAC bool "Intel-based Macintosh Framebuffer Support" diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 309a26d..e57b0e7 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -102,7 +102,11 @@ obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx4008/ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o # Platform or fallback drivers go here -obj-$(CONFIG_FB_VESA) += vesafb.o +ifeq ($(CONFIG_FB_VESA_STD),y) + obj-y += vesafb.o +else + obj-$(CONFIG_FB_VESA) += vesafb-thread.o vesafb-tng.o +endif obj-$(CONFIG_FB_IMAC) += imacfb.o obj-$(CONFIG_FB_VGA16) += vga16fb.o vgastate.o obj-$(CONFIG_FB_OF) += offb.o diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 3cfea31..bfb39cc 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1408,6 +1408,7 @@ fbmem_init(void) printk(KERN_WARNING "Unable to create fb class; errno = %ld\n", PTR_ERR(fb_class)); fb_class = NULL; } + return 0; } diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c index 5df41f6..f838a53 100644 --- a/drivers/video/modedb.c +++ b/drivers/video/modedb.c @@ -674,6 +674,7 @@ void fb_var_to_videomode(struct fb_videomode *mode, { u32 pixclock, hfreq, htotal, vtotal; + mode->refresh = 0; mode->name = NULL; mode->xres = var->xres; mode->yres = var->yres; @@ -1025,3 +1026,4 @@ EXPORT_SYMBOL(fb_find_best_mode); EXPORT_SYMBOL(fb_find_nearest_mode); EXPORT_SYMBOL(fb_videomode_to_modelist); EXPORT_SYMBOL(fb_find_mode); +EXPORT_SYMBOL(fb_destroy_modelist); diff --git a/drivers/video/vesafb-thread.c b/drivers/video/vesafb-thread.c new file mode 100644 index 0000000..543e202 --- /dev/null +++ b/drivers/video/vesafb-thread.c @@ -0,0 +1,751 @@ +/* + * Framebuffer driver for VBE 2.0+ compliant graphic boards. + * Kernel thread and vm86 routines. + * + * (c) 2004-2006 Michal Januszewski + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include