1440x900 no clock available for mode?

[drew at technteach.com]

So it sounds like I have 3 choices.

1) Ignore the problem for now, and sooner or later a new driver
will be released, which will solve the problem.

2) Delve into the mysteries of downloading, configuring, and 
compiling an appropriate driver.  Poking around it seems like
X11R7.1 is probably the one.  Or would I need a development
version to solve the problem.

3) Delve into the mysteries of writing an xorg.conf file to work 
around the bugs (or are they features) of the driver I have.
First sub mystery on this front is finding the right via_mode.h
to study.  

Which X11Rx.y distribution should I look in?
The following snippet suggests X11R7.0

  X Window System Version 7.0.0
  Release Date: 21 December 2005
  X Protocol Version 11, Revision 0, Release 7.0
  Build Operating System:Linux 2.6.9-34.ELsmp i686Red Hat, Inc.
  Current Operating System: Linux drew2.tnt.private 2.6.17-1.2157_FC5 #1 Tue Jul 11 22:55:46 EDT 2006 i686
  Build Date: 30 June 2006

While browsing around the internet, it sounds like an FC5 update
for X11R7.1 may be imminent, or maybe it's just a bogus rumor.

>snippet from your log:
> (II) Module via: vendor="X.Org Foundation"
>        compiled for 4.3.99.902, module version = 0.1.33
>        Module class: X.Org Video Driver
>        ABI class: X.Org Video Driver, version 0.8
>
>This apparently predates both (unichrome and openchrome) VT3122 dotclock
>generators. There's free modesetting, but at that time it was limited to
>a list of known stable dotclocks, for the most common modes only.
>
>VT3122 pll is a rather akward beast. Dotclock generator wasn't easy to
>get stable while still allowing for sufficient granularity.
>
>Some creativity with regard to the modeline might save you from
>compiling a driver yourself. Just look at the list of known dotclocks
>(it spent most of its life in via_mode.h), and pick one that's closest
>to the current dotclock.
>
>If that still doesn't get you near enough, move the SyncStart and
>SyncEnd values equal amounts left, and reduce the Totals.
>
>On the other hand, my driver uses some incarnation of my bug #5386 code,
>which gives you an unruly modelist which should include your panels
>preferred timing.
>
>I'm not sure where Option "IgnoreEDID" came from. Iirc, VIAs idea of
>what Option "NoDDC" should've been was "NoDDCValue" and that got culled
>more than two years ago. grep tells me that IgnoreEDID is radeon
>specific.