Menu
▾
▴
[Linuxconsole-commit]CVS: ruby/web/htdocs/fbdev/HOWTO 1.html,1.1,1.2 2.html,1.1,1.2 3.html,1.1,1.2 4.html,1.1,1.2 index.html,1.1,1.2
|
From: James S. <jsi...@us...> - 2001-11-04 00:47:08
|
Update of /cvsroot/linuxconsole/ruby/web/htdocs/fbdev/HOWTO In directory usw-pr-cvs1:/tmp/cvs-serv22898/htdocs/fbdev/HOWTO Modified Files: 1.html 2.html 3.html 4.html index.html Log Message: Cleanup of fbdev docs. Needs still to be updated. Index: 1.html =================================================================== RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/fbdev/HOWTO/1.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- 1.html 2001/11/03 00:23:59 1.1 +++ 1.html 2001/11/04 00:47:05 1.2 @@ -5,80 +5,122 @@ </head> <body bgcolor="#FFFFFF"> -<h2><font face="Arial, Helvetica, sans-serif">1. Introduction</font></h2> +<h2>1. Introduction</h2> <hr width="100%" size="2"> -<p><font face="Arial, Helvetica, sans-serif">This is the Linux Framebuffer driver - HOWTO. It is intended as a quick reference covering everything you need to know - to write a framebuffer video driver under Linux. Frequently asked questions - about video mode setting under Linux are answered, and references are given - to some other sources of information on a variety of topics related to computer - graphics. Also, read this document not once, not twice but three times if you - are not familiar with video hardware.</font></p> -<p><font face="Arial, Helvetica, sans-serif">The scope is limited to the aspects - of writing a mode setting video card framebuffer driver pertaining to Linux. - listed See the other documents in the References section for more general information - on how to setup framebuffer cards and setting up the XFB_Dev X server.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">1.1. Acknowledgments</font></h3> -<p><font face="Arial, Helvetica, sans-serif">Much of this information came from - the new framebuffer internal API being developed by me for the upcoming next - series of kernels. Originally, this was based on a patch by Fabrice Bellard. - I learned of this patch and was impressed by it. Later, I took over development - and improved it even more. Much thanks goes to Fabrice for getting the ball - rolling. This API is a natural extension of the original API developed by Martin - Schaller and now maintained by Geert Uytterhoeven (<a href="mailto:ge...@li...">ge...@li...</a>). - Thanks go to you and the many others who developed the Linux framebuffer system, - drivers and utilities. A great amount of thanks goes to Andreas Beck of the - GGI project for helping me write this document and teaching me about mode setting. - Thanks also go out to those who have supported my work. </font></p> -<p><font face="Arial, Helvetica, sans-serif">Thanks to the SGML Tools package, - this HOWTO is available in several formats, all generated from a common source - file.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">1.2. Revision History</font></h3> -<p><font face="Arial, Helvetica, sans-serif">Version 1.0</font></p> -<p><font face="Arial, Helvetica, sans-serif">First version; posted to fbdev mailing - list only.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">1.3. New versions of this document</font></h3> -<p><font face="Arial, Helvetica, sans-serif">New versions of this document will - be periodically posted to the comp.os.linux.answers newsgroup. They will also - be uploaded to various anonymous ftp sites that archive such information including - <a href="ftp://metalabs.unc.edu/pub/Linux/docs/HOWTO/">ftp://metalabs.unc.edu/pub/Linux/docs/HOWTO/</a>>. - Hypertext versions of this and other Linux HOWTOs are available on many World-Wide-Web - sites, including <<a href="http://metalab.unc.edu/LDP/">http://metalab.unc.edu/LDP/</a>>. - Most Linux CD-ROM distributions include the HOWTOs, often under the /usr/doc - directory, and you can also buy printed copies from several vendors. Sometimes - the HOWTOs available from CD-ROM vendors, ftp sites, and printed format are - out of date. If the date on this HOWTO is more than six months in the past, - then a newer copy is probably available on the Internet.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Most translations of this and other - Linux HOWTOs can also be found at <<a + +<p> +This is the Linux Framebuffer driver HOWTO. It is intended as a quick reference +covering everything you need to know to write a framebuffer video driver under +Linux. Frequently asked questions about video mode setting under Linux are +answered, and references are given +to some other sources of information on a variety of topics related to computer +graphics. Also, read this document not once, not twice but three times if you +are not familiar with video hardware. +</p> + +<p> +The scope is limited to the aspects +of writing a mode setting video card framebuffer driver pertaining to Linux. +listed See the other documents in the References section for more general information +on how to setup framebuffer cards and setting up the XFB_Dev X server. +</p> + +<h3>1.1. Acknowledgments</h3> + +<p> +Much of this information came from +the new framebuffer internal API being developed by me for the upcoming next +series of kernels. Originally, this was based on a patch by Fabrice Bellard. +I learned of this patch and was impressed by it. Later, I took over development +and improved it even more. Much thanks goes to Fabrice for getting the ball +rolling. This API is a natural extension of the original API developed by Martin +Schaller and now maintained by Geert Uytterhoeven (<a href="mailto:ge...@li...">ge...@li...</a>). +Thanks go to you and the many others who developed the Linux framebuffer system, +drivers and utilities. A great amount of thanks goes to Andreas Beck of the +GGI project for helping me write this document and teaching me about mode setting. +Thanks also go out to those who have supported my work. +</p> + +<p> +Thanks to the SGML Tools package, +this HOWTO is available in several formats, all generated from a common source +file. +</p> + +<h3>1.2. Revision History</h3> + +<p>Version 1.0</p> +<p>First version; posted to fbdev mailing list only.</p> +<p>Version 1.1</p> +<p>Updated version; placed into CVS.Updated to reflect new purposed designs in + the framebuffer api</p> + +<h3>1.3. New versions of this document</h3> + +<p> +New versions of this document will +be periodically posted to the comp.os.linux.answers newsgroup. They will also +be uploaded to various anonymous ftp sites that archive such information including +<a href="ftp://metalabs.unc.edu/pub/Linux/docs/HOWTO/">ftp://metalabs.unc.edu/pub/Linux/docs/HOWTO/</a>>. +Hypertext versions of this and other Linux HOWTOs are available on many World-Wide-Web +sites, including <<a href="http://metalab.unc.edu/LDP/">http://metalab.unc.edu/LDP/</a>>. +Most Linux CD-ROM distributions include the HOWTOs, often under the /usr/doc +directory, and you can also buy printed copies from several vendors. Sometimes +the HOWTOs available from CD-ROM vendors, ftp sites, and printed format are +out of date. If the date on this HOWTO is more than six months in the past, +then a newer copy is probably available on the Internet. +</p> + +<p> +Most translations of this and other +Linux HOWTOs can also be found at <<a href="http://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/">http://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/</a>> - and <<a href="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/">ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/</a>>.</font></p> -<p><font face="Arial, Helvetica, sans-serif">If you make a translation of this - document into another language, let me know and I'll include a reference to - it here. As of yet there are no translations.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">1.4. Feedback</font></h3> -<p><font face="Arial, Helvetica, sans-serif">I rely on you, the reader, to make - this HOWTO useful. If you have any suggestions, corrections, or comments, please + and <<a href="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/">ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/</a>>. +</p> + +<p> +If you make a translation of this +document into another language, let me know and I'll include a reference to +it here. As of yet there are no translations. +</p> + +<h3>1.4. Feedback</h3> + +<p> +I rely on you, the reader, to make +this HOWTO useful. If you have any suggestions, corrections, or comments, please send them to me, <<a -href="mailto:jsi...@ac...">jsi...@ac...</a>>, and - I will try to incorporate them in the next revision.</font></p> -<p><font face="Arial, Helvetica, sans-serif">I am also willing to answer general - questions on video cards and fbcon under Linux as best I can. Before doing so, - please read all of the information in this HOWTO and send me detailed information - about the problem. Please do not ask me about using framebuffer cards under - operating systems other than Linux.</font></p> -<p><font face="Arial, Helvetica, sans-serif">If you publish this document on a - CD-ROM or in hardcopy form, a complimentary copy would be appreciated. Mail - me for my postal address. Also, consider making a donation to the Linux Documentation - Project to help support free documentation for Linux. Contact the Linux HOWTO - coordinator, Tim Bynum <<a +href="mailto:jsi...@tr...">jsi...@tr...</a>>, and + I will try to incorporate them in the next revision. +</p> + +<p> +I am also willing to answer general +questions on video cards and fbcon under Linux as best I can. Before doing so, +please read all of the information in this HOWTO and send me detailed information +about the problem. Please do not ask me about using framebuffer cards under +operating systems other than Linux. +</p> + +<p> +If you publish this document on a +CD-ROM or in hardcopy form, a complimentary copy would be appreciated. Mail +me for my postal address. Also, consider making a donation to the Linux Documentation +Project to help support free documentation for Linux. Contact the Linux HOWTO +coordinator, Tim Bynum <<a href="mailto:lin...@su...">lin...@su...</a>>, - for more information.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">1.5. Distribution Policy</font></h3> -<p><font face="Arial, Helvetica, sans-serif">Copyright (c) 1999 by James Simmons. - This document may be distributed under the terms set forth in the LDP license - at <<a href="http://sunsite.unc.edu/LDP/COPYRIGHT.html">http://sunsite.unc.edu/LDP/COPYRIGHT.html</a>>.</font></p> -<p align="center"><font face="Arial, Helvetica, sans-serif"><a href="index.html">index</a> - <a href="2.html">forward</a></font></p> + for more information. +</p> + +<h3>1.5. Distribution Policy</h3> + +<p> +Copyright (c) 2001 by James Simmons. +This document may be distributed under the terms set forth in the LDP license +at <<a href="http://sunsite.unc.edu/LDP/COPYRIGHT.html">http://sunsite.unc.edu/LDP/COPYRIGHT.html</a>>. +</p> + +<p align="center"><a href="index.html">index</a> +<a href="2.html">forward</a></p> </body> </html> Index: 2.html =================================================================== RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/fbdev/HOWTO/2.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- 2.html 2001/11/03 00:23:59 1.1 +++ 2.html 2001/11/04 00:47:05 1.2 @@ -5,186 +5,251 @@ </head> <body bgcolor="#FFFFFF"> -<h2><font face="Arial, Helvetica, sans-serif">2. Framebuffer Card Technology</font></h2> +<h2>2. Framebuffer Card Technology</h2> <hr width="100%" size="2"> -<p><font face="Arial, Helvetica, sans-serif">This section gives a very cursory + +<p> + This section gives a very cursory overview of graphics cards that have accessible framebuffer technology, in order to help you understand the concepts used later in the document. If you are considering writing a driver for a video card please contact the manufacturer for documentation - on the card. Also, please consider reading some books on video hardware in order - to learn more. </font></p> -<p><font face="Arial, Helvetica, sans-serif">The way framebuffer devices behave + on the card. Also, please consider reading some books on video hardware in order to learn more. +</p> + +<p> +The way framebuffer devices behave under Linux is something very similar to /dev/mem. /dev/fb is in fact viewed as a memory device, except in this case the memory is video ram and is mmaped to userspace for direct access. This model is, of course, simplified for the purpose of making programming the frame buffer much easier as well as making it device and platform independent. Since we are interested in building a driver, - we need to understand how exactly the video card itself works.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">2.1 Monitor</font></h3> -<p><font face="Arial, Helvetica, sans-serif">First, lets describe one of the biggest - but often overlooked components: the monitor. Today, there exist many types - of monitors. Flat screen to LED and so on. For all the many types, the basic - principle behind the monitor is the same. Basically, a monitor builds an image - sequentially from the data it gets on its input lines. To achieve this, a beam - scans over the screen in a kind of "zig-zag" pattern that covers the - whole visible part of the screen once per frame. It happens so fast the eye - can't see this happening (well, we hope). So which way does this beam go? All - monitors have chosen to always go left to right with a quick jump back to the - far left when we hit the right boundary of the monitor. Same goes for the top - to bottom approach, but at a much slower pace since most of our time is used - to move left to right for every single line. Obviously, the displayed data needs - to be synchronized with the current position of the beam to be able to build - a steady picture. This is what those HSYNC and VSYNC you see in your monitor - manual are for. These two lines that say, "hey move the beam to the left - now" and "move the ray to the top now". Some systems encode this - information. For example, the green channel, which is called sync on green, - but that doesn't change the principle. All a monitor knows about a mode is what - it gets that's contained in the frequencies with which those signals return. - These frequencies are called the horizontal and vertical frequencies (aka refresh - rate), as they determine how often per second a whole image is drawn. A monitor - knows nothing about depth, clocks, and borders. If two modes have the same frequencies, - they will be the same to the monitor. This is why different centering data for - e.g. 640x480x16 and 640x480x32 are not stored in the monitor. The monitor can't - distinguish between those modes. Between two HSYNC we get the RGB signals.</font></p> + we need to understand how exactly the video card itself works. +</p> + +<h3>2.1 Monitor</font></h3> + +<p> +First, lets describe one of the biggest +but often overlooked components: the monitor. Today, there exist many types +of monitors. Flat screen to LED and so on. For all the many types, the basic +principle behind the monitor is the same. Basically, a monitor builds an image +sequentially from the data it gets on its input lines. To achieve this, a beam +scans over the screen in a kind of "zig-zag" pattern that covers the +whole visible part of the screen once per frame. It happens so fast the eye +can't see this happening (well, we hope). So which way does this beam go? All +monitors have chosen to always go left to right with a quick jump back to the +far left when we hit the right boundary of the monitor. Same goes for the top +to bottom approach, but at a much slower pace since most of our time is used +to move left to right for every single line. Obviously, the displayed data needs +to be synchronized with the current position of the beam to be able to build +a steady picture. This is what those HSYNC and VSYNC you see in your monitor +manual are for. These two lines that say, "hey move the beam to the left +now" and "move the ray to the top now". Some systems encode this +information. For example, the green channel, which is called sync on green, +but that doesn't change the principle. All a monitor knows about a mode is what +it gets that's contained in the frequencies with which those signals return. +These frequencies are called the horizontal and vertical frequencies (aka refresh + rate), as they determine how often per second a whole image is drawn. A monitor +knows nothing about depth, clocks, and borders. If two modes have the same frequencies, +they will be the same to the monitor. This is why different centering data for +e.g. 640x480x16 and 640x480x32 are not stored in the monitor. The monitor can't +distinguish between those modes. Between two HSYNC we get the RGB signals.</p> <table width="90%" border="0" cellspacing="0" cellpadding="0" align="center"> <tr> - <td width="15%"><font face="Arial, Helvetica, sans-serif">HSYNC</font></td> + <td width="15%">HSYNC</td> <td width="2%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">/</font></td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">-</font></td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">\</font></td> + <td width="2%">/</td> + <td width="2%">-</td> + <td width="2%">\</td> <td width="0%"> </td> <td colspan="10"> <hr width="100%" size="2"> </td> <td width="0%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">/</font></td> - <td width="0%"><font face="Arial, Helvetica, sans-serif">--</font></td> - <td width="5%"><font face="Arial, Helvetica, sans-serif">\</font></td> + <td width="2%">/</td> + <td width="0%">--</td> + <td width="5%">\</td> </tr> <tr> - <td width="15%"><font face="Arial, Helvetica, sans-serif">RGB</font></td> + <td width="15%">RGB</td> <td width="2%"> </td> <td width="2%"> </td> <td width="2%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">data</font></td> + <td width="2%">data</td> <td width="0%"> </td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> - <td width="7%"><font face="Arial, Helvetica, sans-serif">data</font></td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> + <td width="7%">data</td> <td width="0%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">data</font></td> + <td width="2%">data</td> <td width="0%"> </td> <td width="5%"> </td> </tr> <tr> - <td width="15%"><font face="Arial, Helvetica, sans-serif">time</font></td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">1</font></td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">2</font></td> + <td width="15%">time</td> + <td width="2%">1</td> + <td width="2%">2</td> <td width="2%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">3</font></td> + <td width="2%">3</td> <td width="0%"> </td> <td colspan="10"> <hr width="100%" size="2"> </td> <td width="0%"> </td> - <td width="2%"><font face="Arial, Helvetica, sans-serif">4</font></td> + <td width="2%">4</td> <td width="0%"> </td> - <td width="5%"><font face="Arial, Helvetica, sans-serif">5</font></td> + <td width="5%">5</td> </tr> </table> -<p><font face="Arial, Helvetica, sans-serif">At 1, the HSYNC pulse gets raised. - The beam will now quickly move to the left. During that time, the RGB lines - should be black (ray off), otherwise it would leave a noticeable trace while - moving, which would look ugly. </font></p> -<p><font face="Arial, Helvetica, sans-serif">At 2, the HSYNC pulse ends. This - point isn't of much interest, as you cannot tell, if the ray is already at the - left edge. The only thing important about point 2 is, that the time between - point 1 and 2 must be sufficiently high for the monitor to detect the HSYNC - signal. Usually, the HSYNC pulse can be made very small.</font></p> -<p><font face="Arial, Helvetica, sans-serif">At some point after 1, the ray will - start flying to the right again. When point 3 comes, it will actually start - to display data. Point 3 can thus be adjusted to change the left border location. - If you wait longer before you start sending data, the left border will move - to the right.</font></p> -<p><font face="Arial, Helvetica, sans-serif">When you have sent all data, you - reach point 4. As a HSYNC pulse should then be sent to start a new line, we - set the RGB lines to black again. At point 5 we have completed a cycle and start - the next line.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">2.2 Video card </font></h3> -<p><font face="Arial, Helvetica, sans-serif">Next, we look at the video card point - of view. The video card could send out a steady stream of data to the monitor - except for one thing. The monitor needs time for retracing so the video card - will be put into some "delay" at specific times. To be precise between - point 4 and point 1 on the NEXT line on the previous diagram. For the video - card, the "natural" coordinate system starts at point 3, when it starts - emitting data. This point usually causes some confusion with modeline calculation:</font></p> -<p><font face="Arial, Helvetica, sans-serif">HSYNC __/~~~\______________________________________________/~~~\___</font></p> -<p><font face="Arial, Helvetica, sans-serif">RGB ___________datadatadatadatadatadatadatadatadatad_____________</font></p> -<p><font face="Arial, Helvetica, sans-serif">time 1 2 3 - 4 5 6</font></p> -<p><font face="Arial, Helvetica, sans-serif">grc SS SE 0 - W SS SE</font></p> -<p><font face="Arial, Helvetica, sans-serif">From the graphics card point of view - (grc), a line starts at "0". From that point onward, it will output - the data in its video ram. There is a counter that will limit the number of - pixels that are put on one line. This is what we call the width of the mode. - On a 640x480 standard VESA mode, this is 640 pixels. </font></p> -<p><font face="Arial, Helvetica, sans-serif">We will usually want a small right - border to allow the monitor to prepare for the following SYNC pulse we will - generate. The aforementioned counter will run on (but data output from video - RAM will be suppressed) until we reach the point SS (SyncStart). On a 640x480 - standard VGA mode, this happens at 664 pixels. That is, we left a border of - 24 pixels.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now we raise the HSYNC to tell the - monitor to go left. This signal remains asserted until we reach the point SE - (SyncEnd). (760 pixels on VGA - i.e. 96 pixels of sync pulse. This is pretty - long, but VGA monitors weren't very quick.)</font></p> -<p><font face="Arial, Helvetica, sans-serif">We will also want some left border, - so we wait until we reach the next "0" point before starting to generate - a signal again. On standard VGA this happens at 800 pixels (40 pixels left border). - At that point, we reset the counter to 0 and start over. This point is usually - called the "total" for this reason.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now let us look at how we can change - the picture's appearance by changing values in such a modeline.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Moving SE should not cause any difference - at all, except if you make the sync pulse too small for the monitor to recognize.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Moving SS and SE together will move - the location of the sync pulse within the picture. Let us assume we move them - both to the "left", i.e. we decrease their startpoints. What happens - is, that we decrease the distance W-SS (which determines the right border) and - increase 0-SE (the left border). As a result, the picture moves to the right.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now what happens, if you change W? - You get extra pixels at the right border. As usually borders are pretty large - for standard VGA modes, you can usually display something like 648x486 without - a problem on a standard VGA monitor. You will not be able to see the difference.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Of course, there are limits to this: - If you go too far, you will produce pixels beyond the visible area of the monitor - (which is useless), or interfere with the retrace, what gives ugly stripes from - the retracing CRT ray.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now let's shed some light on a few - remaining terms:</font></p> -<p><font face="Arial, Helvetica, sans-serif">BlankStart BS and BlankEnd BE. Between - SE and 0, you can put a BE point on many graphics cards. At that point, the - RGB lines are no longer clamped to black (to avoid interfering with the retrace), - but can be programmed to a border color. The same goes for BS, which can be - placed between W and SS. Usually, one doesn't use that feature nowadays, as - we have tunable monitors that allow stretching the mode to the physical limits - of the monitor.</font></p> -<p><font face="Arial, Helvetica, sans-serif">On old monitors, one used large borders - to ensure the data was always visible. There, the border color made some sense - as kind of eye candy.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Pixelclock. That is the rate at which - pixels are output to the RGB lines. It is usually the basic unit for all timing - values in a graphics card.</font></p> -<p align="center"><font face="Arial, Helvetica, sans-serif"> <a href="index.html">index</a> - <a href="1.html">back</a> <a href="3.html">forward </a></font></p> + +<p> +At 1, the HSYNC pulse gets raised. +The beam will now quickly move to the left. During that time, the RGB lines +should be black (ray off), otherwise it would leave a noticeable trace while +moving, which would look ugly. +</p> + +<p> +At 2, the HSYNC pulse ends. This +point isn't of much interest, as you cannot tell, if the ray is already at the +left edge. The only thing important about point 2 is, that the time between +point 1 and 2 must be sufficiently high for the monitor to detect the HSYNC +signal. Usually, the HSYNC pulse can be made very small. +</p> + +<p> +At some point after 1, the ray will +start flying to the right again. When point 3 comes, it will actually start +to display data. Point 3 can thus be adjusted to change the left border location. +If you wait longer before you start sending data, the left border will move +to the right. +</p> + +<p> +When you have sent all data, you +reach point 4. As a HSYNC pulse should then be sent to start a new line, we +set the RGB lines to black again. At point 5 we have completed a cycle and start +the next line. +</p> + +<h3>2.2 Video card </h3> + +<p> +Next, we look at the video card point +of view. The video card could send out a steady stream of data to the monitor +except for one thing. The monitor needs time for retracing so the video card +will be put into some "delay" at specific times. To be precise between +point 4 and point 1 on the NEXT line on the previous diagram. For the video +card, the "natural" coordinate system starts at point 3, when it starts +emitting data. This point usually causes some confusion with modeline calculation: +</p> + +<p>HSYNC __/~~~\______________________________________________/~~~\___</p> +<p>RGB ___________datadatadatadatadatadatadatadatadatad_____________</p> +<p>time 1 2 3 + 4 5 6</p> +<p>grc SS SE 0 + W SS SE</p> + +<p> +From the graphics card point of view +(grc), a line starts at "0". From that point onward, it will output +the data in its video ram. There is a counter that will limit the number of +pixels that are put on one line. This is what we call the width of the mode. +On a 640x480 standard VESA mode, this is 640 pixels. +</p> + +<p> +We will usually want a small right +border to allow the monitor to prepare for the following SYNC pulse we will +generate. The aforementioned counter will run on (but data output from video +RAM will be suppressed) until we reach the point SS (SyncStart). On a 640x480 +standard VGA mode, this happens at 664 pixels. That is, we left a border of +24 pixels. +</p> + +<p> +Now we raise the HSYNC to tell the +monitor to go left. This signal remains asserted until we reach the point SE +(SyncEnd). (760 pixels on VGA - i.e. 96 pixels of sync pulse. This is pretty +long, but VGA monitors weren't very quick.) +</p> + +<p> +We will also want some left border, +so we wait until we reach the next "0" point before starting to generate +a signal again. On standard VGA this happens at 800 pixels (40 pixels left border). +At that point, we reset the counter to 0 and start over. This point is usually +called the "total" for this reason. +</p> + +<p> +Now let us look at how we can change +the picture's appearance by changing values in such a modeline. +</p> + +<p> +Moving SE should not cause any difference +at all, except if you make the sync pulse too small for the monitor to recognize. +</p> + +<p> +Moving SS and SE together will move +the location of the sync pulse within the picture. Let us assume we move them +both to the "left", i.e. we decrease their startpoints. What happens +is, that we decrease the distance W-SS (which determines the right border) and +increase 0-SE (the left border). As a result, the picture moves to the right. +</p> + +<p> +Now what happens, if you change W? +You get extra pixels at the right border. As usually borders are pretty large +for standard VGA modes, you can usually display something like 648x486 without +a problem on a standard VGA monitor. You will not be able to see the difference. +</p> + +<p> +Of course, there are limits to this: +If you go too far, you will produce pixels beyond the visible area of the monitor +(which is useless), or interfere with the retrace, what gives ugly stripes from +the retracing CRT ray. +</p> + +<p> +Now let's shed some light on a few +remaining terms: +</p> + +<p> +BlankStart BS and BlankEnd BE. Between +SE and 0, you can put a BE point on many graphics cards. At that point, the +RGB lines are no longer clamped to black (to avoid interfering with the retrace), +but can be programmed to a border color. The same goes for BS, which can be +placed between W and SS. Usually, one doesn't use that feature nowadays, as +we have tunable monitors that allow stretching the mode to the physical limits +of the monitor. +</p> + +<p> +On old monitors, one used large borders +to ensure the data was always visible. There, the border color made some sense +as kind of eye candy. +</p> + +<p> +Pixelclock. That is the rate at which +pixels are output to the RGB lines. It is usually the basic unit for all timing +values in a graphics card. +</p> + +<p align="center"> <a href="index.html">index</a> +<a href="1.html">back</a> <a href="3.html">forward </a></p> </body> </html> Index: 3.html =================================================================== RCS file: /cvsroot/linuxconsole/ruby/web/htdocs/fbdev/HOWTO/3.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- 3.html 2001/11/03 00:23:59 1.1 +++ 3.html 2001/11/04 00:47:05 1.2 @@ -5,336 +5,480 @@ </head> <body bgcolor="#FFFFFF"> -<h2><font face="Arial, Helvetica, sans-serif">3. Actually calculating a mode</font></h2> +<h2>3. Actually calculating a mode</h2> <hr width="100%" size="2"> -<p><font face="Arial, Helvetica, sans-serif">If you look at the fbdev driver you - think yikes. Yes, it's complex, but not as much as you think. A side note about - standard modes -- It's a common misconception that graphics cards cannot do - anything but the VGA/VESA induced "standard" modes like 640x480, 800x600, - 1024x768, 1280x960, ... With most cards, about any resolution can be programmed, - though many accelerators have been optimized for the above mentioned modes, - so that it is usually NOT wise to use other widths, as one might need to turn - OFF accelerator support. So if you write a driver, don't cling to these modes. - If the card can handle it, allow any mode.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Here, the type of monitor has a big - impact on what kind of modes we can have. There are two basic types of monitors: - fixed frequency (they usually can do multiple vertical frequencies, though, - which are much less critical, as they are much lower) and multifrequency. </font></p> -<h3><font face="Arial, Helvetica, sans-serif">3.1 Fixed frequency monitors</font></h3> -<p><font face="Arial, Helvetica, sans-serif">The monitor manual says the horizontal - frequency (hfreq) is 31.5 kHz.</font></p> -<p><font face="Arial, Helvetica, sans-serif">We want to display a given mode, - say 640x480.</font></p> -<p><font face="Arial, Helvetica, sans-serif">We can now already determine the - absolute minimum dotclock we need, as</font></p> + +<p> +If you look at the fbdev driver you +think yikes. Yes, it's complex, but not as much as you think. A side note about +standard modes -- It's a common misconception that graphics cards cannot do +anything but the VGA/VESA induced "standard" modes like 640x480, 800x600, + 1024x768, 1280x960, ... With most cards, about any resolution can be programmed, +though many accelerators have been optimized for the above mentioned modes, +so that it is usually NOT wise to use other widths, as one might need to turn +OFF accelerator support. So if you write a driver, don't cling to these modes. +If the card can handle it, allow any mode. +</p> + +<p> +Here, the type of monitor has a big +impact on what kind of modes we can have. There are two basic types of monitors: +fixed frequency (they usually can do multiple vertical frequencies, though, +which are much less critical, as they are much lower) and multifrequency. +</p> + +<h3>3.1 Fixed frequency monitors</h3> + +<p> +The monitor manual says the horizontal +frequency (hfreq) is 31.5 kHz. +</p> + +<p> +We want to display a given mode, +say 640x480. +</p> + +<p> +We can now already determine the +absolute minimum dotclock we need, as +</p> <blockquote> - <p><font face="Courier New, Courier, mono" size="2">dotclock = horiz_total * - hfreq</font></p> + <p><font size="2">dotclock = horiz_total * hfreq</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">and</font></p> +<p>and</p> <blockquote> - <p><font face="Courier New, Courier, mono" size="2">horiz_total = width + right_border - + sync + left_border > width</font></p> + <p><font size="2">horiz_total = width + right_border + + sync + left_border > width</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">The minimum dotclock computes to - 20.16 MHz. We will probably need something around 20% "slack" for - borders and sync, so let's say we need about a 24MHz clock. Now we look at the - next higher clock our card can handle, which is 25.175 MHz, as we assume we - have a VGA compatible card.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now we can compute the horizontal - total:</font></p> + +<p> +The minimum dotclock computes to +20.16 MHz. We will probably need something around 20% "slack" for +borders and sync, so let's say we need about a 24MHz clock. Now we look at the +next higher clock our card can handle, which is 25.175 MHz, as we assume we +have a VGA compatible card. +</p> + +<p> +Now we can compute the horizontal +total: +</p> + <blockquote> - <p><font face="Courier New, Courier, mono" size="2">horiz_total = dotclock / - hfreq = 799.2</font></p> + <p><font size="2">horiz_total = dotclock / + hfreq = 799.2</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">We can only program this as multiples - of 8, so we round to 800. Now, we still need to determine the length and placement - of the sync pulse, which will give all remaining parameters.</font></p> -<p><font face="Arial, Helvetica, sans-serif">There is no clean mathematical requirement - for those. Technically, the sync must be long enough to be detected, and placed - in a way that the mode is centered. The centering issue is not very pressing - anymore, as digitally controlled monitors are common, which allow to control - that externally. Generally, you should place the sync pulse early (i.e. keep - right_border small), as this will usually not cause artifacts that would arise - from turning on the output again too early when the sync pulse is placed too - late.</font></p> -<p><font face="Arial, Helvetica, sans-serif">So, if we as a "rule-of-thumb" - use a half of the blanking period for the sync and divide the rest as 1/3 right-border, - 2/3 left border, we get a modeline of:</font></p> +<p> +We can only program this as multiples +of 8, so we round to 800. Now, we still need to determine the length and placement +of the sync pulse, which will give all remaining parameters. +</p> +<p> +There is no clean mathematical requirement +for those. Technically, the sync must be long enough to be detected, and placed +in a way that the mode is centered. The centering issue is not very pressing +anymore, as digitally controlled monitors are common, which allow to control +that externally. Generally, you should place the sync pulse early (i.e. keep +right_border small), as this will usually not cause artifacts that would arise +from turning on the output again too early when the sync pulse is placed too +late. +</p> +<p> +So, if we as a "rule-of-thumb" +use a half of the blanking period for the sync and divide the rest as 1/3 right-border, +2/3 left border, we get a modeline of:</p> <blockquote> - <p><font face="Arial, Helvetica, sans-serif">"640x480" 25.175 640 - 664 744 800 ??? ??? ??? ???</font></p> + <p>"640x480" 25.175 640 + 664 744 800 ??? ??? ??? ???</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">While this is not perfectly the same - as a standard VGA timing, it should run as well on VGA monitors. The sync is - a bit shorter, but that shouldn't be a real problem.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now, for the vertical timing. At - 480 lines, a VGA monitor uses 60Hz.</font></p> +<p> +While this is not perfectly the same +as a standard VGA timing, it should run as well on VGA monitors. The sync is +a bit shorter, but that shouldn't be a real problem. +</p> + +<p> +Now, for the vertical timing. At 480 lines, a VGA monitor uses 60Hz. +</p> <blockquote> - <p><font face="Courier New, Courier, mono" size="2">hfreq = vfreq * vert_total</font></p> + <p><font size="2">hfreq = vfreq * vert_total</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">This yields a vert_total=525. The - vertical timings usually use much less overhead than the horizontal ones, as - here we count whole lines. This means much longer delays than just pixels. 10% - overhead will suffice here and we again split the borders 1/3: 2/3, with only - a few lines (say 2) for the sync pulse, as this is already much longer than - a HSYNC and thus easily detectable.</font></p> +<p> +This yields a vert_total=525. The +vertical timings usually use much less overhead than the horizontal ones, as +here we count whole lines. This means much longer delays than just pixels. 10% +overhead will suffice here and we again split the borders 1/3: 2/3, with only +a few lines (say 2) for the sync pulse, as this is already much longer than +a HSYNC and thus easily detectable. +</p> + <blockquote> - <p><font face="Arial, Helvetica, sans-serif">"640x480" 25.175 640 - 664 744 800 480 495 497 525</font></p> + <p>"640x480" 25.175 640 + 664 744 800 480 495 497 525</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">Let us compare that to an XF86 modeline - that claims to be standard VGA:</font></p> + +<p> +Let us compare that to an XF86 modeline + that claims to be standard VGA: +</p> + <blockquote> - <p><font face="Arial, Helvetica, sans-serif">Modeline "640x480" - 25.175 640 664 760 800 480 491 493 525</font></p> + <p>Modeline "640x480" + 25.175 640 664 760 800 480 491 493 525</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">Not much difference - right? They - should both work well, just a little shifted against each other vertically.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">3.2 Multiscan monitor</font></h3> -<p><font face="Arial, Helvetica, sans-serif">Here we will consider a theoretical - monitor that can do hfreq 31-95kHz and vfreq 50-130Hz. Now, let's look at a - 640x480 mode. Our heuristics say, that we will need about 768x528 (20% and 10% - more) for borders and sync. We want a maximum refresh rate, so let's look what - limits the mode:</font></p> + +<p> +Not much difference - right? They +should both work well, just a little shifted against each other vertically. +</p> + +<h3>3.2 Multiscan monitor</h3> + +<p> +Here we will consider a theoretical +monitor that can do hfreq 31-95kHz and vfreq 50-130Hz. Now, let's look at a +640x480 mode. Our heuristics say, that we will need about 768x528 (20% and 10% +more) for borders and sync. We want a maximum refresh rate, so let's look what +limits the mode: +</p> + <blockquote> <p><font face="Courier New, Courier, mono" size="2">hfreq = vfreq * vtotal = - 130 * 528 = 68.6 kHz</font></p> + 130 * 528 = 68.6 kHz</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">Oh - we cannot use the full hfreq - of our monitor... well no problem. What counts is the vfreq, as it determines - how much flicker we see.</font></p> -<p><font face="Arial, Helvetica, sans-serif">O.K. - what pixelclock will we need? - </font></p> +<p> +Oh - we cannot use the full hfreq +of our monitor... well no problem. What counts is the vfreq, as it determines +how much flicker we see. +</p> + +<p>O.K. - what pixelclock will we need? +</p> <blockquote> - <p><font face="Courier New, Courier, mono" size="2">pixclock = hfreq * htotal</font></p> + <p><font size="2">pixclock = hfreq * htotal</p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">The calculation yields 52.7MHz. - </font></p> -<p><font face="Arial, Helvetica, sans-serif">Now we look what the card can do. - Say we have a fixed set of clocks. We look what clocks we have close by. Assume - the card can do 50 and 60 MHz.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now we have a choice: We can either - use a lower clock, thus scaling down the refresh rate a bit (by 5% ... so what...): - This is what one usually does.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Or we can use a higher clock, but - this would exceed the monitor specifications. That can be countered by adding - more border, but this is usually not done, as it is a waste of space on the - screen. However, keep it in mind as a trick for displaying 320x200, when you - do not have doubling features. It will display in a tiny window in the middle - of the screen, but it will display.</font></p> -<p><font face="Arial, Helvetica, sans-serif">O.K. - what will our calculation - yield?</font></p> +<p>The calculation yields 52.7MHz. + </p> + +<p> +Now we look what the card can do. +Say we have a fixed set of clocks. We look what clocks we have close by. Assume +the card can do 50 and 60 MHz. +</p> + +<p> +Now we have a choice: We can either +use a lower clock, thus scaling down the refresh rate a bit (by 5% ... so what...): +This is what one usually does. +</p> + +<p> +Or we can use a higher clock, but +this would exceed the monitor specifications. That can be countered by adding +more border, but this is usually not done, as it is a waste of space on the +screen. However, keep it in mind as a trick for displaying 320x200, when you +do not have doubling features. It will display in a tiny window in the middle +of the screen, but it will display. +</p> + +<p> +O.K. - what will our calculation +yield? +</p> + <blockquote> - <p><font face="Arial, Helvetica, sans-serif">"640x480" 50 640 - 664 728 768 480 496 498 528 <i># 65kHz 123Hz</i></font></p> + <p>"640x480" 50 640 + 664 728 768 480 496 498 528 <i># 65kHz 123Hz</i></p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">I just mentioned doubling features. - This is how VGA does 320x200. It displays each pixel twice in both directions. - Thus it effectively is a 640x400 mode. If this would not be done, you would - need a pixelclock of 12.59MHz and you would still have the problem of needing - a 140Hz refresh, if hsync should stay at 31.5kHz.</font></p> -<p><font face="Arial, Helvetica, sans-serif">A horizontal doubling feature allows - us to use the 25.175MHz clock intended for 640, and a line-doubling feature - keeps the vsync the same as 400 lines. Actually the line-doubler is programmable, - so you can as well use modes as sick as 640x50.</font></p> -<p><font face="Arial, Helvetica, sans-serif">O.K. - another example. Same monitor, - 1280x1024.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Now we need about 1536x1126 total - (same rule of thumb). That yields 130Hz*1126lines = 146 kHz. We would exceed - the hfreq with that, so now the hfreq is the limit and we can only reach a refresh - rate of about (95kHz/1126) 84 Hz anymore.</font></p> -<p><font face="Arial, Helvetica, sans-serif">The required clock is now 146MHz. - That would yield:</font></p> + +<p> +I just mentioned doubling features. +This is how VGA does 320x200. It displays each pixel twice in both directions. +Thus it effectively is a 640x400 mode. If this would not be done, you would +need a pixelclock of 12.59MHz and you would still have the problem of needing +a 140Hz refresh, if hsync should stay at 31.5kHz. +</p> + +<p> +A horizontal doubling feature allows +us to use the 25.175MHz clock intended for 640, and a line-doubling feature +keeps the vsync the same as 400 lines. Actually the line-doubler is programmable, +so you can as well use modes as sick as 640x50. +</p> + +<p> +O.K. - another example. Same monitor, +1280x1024. +</p> + +<p> +Now we need about 1536x1126 total +(same rule of thumb). That yields 130Hz*1126lines = 146 kHz. We would exceed +the hfreq with that, so now the hfreq is the limit and we can only reach a refresh +rate of about (95kHz/1126) 84 Hz anymore. +</p> + +<p> +The required clock is now 146MHz. +That would yield: +</p> <blockquote> - <p><font face="Arial, Helvetica, sans-serif">"1280x1024" 146 1280 - 1320 1448 1536 1024 1058 1060 1126 <i># 95kHz 84Hz</i></font></p> + <p>"1280x1024" 146 1280 + 1320 1448 1536 1024 1058 1060 1126 <i># 95kHz 84Hz</i></p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">Now the clock might be programmable, - but keep in mind that there may be limits to the clock. <b>DO NOT OVERCLOCK</b> - a graphics card. This will result in the RAMDAC producing blurry images (as - it cannot cope with the high speed), and more importantly, the RAMDAC will OVERHEAT - and might be destroyed.</font></p> -<p><font face="Arial, Helvetica, sans-serif">Another issue is memory bandwidth. - The video memory can only give a certain amount of data per time unit. This - often limits the maximum clock at modes with high color depth (i.e. much data - per pixel). In the case of my card, it limits the clock to 130MHz at 16-bit - depth, which would produce:</font></p> + +<p> +Now the clock might be programmable, +but keep in mind that there may be limits to the clock. <b>DO NOT OVERCLOCK</b> +a graphics card. This will result in the RAMDAC producing blurry images (as +it cannot cope with the high speed), and more importantly, the RAMDAC will +OVERHEAT +and might be destroyed. +</p> + +<p> +Another issue is memory bandwidth. +The video memory can only give a certain amount of data per time unit. This +often limits the maximum clock at modes with high color depth (i.e. much data +per pixel). In the case of my card, it limits the clock to 130MHz at 16-bit +depth, which would produce: +</p> + <blockquote> - <p><font face="Arial, Helvetica, sans-serif">"1280x1024" 130 1280 - 1320 1448 1536 1024 1058 1060 1126 <i># 85kHz 75Hz</i></font></p> + <p>"1280x1024" 130 1280 + 1320 1448 1536 1024 1058 1060 1126 <i># 85kHz 75Hz</i></p> </blockquote> -<p><font face="Arial, Helvetica, sans-serif">This is pretty much what my monitor - shows now, if I ask it.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">3.3 Recipe for multisync monitors</font></h3> -<p><font face="Arial, Helvetica, sans-serif">a) Determine the totals by calculating - htotal = width*1.2 and vtotal = height*1.1.</font></p> -<p><font face="Arial, Helvetica, sans-serif">b) Check what limits the refresh - rate by calculating vfreq2 = hfreqmax/vtotal. If that exceeds vfreqmax, the - limit is on the vfreq side and we use vfre = vfreqmax and hfreq = vfreqmax*vtotal. - If it doesn't, the mode is limited by hfreq and we have to use vfreq = vfreq2. - Note, that if this is smaller than vfreqmin, the mode cannot be displayed. In - the vfreq-limited case, you might exceed hfreqmin, which can be countered by - using line doubling facilities, if available. You can also add extra blank lines - (increase vtotal) as a last-resort alternative.</font></p> -<p><font face="Arial, Helvetica, sans-serif">c) Now that you have hfreq and vfreq, - calculate the pixel clock using pixclock=hfreq*htotal. Use the next lower pixel - clock. If you are below the lowest clock, you might want to try horizontal doubling - features or you will have to pad the mode by increasing htotal.</font></p> -<p><font face="Arial, Helvetica, sans-serif">d) Again, check the monitor limits. - You might be violating lower bounds now... In that case you might need to resort - to choosing a higher clock and padding as well.</font></p> -<p><font face="Arial, Helvetica, sans-serif">e) You now have pixclock, width, - height, htotal and vtotal. Calculate the sync start positions: hss=width+(htotal-width)/2/3; - vss=height+(vtotal-height)/3. Make sure to properly align them as required by - the video card hardware. hss usually has to be a multiple of 8.</font></p> -<p><font face="Arial, Helvetica, sans-serif">f) SyncEnd is calculated similarly: - hse=hss+(htotal-width)/2 and vse=vss+2.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">3.4 Recipe for Monosync</font></h3> -<p><font face="Arial, Helvetica, sans-serif">a) Calculate the number of lines. - As hfreq and vfreq are given, vtotal is fixed: vtotal=hfreq/vfreq. If there - are multiple vfreqs allowed, choose them according to your desired vtotal (i.e. - one that gives the lowest vtotal above what you really need).</font></p> -<p><font face="Arial, Helvetica, sans-serif">b) Calculate the pixelclock. pixclock=hfreq*htotal. - htotal starts at the same estimate (width*1.2) we used above.</font></p> -<p><font face="Arial, Helvetica, sans-serif">c) Adjust the pixelclock to hardware-limits. - Adjust <b>UP</b>. Now recalculate the htotal=pixclock/hfreq.</font></p> -<p><font face="Arial, Helvetica, sans-serif">d) Go to 3.3. </font></p> -<p><font face="Arial, Helvetica, sans-serif">An important final word. Most video + +<p>This is pretty much what my monitor + shows now, if I ask it. +</p> + +<h3>3.3 Recipe for multisync monitors</h3> + +<p> +a) Determine the totals by calculating +htotal = width*1.2 and vtotal = height*1.1. +</p> + +<p> +b) Check what limits the refresh +rate by calculating vfreq2 = hfreqmax/vtotal. If that exceeds vfreqmax, the +limit is on the vfreq side and we use vfre = vfreqmax and hfreq = vfreqmax*vtotal. +If it doesn't, the mode is limited by hfreq and we have to use vfreq = vfreq2. +Note, that if this is smaller than vfreqmin, the mode cannot be displayed. In +the vfreq-limited case, you might exceed hfreqmin, which can be countered by +using line doubling facilities, if available. You can also add extra blank lines +(increase vtotal) as a last-resort alternative. +</p> + +<p> +c) Now that you have hfreq and vfreq, +calculate the pixel clock using pixclock=hfreq*htotal. Use the next lower pixel +clock. If you are below the lowest clock, you might want to try horizontal doubling +features or you will have to pad the mode by increasing htotal. +</p> + +<p> +d) Again, check the monitor limits. +You might be violating lower bounds now... In that case you might need to resort +to choosing a higher clock and padding as well. +</p> + +<p> +e) You now have pixclock, width, +height, htotal and vtotal. Calculate the sync start positions: hss=width+(htotal-width)/2/3; +vss=height+(vtotal-height)/3. Make sure to properly align them as required by + the video card hardware. hss usually has to be a multiple of 8. +</p> +<p> +f) SyncEnd is calculated similarly: +hse=hss+(htotal-width)/2 and vse=vss+2. +</p> + +<h3>3.4 Recipe for Monosync</h3> + +<p> +a) Calculate the number of lines. +As hfreq and vfreq are given, vtotal is fixed: vtotal=hfreq/vfreq. If there +are multiple vfreqs allowed, choose them according to your desired vtotal (i.e. +one that gives the lowest vtotal above what you really need). +</p> + +<p> +b) Calculate the pixelclock. pixclock=hfreq*htotal. + htotal starts at the same estimate (width*1.2) we used above. +</p> + +<p> +c) Adjust the pixelclock to hardware-limits. + Adjust <b>UP</b>. Now recalculate the htotal=pixclock/hfreq. +</p> + +<p> +d) Go to 3.3. +</p> + +<p> +An important final word. Most video card documentations give you the exact equations needed to set a mode. Here, - we give approached values. Use the exact values given in the documents.</font></p> -<h3><font face="Arial, Helvetica, sans-serif">3.5 Colors</font></h3> -<p><font face="Arial, Helvetica, sans-serif">There exist an endless number of - colors, but colors have a special property. If you take two colors and mix them - together you get a different color. There exist many models to represent colors, - but fbdev is based on what is known as the RGB color model. Out of all the colors, - there exist three colors in this model which when mixed in different amounts - can produce any color. These colors are known as primary colors. There does - exist a physical limit to mixing colors. If you take and mix red, green, and - blue in equal amounts you get gray. Now if you make each color component equally - brighter, the final color will become white. Now their reaches a point when - making each component brighter and brighter you will still end up with white. - You can increase the intensity of a color component by any amount from some - initial value up to this physical limit. This is where the image depth comes - in. As you know, on most cards you can have an image depth from one bit to 32 - bits. Image depth is independent of the mapping from the pixel to the color - components. It is also independent of the memory layout to pixel mapping. Note - that some cards have a complex mapping from the pixel values to the color components - (red, blue, green) as well as video memory to pixel mapping. If this is the - case, you will have to consult your documentation on your video card to see - what the mapping exactly is. Here are the mappings defined from top to bottom - in fbdev starting with the value of the color components:</font></p> + we give approached values. Use the exact values given in the documents. +</p> + +<h3>3.5 Colors</h3> + +<p> +There exist an endless number of +colors, but colors have a special property. If you take two colors and mix them +together you get a different color. There exist many models to represent colors, +but fbdev is based on what is known as the RGB color model. Out of all the colors, +there exist three colors in this model which when mixed in different amounts +can produce any color. These colors are known as primary colors. There does +exist a physical limit to mixing colors. If you take and mix red, green, and +blue in equal amounts you get gray. Now if you make each color component equally +brighter, the final color will become white. Now their reaches a point when +making each component brighter and brighter you will still end up with white. +You can increase the intensity of a color component by any amount from some +initial value up to this physical limit. This is where the image depth comes +in. As you know, on most cards you can have an image depth from one bit to 32 +bits. Image depth is independent of the mapping from the pixel to the color +components. It is also independent of the memory layout to pixel mapping. Note +that some cards have a complex mapping from the pixel values to the color components +(red, blue, green) as well as video memory to pixel mapping. If this is the +case, you will have to consult your documentation on your video card to see +what the mapping exactly is. Here are the mappings defined from top to bottom +in fbdev starting with the value of the color components: +</p> + <table width="151" border="0" cellpadding="0" cellspacing="0" align="center"> <tr align="center"> - <td><font face="Courier New, Courier, mono" size="2"> {red, blue, green}</font></td> + <td><font size="2"> {red, blue, green}</td> </tr> <tr align="center"> - <td><font face="Courier New, Courier, mono" size="2"> |</font></td> + <td><font size="2"> |</td> </tr> <tr align="center"> - <td> <font face="Courier New, Courier, mono" size="2"><i>FB_VISUAL_MONO01</i></font></td> + <td> <font size="2"><i>FB_VISUAL_MONO01</i></td> </tr> <tr align="center"> - <td> <font face="Courier New, Courier, mono" size="2"><i>FB_VISUAL_MONO10</i></font></td> + <td> <font size="2"><i>FB_VISUAL_MONO10</i></td> </tr> <tr align="center"> - <td> <font face="Courier New, Courier, mono" size="2"><i>FB_VISUAL_TRUECOLOR - </i></font></td> + <td> <font size="2"><i>FB_VISUAL_TRUECOLOR + </i></td> </tr> <tr align="center"> - <td> <font face="Courier New, Courier, mono" size="2"><i>FB_VISUAL_PSEUDOCOLOR - </i></font></td> + <td> <font size="2"><i>FB_VISUAL_PSEUDOCOLOR + </i></td> </tr> <tr align="center"> - <td> <font face="Courier New, Courier, mono... [truncated message content] |
