> 1) I have yet to do the shark hardware fix. My hardware guru informs
> me that this works by dropping the Vco voltage to the graphics chip
> slightly which results in a smoother signal but has the side effect of
> dropping the maximum attainable dot clock. Does this mean that all the
> mode definitions are going to need changing when I do the fix? Or just
> that I'll get a lower frame rate? Or even that I'll lose the ability
> to do the really big ones (1600x1200?)/

The main impact of the fix is to move a couple of components. The filter
and feedback part of the VCO is very sensitive to noise -- which causes
the clock frequency to jiggle about a bit, if you have a good scope and
trigger it on the rising edge of the line sync pulse (i.e. the left hand
edge of the screen) and use delay-after-trigger to watch the falling edge
(i.e. right of the screen) you can see a couple of pixel-time variation
which corresponds to the couple of pixel "swim" you see on the screen.

Anyway, IGST recommend (in an ap note they sent us after the sharks were
being made :-( ) keeping all digital signals out of this area. If you look
on your shark pcb you will see there are lots of them. By moving the filter
components to sit on top of the video chip they are kept far enough away
from the traces that the noise goes away (this also explains why the fix
says to use very short wires, otherwise they act as antennas).

The changes in component values are mainly reversing changes applied during
mnufacturing that removed some of the "swim" but did not fix it.

You should be fine with the dot clocks in the XF86 config file released
for the shark, no need to change anything after the fix. I think 1152x864
is the highest "recommended" resolution, but 1600x1200 in 8 bit should
be ok. 

2) 16 bit mode should work (I haven't tested it on the latest realese yet).
It did on the older X server in the release on the shark web site.
I can send my XF86Config if it would help.

Mark