[hardy] Blank GDM screen with ATI R420 [X800XT PE]

Bug #177658 reported by Cesare Tirabassi
6
Affects Status Importance Assigned to Milestone
xserver-xorg-driver-ati
Fix Released
Low
xserver-xorg-video-ati (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-ati

xserver-xorg-video-ati v1:6.7.196-2

Screen is blank but GDM is running and login can be made. After login screen is visualised correctly.
There is no problem with the vesa driver.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please attach your X server configuration file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.0.log) to the bug report as individual uncompressed file attachments using the "Attachment:" box below. Could you please also try to run without any /etc/X11/xorg.conf and let Xorg autodetect your display and video card? Please also attach the /var/log/Xorg.0.log from this attempt. Thanks in advance.

Changed in xserver-xorg-video-ati:
assignee: nobody → tormodvolden
status: New → Incomplete
Revision history for this message
Cesare Tirabassi (norsetto) wrote :
Revision history for this message
Cesare Tirabassi (norsetto) wrote :
Revision history for this message
Cesare Tirabassi (norsetto) wrote :
Changed in xserver-xorg-video-ati:
status: Incomplete → New
Revision history for this message
Tormod Volden (tormodvolden) wrote :

Thanks. First, can you please install the newest test driver from https://wiki.ubuntu.com/XorgOnTheEdge to see if it helps?

Can you switch to a console while the screen is black? Please run:
 xrandr -q -d :0 > xrandr.txt
and attach the file xrandr.txt. Please also make a copy of Xorg.0.log at this point, and then again after logging in, so I can easier see what in the log corresponds to which state.

Changed in xserver-xorg-video-ati:
status: New → Incomplete
Revision history for this message
Cesare Tirabassi (norsetto) wrote :

No change with newest driver (6.7.197+git20071227.bfa22d-0ubuntu0tormod1).
xrandr -q -d :0 (or any variations of it) all fail with "no display found"
Attached Xorg.0.log shows:

AUDIT: Fri Jan 4 00:27:16 2008: 7399 X: client 4 rejected from local host (uid 1000)

when gdm screen is suspended.
Hope this sheds some light.

Changed in xserver-xorg-video-ati:
status: Incomplete → New
Revision history for this message
Tormod Volden (tormodvolden) wrote :

Sorry, I forgot about the access control (I tried it out myself when I was logged in already). Can you please try with sudo or even sudo -i ?

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Can you try the test version for Gutsy, which is newer? There were some possibly relevant changes recently. Do you have TV out on your card? What kind of screen(s) is connected?

Otherwise it would be nice if you could file a bug on bugs.freedesktop.org once you get that xrandr output.

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

Created an attachment (id=13688)
Xorg.0.log file

Hi there,

This bug has been reported to Ubuntu (see link above).
Post boot, the gdm screen is blank but gdm is running and login can be blindly made. After login, the screen resumes normally.
Attempts to run xrandr during login by alternate login to a console fails with the message "no display found!".
In the attached log file, this can be seen by the AUDIT: line (line 1116), so, if any releveant log message can help they should be locate in that area of the log file (where the VT switch is also logged)

Let me know if I can help in any way.

Driver version is 6.7.197.

Revision history for this message
In , agd5f (agd5f) wrote :

(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.

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

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).

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

Created an attachment (id=13707)
xorg.conf

Revision history for this message
In , agd5f (agd5f) wrote :

(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

Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

>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.

Revision history for this message
In , agd5f (agd5f) wrote :

(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.

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

(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?

Revision history for this message
In , Loïc Minier (lool) wrote :

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?

Revision history for this message
In , agd5f (agd5f) wrote :

(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?

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

> 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.

Revision history for this message
In , agd5f (agd5f) wrote :

(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"

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

>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.

Revision history for this message
In , Cesare Tirabassi (norsetto) wrote :

Created an attachment (id=13730)
This is the Xorg.0.log using startx

Revision history for this message
In , agd5f (agd5f) wrote :

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.

Changed in xserver-xorg-video-ati:
assignee: tormodvolden → nobody
status: New → Confirmed
Revision history for this message
Adrian Moisey (adrianmoisey) wrote :

I also seem to be getting this

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

Adrian, please don't add confirmation to bugs without also including some evidence or other information to that effect. Please include your Xorg.0.log.

Revision history for this message
Brian Murray (brian-murray) wrote : Ubuntu needs you!

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

Changed in xserver-xorg-video-ati:
status: Confirmed → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

It's ambiguous from the upstream bug if this was fixed - would you mind re-testing against intrepid and see if the issue still exists? Based on Alex's description of the problem it may be possible to quirk it.

Changed in xserver-xorg-video-ati:
importance: Undecided → High
status: Incomplete → Triaged
Revision history for this message
Cesare Tirabassi (norsetto) wrote :

I'm currently unable to boot into intrepid. As soon as this boot problem is resolved I can certainly check this out. Please leave the bug open for the time being.

Revision history for this message
Cesare Tirabassi (norsetto) wrote :

Setting this as fixed, its working fine now in intrepid.

Changed in xserver-xorg-video-ati:
status: Triaged → Fix Released
Revision history for this message
Zachary Sandberg (zachary-sandberg) wrote :

Unfortunately, I am having the same identical problem as originally described in Intrepid 64-Bit. It is intermittent (maybe 1 out of 3 boots) The Machine has an AMD 690G integrated chipset, and experiences the blank GDM problem with both the generic ATI and proprietary ATI drivers.

Revision history for this message
In , agd5f (agd5f) wrote :

this should be fixed in xserver 1.5 and newer.

Changed in xserver-xorg-driver-ati:
status: Confirmed → Fix Released
Revision history for this message
Tormod Volden (tormodvolden) wrote :

Zachary, this bug is fixed and closed. Please file a new bug for your issue.

Changed in xserver-xorg-driver-ati:
importance: Unknown → Low
Changed in xserver-xorg-driver-ati:
importance: Low → Unknown
Changed in xserver-xorg-driver-ati:
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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