Comment 8 for bug 68654

By the way, in fixing bug 27667 (which in a way is the corollary to this one) I've decided to chuck the CRT resolution algorithm.

Of course, that fix actually exacerbates this particular bug, giving us a regression on CRTs. However, as pointed out above, even for CRTs its a bad default algorithm. I suppose in the "old days" CRTs may only have had one resolution that was too high to read, so tossing the highest would give adequate results. These days, as Mantas demonstrates, CRTs can support resolutions far, far beyond what's appropriate for default desktop use.

The good news is that this gives us a clean slate. I'd like to work with you guys to achieve a much superior algorithm for CRTs, that will scale better into the future than our old algorithm did.

One factor we must keep in mind though, is that currently xresprobe can't tell the difference between a CRT and an LCD with an "analog" connection. The way it tries to tell LCDs and CRTs apart is to get the output from ddcprobe and scan for "*digital*". Unfortunately, the LCDs I have to test with have VGA connections and are listed as "analog", and thus get detected by xresprobe as CRTs.

So, we need either of two things. One would be a general purpose algorithm that solves the CRT needs and doesn't impact LCDs. The other is to find a better mechanism for identifying LCDs that ddcprobe shows as "analog". If either of these can be satisfied, then it should be straightforward to implement an algorithm such as the one Mantas proposes.

I'd really like to see this solved for Gutsy, since otherwise we're going to show a regression on this bug. So I would greatly appreciate any research / advice / ideas people have on this one.