All of the Western Digital chipsets after the PVGA1 support the ability
to use the memory-refresh clock as an alternate dot-clock for video
timing. Hence for all of these chipsets, the server will detect one more
clocks than ``normal''. What this means is that if you have an old
`Clocks'
line in your XF86Config file, you should comment it out, and rerun
the server with the `-probeonly' option to find all of the clock
values. All but the
last should be the same as what you had before; the last will be new.
For the WD90C00 chipset, the chipset will only support 640x480 in 256-color mode. Even though 512k of memory should allow better than 800x600, the chipset itself cannot do this. This is stated in the databook (which lists 1024x768x16 and 640x480x256 for specifications). We have also witnessed this behavior.
The server will detect 17 clocks for the WD90C24, WD90C30 and WD90C31
chipsets. If you have one of these chipsets, you should let the server
re-probe the clocks and update your XF86Config.
There is an `Option' flag available for the XF86Config
file that is specific to the Western Digital chipsets (except the
WD90C24). This option is "swap_hibit". We have determined via
experimentation that the WD90C1x and WD90C3x chipsets need the high-order
clock-select bit inverted, and the PVGA1 and WD90C00 need it
non-inverted. This is hardcoded into the driver. Since our sample-set
was rather small, we have provided the "swap_hibit" option to
invert this behavior. If the clocks detected by the server show a very
low last clock (under 28Mhz), then this option is likely needed.