Bug 14050

(II) RADEON(0): Output VGA-0 using monitor section Generic Monitor
...
(II) RADEON(0): Output VGA-0 using initial mode 1600x1024

Looks like it's trying to use 1600x1024 on startup for some reason.  Can you attach your xorg config?  perhaps you have a strange mode or sync range set in your monitor section?  Does startx (as opposed to gdm) work ok?  gnome/gdm sometimes saves previously set user modes.

Hi Alex,

thanks for stepping on this.
I'm attaching my xorg.conf, but its a pretty standard one and I have been using it  since 1 year without a problem.
Removing it and using autodetection is the same.
Note as well that neither the vesa driver nor the fglrx one have this problem, also the previous driver was ok (6.6.3).
Starting with startx is obvioulsy ok as it bypasses gdm (as I said, the problem is only with gdm).

Created attachment 13707 [details]
xorg.conf

(In reply to comment #2)
> Note as well that neither the vesa driver nor the fglrx one have this problem,
> also the previous driver was ok (6.6.3).
> Starting with startx is obvioulsy ok as it bypasses gdm (as I said, the problem
> is only with gdm).
> 

hmmm, if startx works ok, I think this may be an issue with gdm rather than the radeon driver.  Does it help if you remove these two lines from your config:

	HorizSync	30-92
	VertRefresh	50-160

>Does it help if you remove these two lines from your config:
>
>       HorizSync       30-92
>       VertRefresh     50-160

As I said, even removing the whole xorg.conf doesn't help (note that I'm not getting an out-of-sync message).

>an issue with gdm rather than the radeon driver

I doubt it, since, as I said, everything is ok with vesa, fgrlx and the old driver.

(In reply to comment #5)
> >an issue with gdm rather than the radeon driver
> 
> I doubt it, since, as I said, everything is ok with vesa, fgrlx and the old
> driver.
> 

neither vesa, nor fglrx, nor the old radeon driver are randr 1.2 capable drivers.  I think gdm is doing the wrong thing in this case.

(In reply to comment #6)
> I think gdm is doing the wrong thing in this case.

I didn't think gdm actively influenced the video mode at all though. It certainly doesn't seem to here. It's possible Ubuntu have modified gdm or its configuration to change this though, Cesare can you clarify this downstream?

Hi,

You say startx works, but does it work when gdm is still running?  Or do you run stop gdm, then run startx?

Can you attach your gdm configuration files?

Older GNOME releases do some modesetting when launching the gnome-settings-daemon based on the value of GConf keys; if you:
gconftool-2 --recursive-unset /desktop/gnome/screen/default/0
gconftool-2 --recursive-unset /desktop/gnome/screen/default
gconftool-2 --recursive-unset /desktop/gnome/screen

and run a recent GNOME, it will simply rely on Xorg and not touch the settings.

I suppose this explains why blind login helps; after the unsets, your screen wont be restored after a blind login.

This doesn't explain what gdm does differently, but perhaps it's simply that you run startx when gdm is still running on another VT?

(In reply to comment #7)
> (In reply to comment #6)
> > I think gdm is doing the wrong thing in this case.
> 
> I didn't think gdm actively influenced the video mode at all though. It
> certainly doesn't seem to here. It's possible Ubuntu have modified gdm or its
> configuration to change this though, Cesare can you clarify this downstream?
> 

I didn't think so either, but I can't explain why that weird mode gets picked only when gdm is active and not when you just run startx.  Plus I've seen cases where gnome-session saves old modes which have caused problems when users switch monitors and what-not.

Cesare, can you attach a log from startx as opposed to gdm?

> It's possible Ubuntu have modified gdm or its configuration to change
> this though, Cesare can you clarify this downstream?

In between Debian and us we have a quite large number of mods. I scanned them briefly and I see some are related to display configuration, loic (nice to see you here too :-)) would certainly know.

> This doesn't explain what gdm does differently, but perhaps it's simply
> that you run startx when gdm is still running on another VT?

That's right. I also wanted to check what happens by stopping gdm and then running startx but ....

>gconftool-2 --recursive-unset /desktop/gnome/screen/default/0
>gconftool-2 --recursive-unset /desktop/gnome/screen/default
>gconftool-2 --recursive-unset /desktop/gnome/screen

deleting this key (too bad i didn't back-it up before) now also leads to Gnome with a blank screen. If anyone has any idea on how I could restore it I could continue with some more testing.

(In reply to comment #10)
> deleting this key (too bad i didn't back-it up before) now also leads to Gnome
> with a blank screen. If anyone has any idea on how I could restore it I could
> continue with some more testing.
> 

Does deleting that key also break startx?

you can specify a preferred mode in your monitor section:

Option "PreferredMode"  "1280x1024"

>Does deleting that key also break startx?

Yes.

>you can specify a preferred mode in your monitor section

Adding Option "PreferredMode"  "1280x1024" in xorg.conf makes everything work as it should: startx, gdm and Gnome.

Created attachment 13730 [details]
This is the Xorg.0.log using startx

Very strange.  I think since the edid does not specify a preferred mode the xserver is picking some strange mode that it thinks is optimal within the bounds of h/v sync ranges.  We should probably add some logic to the xserver to default to the first detailed timing block if no preferred mode is specified or perhaps a quirk for this monitor.  The edid claims to be 1.2 but it is not conformant.  

this should be fixed in xserver 1.5 and newer.