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.

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: "UseModeline"
Tested on a Prostar 8200, (640x480, 65548, 1Mbyte)

Modeline "800x600@8bpp"	  28.322  800  808  848  936   600  600  604  628
Options: "FixPanelSize", "UseModeline"
Tested on a HP OmniBook 5000CTS (800x600 TFT, 65548, 1Mbyte)

Modeline "800x600@8bpp"	  30.150  800  896  960 1056   600  600  604  628
Options: "FixPanelSize", "UseModeline"
Test on a Zeos Meridan 850c (800x600 DSTN, 65545, 1Mbyte)

The NEC Versa 4080 just needs the "FixPanelSize" option. To the best of my knowledge no machine with a HiQV needs the "UseModeline" or "FixPanelSize" options.