I'm the Ubuntu user who reported this bug, just let me know what you need me to do.

On Thu, Aug 21, 2008 at 19:15:34 -0700, bugzilla-daemon@freedesktop.org wrote:

> (II) RADEON(0): Using hsync ranges from config file
> (II) RADEON(0): Using vrefresh ranges from config file

that might be a problem.  what happens if the log file doesn't give any
hsync/vrefresh ranges?

Cheers,
Julien

You monitor does not specify a preferred mode so the server ends up picking one.  Also as Julien noted the driver is using the sync ranges from the monitor section of your config which may influence that decision.  1280x960 is a valid mode based on the sync ranges provided and it's actually 4:3 whereas 1280x1024 is not.  I suppose it comes down to what mode do you pick as a default on an analog monitor which does not specify a preferred mode.  You can use the preferred mode option in your monitor section to hardcode your preferred mode if you don't like what the xserver picks.

As to the display sizes, both come from the monitor via the EDID:
- Max image size supported by the monitor:
(II) RADEON(0): Max Image Size [cm]: horiz.: 32  vert.: 24
- The extended timings can individually specify an image sizes:
(II) RADEON(0): clock: 40.5 MHz   Image Size:  310 x 230 mm
(II) RADEON(0): clock: 56.2 MHz   Image Size:  310 x 230 mm

> --- Comment #2 from Julien Cristau <jcristau@debian.org>  2008-08-22 05:19:46 PST ---
> what happens if the log file doesn't give any hsync/vrefresh ranges?
> 
bah. i obviously meant *config* file there...

The user isn't specifying anything in their xorg.conf; it's just a stock empty config file (see below).  Here's an updated description of the problem:

"I measured my screen. The viewing area is 32cm wide and like 25 and a
half cm tall.
This 1280x960 stetches everything vertically and leaves two big black
strips up the side of the screen. You'd think it would do the
opposite.."

So it sounds like the driver (or server) is picking an inappropriate modeline.


# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
	Identifier	"Generic Keyboard"
	Driver		"kbd"
	Option		"XkbRules"	"xorg"
	Option		"XkbModel"	"pc105"
	Option		"XkbLayout"	"us"
EndSection

Section "InputDevice"
	Identifier	"Configured Mouse"
	Driver		"mouse"
	Option		"CorePointer"
EndSection

Section "Device"
	Identifier	"Configured Video Device"
EndSection

Section "Monitor"
	Identifier	"Configured Monitor"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
EndSection

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		"Default Screen"
EndSection

The server is injecting that mode.  It's technically valid based on the sync ranges reported by the monitor.  I guess ideally the server should not inject any modelines if the output has an EDID.

A circle is a circle on the monitor when it's 1280x1024, with the
other one it's kinda stretched.
Also, 1280x1024 is simply more information being sent to the screen.
Why on earth would I want to use a resolution /less/ than my screen
supports?
There's people out there with 2560x1600 LCD's, and I have this
pathetic CRT, the least I can do is use it to its fullest potential.

"You can use the preferred mode option in your monitor section to
hardcode your preferred mode if you don't like what the xserver
picks."
Sometimes a problem is so complicated that it comes down to personal
preference.  This is not one of those times.
1280x1024 is the -correct- resolution for my setup.

"1280x960 is a valid mode based on the sync ranges provided and it's
actually 4:3 whereas 1280x1024 is not"
My physical hardware is 5:4 aspect ratio, not 4:3.  If you have
something against 5:4, please take it up with the manufacturers, not
the end users.

Julien, what is it you want me to do exactly?  I have Ubuntu 8.10
alpha4 on a LiveCD..

"It's technically valid based on the sync ranges reported by the monitor."

I thought the only thing worse than display EDID accuracy was ACPI..

