<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Modelines </TITLE>
</HEAD>
<BODY BGCOLOR="#efefef" TEXT="black" LINK="blue" VLINK="#551A8B" ALINK="red">

<A HREF="chips.html"><EM> Information for Chips and Technologies Users</EM></A>
 <b>:</b> <EM>Modelines </EM><BR>
<b>Previous:</b> <A HREF="chips3.html"><EM>XF86Config Options </EM></A><BR>
<b>Next:</b> <A HREF="chips5.html"><EM>The Full Story on Clock Limitations </EM></A>


<HR NOSHADE>
  <H2><A NAME="4"></A>4. Modelines </H2>

<p>When constructing a modeline for use with the Chips and Technologies
driver you'll needed to considered several points</p>
<p>
<dl>
<dt><b> * Virtual Screen Size </b><dd><p>It is the virtual screen size that determines the amount
of memory used by a mode. So if you have a virtual screen size
set to 1024x768 using a 800x600 at 8bpp, you use 768kB for the
mode. Further to this some of the XAA acceleration requires that
the display pitch is a multiple of 64 pixels. So the driver will
attempt to round-up the virtual X dimension to a multiple of 64,
but leave the virtual resolution untouched. This might further
reduce the available memory.</p>
<dt><b> * 16/24/32 Bits Per Pixel </b><dd><p>Chips later than the ct65540 are capable of supporting
Hi-Color and True-Color modes. These are implemented in the current
server. The clocks in the 6554x series of chips are internally
divided by 2 for 16bpp and 3 for 24bpp, allowing one modeline to
be used at all depths.  The effect of this is that the maximum
dot clock visible to the user is a half or a third of the value
at 8bpp. The 6555x series of chips doesn't need to use additional
clock cycles to display higher depths, and so the same modeline
can be used at all depths, without needing to divide the clocks.
Also 16/24/32 bpp modes will need 2 , 3 or 4 times respectively more
video ram.</p>
<dt><b> * Frame Acceleration</b><dd><p>Many DSTN screens use frame acceleration to improve the
performance of the screen. This can be done by using an external
frame buffer, or incorporating the framebuffer at the top of video
ram depending on the particular implementation. The Xserver assumes
that the framebuffer, if used, will be at the top of video ram.
The amount of ram required for the framebuffer will vary depending
on the size of the screen, and will reduce the amount of video
ram available to the modes. Typical values for the size of the
framebuffer will be 61440 bytes (640x480 panel), 96000 bytes
(800x600 panel) and 157287 bytes (1024x768 panel).</p>
<dt><b> * H/W Acceleration </b><dd><p>The H/W cursor will need 1kB for the 6554x and 4kb for the
65550. On the 64300 chips the H/W cursors is stored in registers and
so no allowance is needed for the H/W cursor. In addition to this
many graphics operations are speeded up using a
"<code>pixmap cache</code>". Leaving too little memory available for
the cache will only have a detrimental effect on the graphics
performance.</p>
<dt><b> * VESA like modes </b><dd><p>We recommend that you try and pick a mode that is similar
to a standard VESA mode. If you don't a suspend/resume or LCD/CRT
switch might mess up the screen. This is a problem with the video
BIOS not knowing about all the funny modes that might be selected.</p>
<dt><b> * Dot Clock </b><dd><p>For LCD screens, the lowest clock that gives acceptable
contrast and flicker is usually the best one. This also gives
more memory bandwidth for use in the drawing operations. Some
users prefer to use clocks that are defined by their BIOS. This
has the advantage that the BIOS will probably restore the clock
they specified after a suspend/resume or LCD/CRT switch. For a
complete discussion on the dot clock limitations, see the next
section.</p>
</dl>
</p>
<p>The driver is capable of driving both a CRT and a flat panel
display. In fact the timing for the flat panel are dependent on the
specification of the panel itself and are independent of the particular
mode chosen. For this reason it is recommended to use one of the programs
that automatically generate XF86Config files, such as "<code>xf86config</code>"
or "<code>XF86Setup</code>".</p>
<p>However there are many machines, particular those with 800x600 screen or
larger, that need to reprogram the panel timings. The reason for this is
that the manufacturer has used the panel timings to get a standard EGA
mode to work on flat panel, and these same timings don't work for an SVGA
mode. For these machines the "<code>use_modeline</code>" and/or possibly the
"<code>fix_panel_size</code>" option might be needed. Some machines that 
are known to need these options include.</p>
<p>
<blockquote>
<pre>
Modeline "640x480@8bpp"	  25.175  640  672  728  816   480  489  501  526
Modeline "640x480@16bpp"  25.175  640  672  728  816   480  489  501  526
Options: "use_modeline"
Tested on a Prostar 8200, (640x480, 65548, 1Mbyte)
</pre>
</blockquote>
</p>
<p>
<blockquote>
<pre>
Modeline "800x600@8bpp"	  28.322  800  808  848  936   600  600  604  628
Options: "fix_panel_size", "use_modeline"
Tested on a HP OmniBook 5000CTS (800x600 TFT, 65548, 1Mbyte)
</pre>
</blockquote>
</p>
<p>
<blockquote>
<pre>
Modeline "800x600@8bpp"	  30.150  800  896  960 1056   600  600  604  628
Options: "fix_panel_size", "use_modeline"
Test on a Zeos Meridan 850c (800x600 DSTN, 65545, 1Mbyte)
</pre>
</blockquote>
</p>
<p>The NEC Versa 4080 just needs the "fix_panel_size" option.</p>

 <HR NOSHADE>
<A HREF="chips.html"><EM> Information for Chips and Technologies Users</EM></A>
 <b>:</b> <EM>Modelines </EM><BR>
<b>Previous:</b> <A HREF="chips3.html"><EM>XF86Config Options </EM></A><BR>
<b>Next:</b> <A HREF="chips5.html"><EM>The Full Story on Clock Limitations </EM></A>



</BODY>
</HTML>
