Screen resolution set too high for CRT displays

[Marco Aurélio Graciotto Silva]

The Ubuntu Live CDs (both 5.04 and 5.10 RC) set the resolution to the maximum supported by the display. This is
great for LCD screens, but for CRTs it's not optimal. A better strategy would be to set the maximum resolution
supported for a reasonable refresh ratio, of at least 75 hz. With the current Live CD, I get 1600x1200 at 60 Hz,
when I usually use the display at 1152x864, the highest resolution supported using 75 Hz refresh ratio.

[Matt Zimmerman (mdz)]

(In reply to comment #0)
> The Ubuntu Live CDs (both 5.04 and 5.10 RC) set the resolution to the maximum
supported by the display.

No they don't; they (more or less) use the second highest resolution mode, which
is very often the right choice.

Run "sudo ddcprobe" to see which modes your CRT claims to support.

[Marco Aurélio Graciotto Silva (magsilva)]

Below is the output from ddcprobe. The 'more or less' on the resolution chooser
algorithm seens to be fooled by displays that report the same resolution twice
but with different refresh ratio. I couldn't find a documentation about ctiming
and dtiming, I imagine it's non-interlaced and interlaced mode. If the second
highest resolution haven't considered interlaced modes, the resolution choosen
(1280x1024) would be fine (although 1152x864, the resolution I'm using right
now, looks better - and it's not listed by ddcprobe). May be it could be a good
idea to try a good non-interlaced mode instead of trying interlaced mode.
Actually, I'd prefer interlaced mode as a last resource (instead of a main option).

vbe: VESA 3.0 detected.
oem: NVIDIA
vendor: NVIDIA Corporation
product: NV18 Board - V32-B04z Chip Rev A4
memory: 65536kb
mode: 640x400x256
mode: 640x480x256
mode: 800x600x16
mode: 800x600x256
mode: 1024x768x16
mode: 1024x768x256
mode: 320x200x64k
mode: 320x200x16m
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
mode: 1024x768x64k
mode: 1024x768x16m
edid: 1 3
id: 0312
eisa: PBR0312
serial: 1dde37c4
manufacture: 3 2005
input: sync on green, analog signal.
screensize: 31 23
gamma: 1.270000
dpms: RGB, active off, suspend, standby
timing: 720x400@70 Hz (VGA 640x400, IBM)
timing: 640x480@75 Hz (VESA)
timing: 800x600@60 Hz (VESA)
timing: 800x600@72 Hz (VESA)
timing: 800x600@75 Hz (VESA)
timing: 1024x768@87 Hz Interlaced (8514A)
timing: 1024x768@75 Hz (VESA)
ctiming: 800x600@85
ctiming: 800x600@100
ctiming: 1024x768@85
ctiming: 1600x1200@60
ctiming: 1280x1024@60
ctiming: 640x480@85
dtiming: 1600x1200@78
monitorid: Serie 786NS
monitorname: Serie 786NS
monitorrange: 30-75, 60-100

[Daniel Stone (daniels)]

the difference between ctiming and dtiming isn't interlaced vs non-interlaced,
it's between 'i can do 1024x768@60', and 'i can do 1024x768@60, with this long a
vblank, this long a vporch, etc, etc' -- detailed timing information.

[Marco Aurélio Graciotto Silva (magsilva)]

Well, but that doesn't settle the problem yet. The bug in question is that the screen resolution is set way
to high for the current display. I just thought about interlaced and non-interlaced because 1600x1200@78 was
clearly in interlaced mode in my monitor (and that would ease a solution).

In the first comment, the answer was:
> No they don't; they (more or less) use the second highest resolution mode, which
> is very often the right choice.

Well, if dtiming and ctiming is of no meaning, the resolutions available, from highest to lowest, as
reported from ddcprobe, were:

1600x1200@78
1600x1200@60
1280x1024@60
1024x768@87 Hz Interlaced (8514A)
1024x768@85
1024x768@75 Hz (VESA)
...

Well, the resolution the screen was working at was the second highest resolution, that I clearly understood.
What I'm suggesting is that the second resolution, if the first resolution is the same (but at a different
refresh ratio), isn't the best choice.

Changing from bug to a enhancement.

[Daniel Stone (daniels)]

This bug has been marked as a duplicate of bug 12829.