(In reply to comment #7)
> A circle is a circle on the monitor when it's 1280x1024, with the
> other one it's kinda stretched.
> Also, 1280x1024 is simply more information being sent to the screen.
> Why on earth would I want to use a resolution /less/ than my screen
> supports?
> There's people out there with 2560x1600 LCD's, and I have this
> pathetic CRT, the least I can do is use it to its fullest potential.
> 

You can.  Just add the preferred mode to your config and be done with it. or change it on the fly with xrandr:
xrandr --output VGA-0 --mode 1280x1024

> "You can use the preferred mode option in your monitor section to
> hardcode your preferred mode if you don't like what the xserver
> picks."
> Sometimes a problem is so complicated that it comes down to personal
> preference.  This is not one of those times.
> 1280x1024 is the -correct- resolution for my setup.

How is this not one of those times?  You monitor is a CRT and does not list a preferred mode, so it comes down to what mode should be picked.  Most people would say 1280x1024@60hz is pretty rough on the eyes.  I would argue that based on your monitor's EDID, 1024x768@85hz would be the preferred mode.  1280x960 happens to be right in the middle.  Some people like 800x600.  That's why there is a preferred mode option.

Naturally if I had it installed instead of just booting the livecd 75
times, I wouldn't mind such a simple modification...
(I don't like trusting my life to a partitioner in an alpha OS)

"Most people would say 1280x1024@60hz is pretty rough on the eyes.  I
would argue that based on your monitor's EDID, 1024x768@85hz would be
the preferred mode.  1280x960 happens to be right in the middle.  Some
people like 800x600.  That's why there is a preferred mode option."

'Oh gee, they didn't sell pathetic enough displays at Wal-Mart, looks
like I'll have to get this ok one and set it down to youtube
resolution.'
I'll take your word that those people exist, I've never met one.  ..I
can see that having a GUI that's not zoomable can really be a pain
with any kind of decent display, but .svg icons should do a lot to
help us out there.

My only argument now is that more people will /prefer/ 1280x1024 on
this display than won't, and because of that, it should be the default
resolution..

Sorry for getting snappy, I hear people who hold things in become mass
murderers.  I'm a quiet, friendly guy who always keeps to himself but
lends a helping hand when people need it, so I figure the risk factors
are already stacked against me.

/me shakes fist at vendors who use incomplete and/or erroneous EDID

Quick addendum:
"I would argue that based on your monitor's EDID, 1024x768@85hz would
be the preferred mode."
If I had a GPU that didn't completely suck, I would most certainly
want to use that mode for OpenGL applications.  85 FPS would be
awesome.
As it stands, Firefox gains a lot more from those extra pixels than it
does from being painted at 85 Hz.
Also, it's trivial for games to change the screen mode, they do it all
the time, I may even have tremulous set to 1024x768@85Hz.

Let's forget all this for a second and say that I want the 1280x960 resolution.
...you know, if it didn't stretch everything insanely, I probably
wouldn't have even noticed in the first placed, and also, even if I
had, probably not have cared that much.

If this bug is fixed only by making 1280x960 work properly by default,
I'll be content.

And just as a final note, all politics and technical arguments aside,
you guys rock, your work is amazing, I'm very, very grateful for all
the time you spend on these drivers and I think many other people are
too.  Don't let the minutiae get you down.

(In reply to comment #7)
> "1280x960 is a valid mode based on the sync ranges provided and it's
> actually 4:3 whereas 1280x1024 is not"
> My physical hardware is 5:4 aspect ratio, not 4:3.  If you have
> something against 5:4, please take it up with the manufacturers, not
> the end users.
Sure about that? I've never seen a CRT which has a 5:4 aspect ratio. Maybe they exist as some specialty items but certainly usual (non-widescreen) crts are all 4:3.
And I'd have to agree default mode on CRTs should be any mode which uses more than 60Hz. Maybe it doesn't bother you, but I know a lot of people (me included...) which will get killed by the annoying flicker within minutes :-).

I think I posted this on the bug in Ubuntu, not freedesktop.org, but I
measured my screen viewing area with a ruler, and it is exactly 5:4.

> I’ve never seen a CRT which has a 5:4 aspect ratio.

There were several on the market back when 1280x1024 was a top-notch resolution.

At that time, only the Mac-specific monitors in that pixel-class were
designed for 1280x960.  Everyone else went for a 5x4 1280x1024.

(I once drove one such monitor at 1168x930 — 1160x928 with a few extra
pixels horizontally because the card required a width divisible by 16
and a couple of extra lines just because I could — to get a better-than-
60 Hz refresh rate.)

Update your monitor and screen sections like so:

Section "Monitor"
        Identifier      "VGA-0"
        Option          "DPMS"
        Modeline "1280x1024_60.00"  108.88  1280 1360 1496 1712  1024 1025 1028 1060 -hsync +vsync
        Option "PreferredMode" "1280x1024_60.00"
EndSection


Section "Screen"
        Identifier      "Default Screen"
        Monitor         "VGA-0"
        Device          "Configured Video Device"
EndSection

That will select 1280x1024 @ 60hz as your default mode.

(In reply to comment #16)
> > I’ve never seen a CRT which has a 5:4 aspect ratio.
> 
> There were several on the market back when 1280x1024 was a top-notch
> resolution.
> 
> At that time, only the Mac-specific monitors in that pixel-class were
> designed for 1280x960.  Everyone else went for a 5x4 1280x1024.
Well everybody used 1280x1024, but I'm not too sure that the monitors were really 5:4. I've got a 19" CRT here for instance which clearly is 4:3, and there were lots of similar monitors around that time. And especially the cheaper ones, while they could run 1600x1200, it was unusable due to fuzziness and restriction to 60Hz, so everybody just used 1280x1024 on them. But you may be right some might indeed have been 5:4. Anyway, even if the monitor in question here really is 5:4 physically, there's nothing in the edid data which would indicate this - in fact edid just shows it's 4:3. So there's absolutely nothing the driver could do to figure out it should indeed chose a 5:4 resolution by default.

> Well everybody used 1280x1024, but I'm not too sure that the monitors were
> really 5:4. I've got a 19" CRT here for instance which clearly is 4:3, and
> there were lots of similar monitors around that time. And especially the
> cheaper ones, while they could run 1600x1200, it was unusable due to fuzziness
> and restriction to 60Hz, so everybody just used 1280x1024 on them. But you may
> be right some might indeed have been 5:4.
Yes, as I said, I measured it.

>Anyway, even if the monitor in
> question here really is 5:4 physically, there's nothing in the edid data which
> would indicate this - in fact edid just shows it's 4:3. So there's absolutely
> nothing the driver could do to figure out it should indeed chose a 5:4
> resolution by default.

Keep a database of accurate EDIDs to use for all known monitors.
I thought you guy already did something like this.  I was always under
the impression that monitor EDIDs in general have never been accurate
at all, this reaffirms that.

This is not actually a radeon issue, but an xserver issue as it picks the mode.

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.