On Tue, Dec 19, 2006 at 04:26:12PM +0100, Benno Schulenberg wrote:
> Luc Verhaegen wrote:
> > On Sat, Dec 09, 2006 at 12:18:12PM +0100, Benno Schulenberg wrote:
> > > Mode "640x350" # vfreq 70.100Hz, hfreq
> > > 31.475kHz DotClock 25.180000
> > > HTimings 640 656 752 800
> > > VTimings 350 387 389 449
> > > Flags "-HSync" "+VSync"
> > > EndMode
> > Yikes. You know that detailed mode you're seeing there. That's
> > the monitors preferred mode. So, you get a 17" CRT, prefering
> > 640x350.
> That's pretty silly indeed. But when installing Suse or Ubuntu
> while using this monitor, they would automatically choose the
> 1280x1024 resolution, at about 60 Hz -- much too low. Maybe that's
> how things are supposed to work, but I would expect X to either
> pick the monitor's preferred mode, or pick the highest possible
> resolution that achieves at least 72 Hz.
Well, a correctly working X (when not using my driver, because my
driver replaces all of X's mode validation) should now (anything younger
than 7.1) always land you with 640x350 first. It's what your monitor
says it handles best.
In future you should be able to quickly change that without restarting
X. Any working mode, even if it's 640x350, should allow one to select
a better one.
Well, your monitor cannot handle better than 1280@.... Your monitor
claims not being able to handle a higher dotclock than 110Mhz.
This is probably why you moved to 1024x768. The real trouble here is
that your monitor should've had 1024x768@... where 640x350 is sitting
> > Now, about the 85Hz issue. This was because i didn't set the mode
> > type correctly when i generated modes (as EDID only provides
> > HxV@... for standard timing). Fixed and pushed now.
> Okay. It now chooses the 1024x768 mode at 85 Hz without having to
> add @85 in the Modes directive. Nice.
> For completeness, attached the log.
Yeah, that @85 hack was just there to trigger a different mechanism.
When trying to match up names, this one was left out. Then my code
reverts to trying to parse the name and then generating the mode.
So this forced my code into doing the right thing, without having to
provide a full modeline.
Now that that type bug is fixed, the name "1024x768" matches the highest
type (in this case, monitor provided instead of X provided), then
highest refresh rate (with the bug, the 85Hz one was the same type as X
provided modes, so it was already filtered out here), then lowest
dotclock (so that reduced blanking modes, when allowed, will have
Anyway, thanks for seeing this through. Digging this out has shown me
how grossly inadequate the logging is now. A lot of magic goes into
selecting the right modes, and it'll be hard finding a balance between
verbosity and keeping the size of the log down.
It's also nice to encounter buggered EDID blocks (from a developer
point of view), and to see how they throw spanners in the works.