First of all, make sure that the default modes selected from your
is supported by your monitor, i.e. make sure the horizontal sync limit is
correct. It is best to start with standard 640x480x256 with a 25.175 MHz
clock (by specifying a single horizontal sync of 31.5) to make sure the
driver works on your configuration. The default mode used will always be
the first mode listed in the modes line, with the highest dot clock listed
for that resolution in the timing section.
Note that some VESA standard mode timings may give problems on some monitors (try increasing the horizontal sync pulse, i.e. the difference between the middle two horizontal timing values, or try multiples of 16 or 32 for all of the horizontal timing parameters).
You are using a mode that your monitor cannot handle. If it is a non-standard mode, maybe you need to tweak the timings a bit. If it is a standard mode and frequency that your monitor should be able to handle, try to find different timings for a similar mode and frequency combination.
This problem shows especially when drawing operations such as
scrolling are in progress.
If you're using a 542x/3x/46/6x/754x, try the
option. Failing that, you can try the
or use a lower dot clock. If that is not sufficient, the
"noaccel" option or
probably help. When using a 546x, option
"fifo_aggressive" can also be tried.
Horizontal waving or jittering of the whole screen, continuously (independent from drawing operations). You are probably using a dot clock that is too high; it is also possible that there is interference with a close MCLK. Try a lower dot clock. You can also try to tweak the mode timings; try increasing the second horizontal value somewhat. Here's a 65 MHz dot clock 1024x768 mode (about 60 Hz) that might help:
"1024x768" 65 1024 1116 1228 1328 768 783 789 818If you are using programmable clocks with Clockchip
"cirrus", try disabling it and using the default set of clocks.
"noaccel" option. If that works,
somewhat better performance. Check that the BIOS settings are OK;
in particular, disable caching of 0xa0000-0xaffff. Disabling hidden
DRAM refresh may also help.
This may be related to a bug in one of the accelerated functions, or
a problem with the BitBLT engine. Try the
"no_bitblt" option. Also check the BIOS settings.
Same as for the above entry.
This indicates a DRAM configuration problem. If your card has two
megabytes of memory, try the
"no_2mb_banksel" option, or use
videoram "1024" if you only use 1 Mbyte for the virtual
This has been reported on non-standard video implementations.
This can happen if the dot clock is high enough to leave very little bandwidth for drawing (e.g. 40 MHz on a 512K card), and (5422-style) acceleration is used.
Probably related to MCLK setting that is too high (can happen with linear addressing even though banked mode runs OK).
Try forcing the chipset to a type that is most similar to what you have.
This may be related to a problem with system-to-video-memory BitBLT
operations. Try the
"no_imageblt" option if it annoys you.
This has been reported on some configurations. In XFree86 3.1
the SVGA server probe would corrupt a register on the 543x,
requiring a Chipset line. Normally you should be able to restore
the textmode font using a utility that sets it (
restorefont on Linux).
It is possible that high dot clocks on the video card interfere with other components in the system (e.g. disk I/O), because of a bad card and/or motherboard design. It has been observed on some PCI 5428-based cards (which are very rare, since the 5428 chip doesn't support PCI).
With high dot clocks, the graphics card's hardware cursor
doesn't operate correctly. Try option
use a lower screen refresh.
This problem is usually associated with using a virtual screen size larger than the screen display size. The garbage pixels are unused portions of the frame buffer that result from padding each scanline to an integral number of memory tiles. To eliminate the extra pixels, use a screen display mode whose pixel width is evenly divisible by 128 / bits per pixel.
Same as above entry.
This problem usually happens at high bit depths and while
the screen is changing rapidly (catting a long file or
dragging a large window around). The RamBus memory is
being overdriven. Use Option
"med_dram", or, if
the problem persists, Option
If are having driver-related problems that are not addressed by this document, or if you have found bugs in accelerated functions, you can try contacting the XFree86 team (the current driver maintainer, Corin Anderson, can be reached at firstname.lastname@example.org), or post in the Usenet newsgroup "comp.windows.x.i386unix".
In fact, reports (success or failure) are very welcome, especially on configurations that have not been tested. You can do this via the BetaReport form (mail to report@XFree86.org). You may want to keep an eye on forthcoming beta releases at www.xfree86.org.