Re: [Unichrome] New mode code: good modes refused.

[Luc V. <li...@sk...>]

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@1024@60. 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@85Hz where 640x350 is sitting 
now.

> > 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@R 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.
> 
> Benno
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 
preference).

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.

Luc Verhaegen