Date: Thu, 11 Jun 1998 22:47:38 +0200 (CEST) From: Geert Uytterhoeven To: Linux/m68k Subject: L68K: More patches for 2.1.105 Sender: owner-linux-m68k@phil.uni-sb.de Various clean ups (mainly sync with the vger tree): - Put all frame buffer docs together in Documentation/fb - Fix for newer ATI boards (PPC Open Firmware only) - Better hardware cursor handling. (Andrew Apted, IIRC) - Don't draw graphics logos on VGA text screens. Draw a monochrome text penguin on MDA. (Andrew Apted, IIRC) - Typo fix in vesafb.c. - Fix blanking for monochrome VGA/MDA text. I have to admit there's not that much m68k specific stuff today... --- m68k/Documentation/fb/00-INDEX.orig Thu Jun 11 22:41:30 1998 +++ m68k/Documentation/fb/00-INDEX Thu Jun 11 22:41:30 1998 @@ -0,0 +1,15 @@ +Index of files in Documentation/fb. If you think something about frame +buffer devices needs an entry here, needs correction or you've written one +please mail me. + Geert Uytterhoeven + + +00-INDEX + - this file +framebuffer.txt + - introduction to frame buffer devices +internals.txt + - quick overview of frame buffer device internals +vesafb.txt + - info on the VESA frame buffer device + --- m68k/Documentation/fb/framebuffer.txt.orig Thu Jun 11 22:41:30 1998 +++ m68k/Documentation/fb/framebuffer.txt Thu Jun 11 22:41:30 1998 @@ -0,0 +1,327 @@ + + The Frame Buffer Device + ----------------------- + +Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be) +Last revised: June 10, 1998 + + +0. Introduction +--------------- + +The frame buffer device provides an abstraction for the graphics hardware. It +represents the frame buffer of some video hardware and allows application +software to access the graphics hardware through a well-defined interface, so +the software doesn't need to know anything about the low-level (hardware +register) stuff. + +The device is accessed through special device nodes, usually located in the +/dev directory, i.e. /dev/fb*. + + +1. User's View of /dev/fb* +-------------------------- + +From the user's point of view, the frame buffer device looks just like any +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): + + 0 = /dev/fb0 First frame buffer + 32 = /dev/fb1 Second frame buffer + ... + 224 = /dev/fb7 8th frame buffer + +For backwards compatibility, you may want to create the following symbolic +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 + + cp /dev/fb0 myfile + +There also can be more than one frame buffer at a time, e.g. if you have a +graphics card in addition to the built-in hardware. The corresponding frame +buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently. + +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): + + export FRAMEBUFFER=/dev/fb1 + +or (for csh users): + + setenv FRAMEBUFFER /dev/fb1 + +After this the X server will use the second frame buffer. + + +2. Programmer's View of /dev/fb* +-------------------------------- + +As you already know, a frame buffer device is a memory device like /dev/mem and +it has the same features. You can read it, write it, seek to some location in +it and mmap() it (the main usage). The difference is just that the memory that +appears in the special file is not the whole memory, but the frame buffer of +some video hardware. + +/dev/fb* also allows several ioctls on it, by which lots of information about +the hardware can be queried and set. The color map handling works via ioctls, +too. Look into for more information on what ioctls exist and on +which data structures they work. Here's just a brief overview: + + - You can request unchangeable information about the hardware, like name, + organization of the screen memory (planes, packed pixels, ...) and address + and length of the screen memory. + + - You can request and change variable information about the hardware, like + visible and virtual geometry, depth, color map format, timing, and so on. + If you try to change that information, the driver maybe will round up some + values to meet the hardware's capabilities (or return EINVAL if that isn't + 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 + transparency). + +All this hardware abstraction makes the implementation of application programs +easier and more portable. E.g. the X server works completely on /dev/fb* and +thus doesn't need to know, for example, how the color registers of the concrete +hardware are organized. XF68_FBDev is a general X server for bitmapped, +unaccelerated video hardware. The only thing that has to be built into +application programs is the screen organization (bitplanes or chunky pixels +etc.), because it works on the frame buffer image data directly. + +For the future it is planned that frame buffer drivers for graphics cards and +the like can be implemented as kernel modules that are loaded at runtime. Such +a driver just has to call register_framebuffer() and supply some functions. +Writing and distributing such drivers independently from the kernel will save +much trouble... + + +3. Frame Buffer Resolution Maintenance +-------------------------------------- + +Frame buffer resolutions are maintained using the utility `fbset'. It can +change the video mode properties of the current resolution. 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. + +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. + + +4. The X Server +--------------- + +The X server (XF68_FBDev) is the most notable application program for the frame +buffer device. The current X server is part of the XFree86/XFree68 release +3.3.1 package and has 2 modes: + + - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config + file contains a + + Modes "default" + + line, the X server will use the scheme discussed above, i.e. it will start + up in the resolution determined by /dev/fb0current (or $FRAMEBUFFER, if + set). This is the default for the configuration file supplied with XFree68 + 3.2. It's the most simple configuration (and the only possible one if you + want to have a broadcast compatible display, e.g. PAL or NTSC), but it has + some limitations. + + - Therefore it's also possible to specify resolutions in the /etc/XF86Config + file. This allows for on-the-fly resolution switching while retaining the + 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) and + that you can't have a broadcast compatible display (e.g. no PAL or NTSC). + +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. + + +5. Video Mode Timings +--------------------- + +A monitor draws an image on the screen by using an electron beam (3 electron +beams for most color models, 1 electron beam for Trinitron color monitors and +monochrone monitors). The front of the screen is covered by a pattern of +colored phospors (pixels). If a phospor is hit by an electron, it emits a +photon and thus becomes visible. + +The electron beam draws horizontal lines (scanlines) from left to right, and +from the top to the bottom of the screen. By modifying the intensity of the +electron beam, pixels with various colors and intensities can be shown. + +After each scanline the electron beam has to move back to the left side of the +screen and to the next line: this is called the horizontal retrace. After the +whole screen (frame) was painted, the beam moves back to the upper left corner: +this is called the vertical retrace. During both the horizontal and vertical +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: + + 1/(28.37516E6 Hz) = 35.242E-9 s + +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 + + (640+272)*35.242E-9 s = 32.141E-6 s + +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 `pixels'). So a full screen will take + + (480+49)*32.141E-6 s = 17.002E-3 s + +The vertical scanrate is about 59 Hz: + + 1/(17.002E-3 s) = 58.815 Hz + +This means the screen data is refreshed about 59 times per second. To have a +stable picture without visible flicker, VESA recommends a vertical scanrate of +at least 72 Hz. But the perceived flicker is very human dependent: some people +can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz. + +Since the monitor doesn't know when a new scanline starts, the graphics board +will supply a synchronization pulse (horizontal sync or hsync) for each +scanline. Similarly it supplies a synchronization pulse (vertical sync or +vsync) for each new frame. The position of the image on the screen is +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. + + +----------+---------------------------------------------+----------+-------+ + | | ^ | | | + | | |upper_margin | | | + | | ¥ | | | + +----------###############################################----------+-------+ + | # ^ # | | + | # | # | | + | # | # | | + | # | # | | + | left # | # right | hsync | + | margin # | xres # margin | len | + |<-------->#<---------------+--------------------------->#<-------->|<----->| + | # | # | | + | # | # | | + | # | # | | + | # |yres # | | + | # | # | | + | # | # | | + | # | # | | + | # | # | | + | # | # | | + | # | # | | + | # | # | | + | # | # | | + | # ¥ # | | + +----------###############################################----------+-------+ + | | ^ | | | + | | |lower_margin | | | + | | ¥ | | | + +----------+---------------------------------------------+----------+-------+ + | | ^ | | | + | | |vsync_len | | | + | | ¥ | | | + +----------+---------------------------------------------+----------+-------+ + +The frame buffer device expects all horizontal timings in number of dotclocks +(in picoseconds, 1E-12 s), and vertical timings in number of scanlines. + + +6. Converting XFree86 timing values info frame buffer device timings +-------------------------------------------------------------------- + +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 + +The frame buffer device uses the following fields: + + - pixclock: pixel clock in ps (pico seconds) + - left_margin: time from sync to picture + - right_margin: time from picture to sync + - upper_margin: time from sync to picture + - lower_margin: time from picture to sync + - hsync_len: length of horizontal sync + - 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, +under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt". + + +7. References +------------- + +For more specific information about the frame buffer device and its +applications, please refer to the following documentation: + + - The manual pages for fbset: fbset(8), fb.modes(5) + - The manual pages for XFree68: XF68_FBDev(1), XF86Config(4/5) + - The mighty kernel sources: + o linux/include/linux/fb.h + o linux/drivers/char/fbmem.c + o linux/drivers/video/*fb.c + + +8. Downloading +-------------- + +All necessary files can be found at + + ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/ + +and on its mirrors. + + +9. 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 +provided by Frank Neumann. + +The frame buffer device abstraction was designed by Martin Schaller. --- m68k/Documentation/fb/internals.txt.orig Thu Jun 11 22:41:30 1998 +++ m68k/Documentation/fb/internals.txt Thu Jun 11 22:41:30 1998 @@ -0,0 +1,86 @@ + +This is a first start for some documentation about frame buffer device +internals. + +Geert Uytterhoeven , 10 June 1998 + +-------------------------------------------------------------------------------- + + *** 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 . + +1. Outside the kernel (user space) + + - struct fb_fix_screeninfo + + Device independent unchangeable information about a frame buffer device and + a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO + ioctl. + + - struct fb_var_screeninfo + + Device independent changeable information about a frame buffer device and a + specific video mode. This can be obtained using the FBIOGET_VSCREENINFO + ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan + the screen only, you can use the FBIOPAN_DISPLAY ioctl. + + - struct fb_cmap + + Device independent colormap information. You can get and set the colormap + using the FBIOGETCMAP and FBIOPUTCMAP ioctls. + + +2. Inside the kernel + + - struct fb_info + + Generic information, API and low level information about a specific frame + buffer device instance (slot number, board address, ...). + + - struct `par' + + Device dependent information that uniquely defines the video mode for this + particular piece of hardware. + + - struct display + + Interface between the frame buffer device and the console driver. + + +-------------------------------------------------------------------------------- + + *** VISUALS USED BY THE FRAME BUFFER DEVICE API *** + + +Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10) +------------------------------------------------- +Each pixel is either black or white. + + +Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR) +--------------------------------------------------------------------- +The whole pixel value is fed through a programmable lookup table that has one +color (including red, green, and blue intensities) for each possible pixel +value, and that color is displayed. + + +True color (FB_VISUAL_TRUECOLOR) +-------------------------------- +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. + + +Direct color (FB_VISUAL_DIRECTCOLOR) +------------------------------------ +The pixel value is broken up into red, green, and blue fields. This is what +most people mean when then say `true color'. + + +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. + --- m68k/Documentation/fb/vesafb.txt.orig Thu Jun 11 22:41:30 1998 +++ m68k/Documentation/fb/vesafb.txt Thu Jun 11 22:41:30 1998 @@ -0,0 +1,71 @@ + +what is vesafb? +=============== + +This is a generic driver for a graphic framebuffer on intel boxes. + +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 Extentions +Version 2.0 are required, becauce 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 compilant 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. With vesafb both text and +graphics modes work. Text modes are handled by vgafb, graphic modes +by the new vesafb.c. + +The graphic modes are not in the list which you get if you boot with +vga=ask and hit return. Here are some mode numbers: + + | 640x480 800x600 1024x768 +----+--------------------------- +256 | 0x101 0x103 0x105 +32k | 0x110 0x113 0x116 +64k | 0x111 0x114 0x117 +16M | 0x112 0x115 0x118 + +Note 1: this are the VESA mode numbers. The video mode select code + expects 0x200 + VESA mode number. +Note 2: lilo can't handle hex, for booting with "vga=??" you have to + transform the numbers to decimal. + + +Speed it up! +============ + +Check /usr/src/linux/Documentation/mtrr.txt, enabling write-combining +for the framebuffer memory gives a performance boost. + +There are two ways to do console scrolling: redraw the screen +completely, or by copying around the video memory. You can select one +of them using the kernel command line: video=vesa:redraw or +video=vesa:memmove. redraw is the default, becauce this one works +faster on my box. + + +Have fun! + + Gerd + +-- +Gerd Knorr --- m68k/Documentation/m68k/framebuffer.txt.orig Mon Jun 8 22:43:07 1998 +++ m68k/Documentation/m68k/framebuffer.txt Thu Jun 11 22:41:30 1998 @@ -1,330 +0,0 @@ - - The Linux/m68k Frame Buffer Device - ---------------------------------- - -Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be) -Last revised: January 24, 1998 - - -0. Introduction ---------------- - -The frame buffer device provides an abstraction for the graphics hardware. It -represents the frame buffer of some video hardware and allows application -software to access the graphics hardware through a well-defined interface, so -the software doesn't need to know anything about the low-level (hardware -register) stuff. - -The device is accessed through special device nodes, usually located in the -/dev directory, i.e. /dev/fb*. - - -1. User's View of /dev/fb* --------------------------- - -From the user's point of view, the frame buffer device looks just like any -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): - - 0 = /dev/fb0 First frame buffer - 32 = /dev/fb1 Second frame buffer - ... - 224 = /dev/fb7 8th frame buffer - -For backwards compatibility, you may want to create the following symbolic -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 - - cp /dev/fb0 myfile - -There also can be more than one frame buffer at a time, e.g. if you have a -graphics card in addition to the built-in hardware. The corresponding frame -buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently. - -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): - - export FRAMEBUFFER=/dev/fb1 - -or (for csh users): - - setenv FRAMEBUFFER /dev/fb1 - -After this the X server will use the second frame buffer. - - -2. Programmer's View of /dev/fb* --------------------------------- - -As you already know, a frame buffer device is a memory device like /dev/mem and -it has the same features. You can read it, write it, seek to some location in -it and mmap() it (the main usage). The difference is just that the memory that -appears in the special file is not the whole memory, but the frame buffer of -some video hardware. - -/dev/fb* also allows several ioctls on it, by which lots of information about -the hardware can be queried and set. The color map handling works via ioctls, -too. Look into for more information on what ioctls exist and on -which data structures they work. Here's just a brief overview: - - - You can request unchangeable information about the hardware, like name, - organization of the screen memory (planes, packed pixels, ...) and address - and length of the screen memory. - - - You can request and change variable information about the hardware, like - visible and virtual geometry, depth, color map format, timing, and so on. - If you try to change that information, the driver maybe will round up some - values to meet the hardware's capabilities (or return EINVAL if that isn't - 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 - transparency). - -All this hardware abstraction makes the implementation of application programs -easier and more portable. E.g. the X server works completely on /dev/fb* and -thus doesn't need to know, for example, how the color registers of the concrete -hardware are organized. XF68_FBDev is a general X server for bitmapped, -unaccelerated video hardware. The only thing that has to be built into -application programs is the screen organization (bitplanes or chunky pixels -etc.), because it works on the frame buffer image data directly. - -For the future it is planned that frame buffer drivers for graphics cards and -the like can be implemented as kernel modules that are loaded at runtime. Such -a driver just has to call register_framebuffer() and supply some functions. -Writing and distributing such drivers independently from the kernel will save -much trouble... - - -3. Frame Buffer Resolution Maintenance --------------------------------------- - -Frame buffer resolutions are maintained using the utility `fbset'. It can -change the video mode properties of the current resolution. 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. - -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. - - -4. The X Server ---------------- - -The X server (XF68_FBDev) is the most notable application program for the frame -buffer device. The current X server is part of the XFree86/XFree68 release -3.3.1 package and has 2 modes: - - - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config - file contains a - - Modes "default" - - line, the X server will use the scheme discussed above, i.e. it will start - up in the resolution determined by /dev/fb0current (or $FRAMEBUFFER, if - set). This is the default for the configuration file supplied with XFree68 - 3.2. It's the most simple configuration (and the only possible one if you - want to have a broadcast compatible display, e.g. PAL or NTSC), but it has - some limitations. - - - Therefore it's also possible to specify resolutions in the /etc/XF86Config - file. This allows for on-the-fly resolution switching while retaining the - 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) and - that you can't have a broadcast compatible display (e.g. no PAL or NTSC). - -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. - -There exists also an accelerated X server for the Cybervision 64 graphics -board, but that's not discussed here. - - -5. Video Mode Timings ---------------------- - -A monitor draws an image on the screen by using an electron beam (3 electron -beams for most color models, 1 electron beam for Trinitron color monitors and -monochrone monitors). The front of the screen is covered by a pattern of -colored phospors (pixels). If a phospor is hit by an electron, it emits a -photon and thus becomes visible. - -The electron beam draws horizontal lines (scanlines) from left to right, and -from the top to the bottom of the screen. By modifying the intensity of the -electron beam, pixels with various colors and intensities can be shown. - -After each scanline the electron beam has to move back to the left side of the -screen and to the next line: this is called the horizontal retrace. After the -whole screen (frame) was painted, the beam moves back to the upper left corner: -this is called the vertical retrace. During both the horizontal and vertical -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: - - 1/(28.37516E6 Hz) = 35.242E-9 s - -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 - - (640+272)*35.242E-9 s = 32.141E-6 s - -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 `pixels'). So a full screen will take - - (480+49)*32.141E-6 s = 17.002E-3 s - -The vertical scanrate is about 59 Hz: - - 1/(17.002E-3 s) = 58.815 Hz - -This means the screen data is refreshed about 59 times per second. To have a -stable picture without visible flicker, VESA recommends a vertical scanrate of -at least 72 Hz. But the perceived flicker is very human dependent: some people -can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz. - -Since the monitor doesn't know when a new scanline starts, the graphics board -will supply a synchronization pulse (horizontal sync or hsync) for each -scanline. Similarly it supplies a synchronization pulse (vertical sync or -vsync) for each new frame. The position of the image on the screen is -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. - - +----------+---------------------------------------------+----------+-------+ - | | ^ | | | - | | |upper_margin | | | - | | ¥ | | | - +----------###############################################----------+-------+ - | # ^ # | | - | # | # | | - | # | # | | - | # | # | | - | left # | # right | hsync | - | margin # | xres # margin | len | - |<-------->#<---------------+--------------------------->#<-------->|<----->| - | # | # | | - | # | # | | - | # | # | | - | # |yres # | | - | # | # | | - | # | # | | - | # | # | | - | # | # | | - | # | # | | - | # | # | | - | # | # | | - | # | # | | - | # ¥ # | | - +----------###############################################----------+-------+ - | | ^ | | | - | | |lower_margin | | | - | | ¥ | | | - +----------+---------------------------------------------+----------+-------+ - | | ^ | | | - | | |vsync_len | | | - | | ¥ | | | - +----------+---------------------------------------------+----------+-------+ - -The frame buffer device expects all horizontal timings in number of dotclocks -(in picoseconds, 1E-12 s), and vertical timings in number of scanlines. - - -6. Converting XFree86 timing values info frame buffer device timings --------------------------------------------------------------------- - -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 - -The frame buffer device uses the following fields: - - - pixclock: pixel clock in ps (pico seconds) - - left_margin: time from sync to picture - - right_margin: time from picture to sync - - upper_margin: time from sync to picture - - lower_margin: time from picture to sync - - hsync_len: length of horizontal sync - - 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, -under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt". - - -7. References -------------- - -For more specific information about the frame buffer device and its -applications, please refer to the following documentation: - - - The manual pages for fbset: fbset(8), fb.modes(5) - - The manual pages for XFree68: XF68_FBDev(1), XF86Config(4/5) - - The mighty kernel sources: - o linux/include/linux/fb.h - o linux/drivers/char/fbmem.c - o linux/drivers/video/*fb.c - - -8. Downloading --------------- - -All necessary files can be found at - - ftp://ftp.uni-erlangen.de/pub/Linux/680x0/ - -and on its mirrors. - - -9. 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 -provided by Frank Neumann. - -The frame buffer device abstraction was designed by Martin Schaller. --- m68k/drivers/video/README.fb.orig Mon Jun 1 11:23:00 1998 +++ m68k/drivers/video/README.fb Thu Jun 11 22:41:30 1998 @@ -1,87 +0,0 @@ - -This is a first start for some documentation about frame buffer device -internals. It should probably move to the Documentation directory some day. -You may want to read Documentation/m68k/framebuffer.txt also. - -Geert Uytterhoeven , 30 Mar 1998 - --------------------------------------------------------------------------------- - - *** 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 . - -1. Outside the kernel (user space) - - - struct fb_fix_screeninfo - - Device independent unchangeable information about a frame buffer device and - a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO - ioctl. - - - struct fb_var_screeninfo - - Device independent changeable information about a frame buffer device and a - specific video mode. This can be obtained using the FBIOGET_VSCREENINFO - ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan - the screen only, you can use the FBIOPAN_DISPLAY ioctl. - - - struct fb_cmap - - Device independent colormap information. You can get and set the colormap - using the FBIOGETCMAP and FBIOPUTCMAP ioctls. - - -2. Inside the kernel - - - struct fb_info - - Generic information, API and low level information about a specific frame - buffer device instance (slot number, board address, ...). - - - struct `par' - - Device dependent information that uniquely defines the video mode for this - particular piece of hardware. - - - struct display - - Interface between the frame buffer device and the console driver. - - --------------------------------------------------------------------------------- - - *** VISUALS USED BY THE FRAME BUFFER DEVICE API *** - - -Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10) -------------------------------------------------- -Each pixel is either black or white. - - -Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR) ---------------------------------------------------------------------- -The whole pixel value is fed through a programmable lookup table that has one -color (including red, green, and blue intensities) for each possible pixel -value, and that color is displayed. - - -True color (FB_VISUAL_TRUECOLOR) --------------------------------- -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. - - -Direct color (FB_VISUAL_DIRECTCOLOR) ------------------------------------- -The pixel value is broken up into red, green, and blue fields. This is what -most people mean when then say `true color'. - - -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. - --- m68k/drivers/video/atyfb.c.orig Mon Jun 8 23:15:33 1998 +++ m68k/drivers/video/atyfb.c Thu Jun 11 22:41:30 1998 @@ -1820,11 +1820,26 @@ u8 bus, devfn; u16 cmd; struct fb_info_aty *info; + int i; for (; dp; dp = dp->next) { - if (dp->n_addrs != 1 && dp->n_addrs != 3) - printk("Warning: expecting 1 or 3 addresses for ATY (got %d)", - dp->n_addrs); + switch (dp->n_addrs) { + case 1: + case 3: + addr = dp->addrs[0].address; + break; + case 4: + addr = dp->addrs[1].address; + break; + default: + printk("Warning: got %d adresses for ATY:\n", dp->n_addrs); + for (i = 0; i < dp->n_addrs; i++) + printk(" %08x-%08x", dp->addrs[i].address, + dp->addrs[i].address+dp->addrs[i].size-1); + if (dp->n_addrs) + printk("\n"); + continue; + } info = kmalloc(sizeof(struct fb_info_aty), GFP_ATOMIC); @@ -1845,13 +1860,13 @@ pcibios_write_config_word(bus, devfn, PCI_COMMAND, cmd); } } - /* Map in frame buffer */ - addr = dp->addrs[0].address; #ifdef __BIG_ENDIAN /* Use the big-endian aperture */ addr += 0x800000; #endif + + /* Map in frame buffer */ info->frame_buffer_phys = addr; info->frame_buffer = (unsigned long)ioremap(addr, 0x800000); --- m68k/drivers/video/fbcon.c.orig Mon Jun 8 22:49:18 1998 +++ m68k/drivers/video/fbcon.c Thu Jun 11 22:41:30 1998 @@ -532,16 +532,19 @@ int unit = conp->vc_num; struct display *p = &fb_display[unit]; + /* do we have a hardware cursor ? */ + if (p->dispsw->cursor) { + p->cursor_x = conp->vc_x; + p->cursor_y = conp->vc_y; + p->dispsw->cursor(p, mode, p->cursor_x, real_y(p, p->cursor_y)); + return; + } + /* Avoid flickering if there's no real change. */ if (p->cursor_x == conp->vc_x && p->cursor_y == conp->vc_y && (mode == CM_ERASE) == !cursor_on) return; - if (p->dispsw->cursor) { - p->cursor_x = conp->vc_x; - p->cursor_y = conp->vc_y; - p->dispsw->cursor(p, mode, p->cursor_x, real_y(p, p->cursor_y)); - } else { if (CURSOR_UNDRAWN ()) p->dispsw->revc(p, p->cursor_x, real_y(p, p->cursor_y)); p->cursor_x = conp->vc_x; @@ -558,7 +561,6 @@ cursor_on = 1; break; } - } } @@ -1341,7 +1343,9 @@ #endif #if defined(CONFIG_FBCON_MFB) || defined(CONFIG_FBCON_AFB) || \ defined(CONFIG_FBCON_ILBM) - if (depth == 1) { + if (depth == 1 && (p->type == FB_TYPE_PACKED_PIXELS || + p->type == FB_TYPE_PLANES || + p->type == FB_TYPE_INTERLEAVED_PLANES)) { /* monochrome */ unsigned char inverse = p->inverse ? 0x00 : 0xff; @@ -1354,6 +1358,21 @@ } done = 1; + } +#endif +#ifdef CONFIG_FBCON_VGA + if (depth == 1 && p->type == FB_TYPE_VGA_TEXT) { + + int height = 0; + char *p; + + printk(linux_mda_image); + + for (p = linux_mda_image; *p; p++) + if (*p == '\n') + height++; + + return height; } #endif /* Modes not yet supported: packed pixels with depth != 8 (does such a --- m68k/drivers/video/vesafb.c.orig Mon Jun 1 11:23:00 1998 +++ m68k/drivers/video/vesafb.c Thu Jun 11 22:41:30 1998 @@ -1,5 +1,5 @@ /* - * framebuffer driver for VBE 2.0 compilant graphic boards + * framebuffer driver for VBE 2.0 compliant graphic boards * * switching to graphics mode happens at boot time (while * running in real mode, see arch/i386/video.S). --- m68k/drivers/video/vgafb.c.orig Mon Jun 8 22:49:22 1998 +++ m68k/drivers/video/vgafb.c Thu Jun 11 22:41:30 1998 @@ -592,7 +592,7 @@ disp.ypanstep = fb_fix.ypanstep; disp.ywrapstep = fb_fix.ywrapstep; disp.line_length = fb_fix.line_length; - disp.can_soft_blank = 1; + disp.can_soft_blank = vga_can_do_color; disp.inverse = 0; disp.dispsw = &fbcon_vgafb; Greetings, Geert -- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium