4. Modelines

When constructing a modeline for use with the Chips and Technologies
driver you'll needed to considered several points

* Virtual Screen Size

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.

* 16/24/32 Bits Per Pixel

Hi-Color and True-Color modes are implemented in the
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 HiQV 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.

* Frame Acceleration

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).

* H/W Acceleration

The H/W cursor will need 1kB for the 6554x and 4kb for the
65550. On the 64300 chips the H/W cursor 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
"pixmap cache". Leaving too little memory available for
the cache will only have a detrimental effect on the graphics
performance.

* PseudoColor Overlay

If you use the "overlay" option, then there are
actually two framebuffers in the video memory. An 8bpp one and a
16bpp one. The total memory requirements in this mode of operation
is therefore similar to a 24bpp mode. The overlay consumes memory
bandwidth, so that the maximum dotclock will be similar to a 24bpp
mode.

* XVideo extension*

Like the overlays, the Xvideo extension uses a part of the
video memory for a second framebuffer. In this case enough memory
needs to be left for the largest unscaled video window that will be
displayed.

* VESA like modes

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.

* Dot Clock

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.

* Dual-head display

Dual-head display has two effects on the modelines. Firstly,
the memory requirements of both heads must fit in the available
memory. Secondly, the memory bandwidth of the video processor is
shared between the two heads. Hence the maximum dot-clock might
need to be limited.

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 "xf86config"
or "XF86Setup".

However there are many older machines, particularly 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 "UseModeline"
and/or possibly the "FixPanelSize" option might be needed. Some
machines that are known to need these options include.