When constructing a modeline for use with the Chips and Technologies driver you'll needed to considered several points
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.
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.
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).
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
"pixmap cache
". Leaving too little memory available for
the cache will only have a detrimental effect on the graphics
performance.
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.
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.
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 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 "use_modeline
" and/or possibly the
"fix_panel_size
" 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: "use_modeline" Tested on a Prostar 8200, (640x480, 65548, 1Mbyte)
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)
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)
The NEC Versa 4080 just needs the "fix_panel_size" option.