Default Resolution on high quality CRT monitors is too high

Bug #68654 reported by Fabio
16
Affects Status Importance Assigned to Milestone
Baltix
Invalid
Undecided
Unassigned
xresprobe (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

I have a Samsung Syncmaster 700IFT, it's a CRT monitor that support a maximum resolution of 1600x1200.

I had this bug with Dapper Drake (i have not tried with other releases)

When I run the live CD or I install from a alternated CD, the login screen (and the user desktop) are set to 2048x1536, and this is a NOT supported resolution from my monitor.

Luckily my monitor didn't fail and I was able to change from the GUI the resolution for my user and to change the resolution of the login screen i had to manually edit the xorg configuration file (and this is not easy for a newbie user, luckily i'm not so much newbie)

I experienced this problem with my ATI Radeon 9600 Pro and also with a integrated graphics NVidia chip on a cheap Asrock mother board owned by my friend (and in these two cases, the same problem occurred)

My opinion is that the default resolution in "live" mode and after the first boot of an installed system should be set by default to a safe resolution like 1024x768.

I think that could be good to permit to a user (after sudo authentication) to change from a GUI the resolution of the login screen, because for a newbie user can be very hard to edit the xorg configuration files.

Thank you very much.

Fabio (gandolaf)
description: updated
Revision history for this message
Mantas Kriaučiūnas (mantas) wrote : Ubuntu Default Resolution couses damage to the eyes on high quality CRT monitors because of too small fonts and too low refresh rate :(

Ubuntu has bad default resolution choosing algorithm for CRT monitors. It's not related just to Samsung monitors - I've noticed the same situation (when Ubuntu chooses too high resolution, for example 1920x1440 or even 2048x1536 resolution on 17" or 1600x1200 on 15'' high quality CRT monitors) several times.

Now xresprobe utility simply chooses second from the highest mode from modes, which CRT monitor supports and if CRT monitor can work on very high resolutions then too high resolution is chosen as default. Because of this, menus and other texts are almost unreadable and monitor causes damage to the eyes, because of very small fonts and too low refresh rate (60 Hz) :(

It's a nonsense, because now Ubuntu spoils the eyes for users of high or medium quality CRT monitors by default:(

I will show you example with a high quality 17" CRT monitor, which horizontal freq is 30-96 kHz and refresh rate is 50-160 Hz.
xresprobe output (when XRESPROBE_DEBUG is set) looks like this:

laptop: ; ddc: yes
attempting DDC detection
raw timings - 2048x1536 1920x1440 1600x1200 1280x1024 1280x1024 1024x768 1024x768 1024x768 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 800x600 720x400 720x400 640x480 640x480 640x480 640x480 640x480 640x480
id: SyncMaster
res: 1920x1440 1600x1200 1280x1024 1024x768 832x624 800x600 720x400 640x480
freq: 30-96 50-160
disptype: crt

So, as you see default resolution was set to 1920x1440 on 17'' CRT, which is a total nonsense, because fonts are very very small (so small, that user simply can't find how to change resolution - menu items in system menu are unreadable) and refresh rate is only 60 Hz:

$ ddcprobe |grep 1920x1440
ctiming: 1920x1440@60

Problem is, that ubuntu developers don't want to change default resolution choosing algorithm for CRT displays - there are lots of bugreports about too high default resolution and too low refresh rate, but it seems ubuntu developers don't wanna hear this - look at commens in bug #12829 for example.

ddcprobe command does provide monitor size - for 17" CRT:

$ ddcprobe |grep size
screensize: 32 24

Because we can know CRT size, we can simply limit max resolution to one, which can make sense (for example on 19" CRT's max should be 1920x1440, on 17" - 1600x1200, on 15" and 14" - 1280x1024) and never choose default resolution higher than this.

Btw, I think this bug isn't a duplicate of #12829 - I think this bug is about a patch for xresprobe to care about screensize (look above) and limit default resolution for CRT monitors according to screensize.

Btw2, manufacturers recommend to use 1024x768 or 1280x1024 on this high quality 17" CRT monitor(see http://monitor.samsung.de/article.asp?artid=5264C7DC-A9FB-4E84-835D-E1B14BD6BD6D&show=specs), so, limiting 17" monitors to 1600x1200 is really comfortable for majority of users.
If Ubuntu developers agree I can provide a patch for ddcprobe.sh script to care about screensize.

Revision history for this message
Mantas Kriaučiūnas (mantas) wrote :

assigning bugreport to xresprobe and confirming, as I have the same situation with another high quality 17" CRT monitor.

Changed in xorg:
status: Unconfirmed → Confirmed
Revision history for this message
Mantas Kriaučiūnas (mantas) wrote :

Similar problem is described in bug #50389:
"When I start the LiveCD, X by default selects the most painful for the eyes screen resolution my 19" CRT can do: 2048x1536@60Hz. A much less hurting resolution must be selected manually. [..]"

Revision history for this message
Tollef Fog Heen (tfheen) wrote :

If you come up with a reasonable algorithm for deciding on which resolution to choose, please post it. Please do remember that some monitors lie about sizes, etc so you need to not be too smart in order to not give horrible results on those monitors.

Revision history for this message
ericw (ewasylishen) wrote :

I find this annoying as well. My monitor is a 17 inch samsung SyncMaster 700NF, and Ubuntu (up to Feisty Herd 3) starts at 2048x1536@60hz.

What it currently does (at least with my monitor) is pick the highest possible resolution at 60hz. A decent algorithm for CRT's would be to choose the highest standard resolution the monitor supports at 85hz; and I can't see any cases in which this would work worse than the current way (assuming it can tell the difference between CRT's and LCD's)

Even a 15" CRT monitor I had ten years ago or so could do 1024x768@85hz.

Thanks for any help :)

Revision history for this message
Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount) wrote :

Some users may not be able to boot from the live-cd at all because of this. They'll be able to if they boot with the monitor disconnected. This obviously doesn't fix anything, but it'll enable them to install and fix the resolution.

Revision history for this message
Bryce Harrington (bryce) wrote :

Newer xservers include support for a "Preferred Resolution", which I believe is autodetected from the hardware. It seems the ideal solution to this bug would to make better use of that. The idea of capping the default to 1280x1024 or 1600x1200 may be worth exploring if the preferred resolution approach can't do it.

(Its possible we can sidestep this whole issue in hardy by letting Xorg autoconfigure itself.)

Changed in xresprobe:
status: Confirmed → Triaged
Bryce Harrington (bryce)
Changed in xresprobe:
importance: Undecided → Medium
Revision history for this message
Bryce Harrington (bryce) wrote :

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.

Bryce Harrington (bryce)
Changed in xresprobe:
assignee: nobody → bryceharrington
status: Triaged → In Progress
Bryce Harrington (bryce)
Changed in xresprobe:
assignee: bryceharrington → nobody
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Hi, xresprobe is no longer used in Hardy Heron, the development version which will become Ubuntu 8.04. Because of that I'm closing this bug. Please test Hardy (alpha3 or later), and if your hardware still fails to get a correct resolution (or if it drops to failsafe mode), file a bug against the driver package (xserver-xorg-video-$driver). Thanks!

Changed in xresprobe:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.