Bug 21853

Summary:	Xorg starts up with blank screen, mouse cursor works
Product:	xorg	Reporter:	Coleman Kane <ckane>
Component:	Driver/Radeon	Assignee:	xf86-video-ati maintainers <xorg-driver-ati>
Status:	RESOLVED FIXED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	major
Priority:	medium	CC:	matthieu.herrb
Version:	git
Hardware:	x86-64 (AMD64)
OS:	FreeBSD
Whiteboard:
i915 platform:		i915 features:

Description Coleman Kane 2009-05-21 08:05:45 UTC

This morning I synced to the git master of the following: mesa/drm, mesa/mesa, pixman, xorg/libs/libXt, xorg/libs/libXpm, xorg/xserver, xorg/driver/xf86-video-intel, xorg/driver/xf86-input-synaptics, xorg/driver/xf86-input-keyboard

I am using GNOME 2.26.1 on FreeBSD 8-CURRENT, synced as of last night.

I have an ATI/AMD RS690 GPU running at 1680x1050

Now when I start up with 'startx', I am presented with a black screen. I do get the cursor, and it properly loads the GNOME red-glass cursor that I have chosen in my theme. Running 'startx' from an ssh session into this machine, I can see all of the GNOME applications starting up and their run-time message mess spit to the console.

If I log into another SSH session, I tried "xrandr --output LVDS --mode 1400x1050". Still got the blank screen, but the resolution was noticeably changed.

I then decided to run "xrandr --output LVDS --mode 1680x1050" to reset the screen back to native resolution and viola, the desktop was displayed properly!

So.... anyone have any idea what could possibly be going on here, or even which component is the most likely culprit?

I think that this change occurred sometime since Monday (the last time I successfully synced to git masters on the packages).

Comment 1 Coleman Kane 2009-05-21 16:04:36 UTC

The same behavior is not witnessed with the xf86-video-radeonhd driver, it only happens on the ati driver, so that narrows it down a bit.

I am changing "component" to be Driver/Radeon to reflect this.

Comment 2 Michel Dänzer 2009-05-22 02:17:20 UTC

Please attach the full Xorg.0.log and xorg.conf files.

It would also be great if you could try to isolate the change or at least the component (most likely xf86-video-ati or xserver, maybe mesa if you're using compiz) which introduced the problem.

Comment 3 Matthieu Herrb 2009-05-24 08:55:04 UTC

I saw the same thing on OpenBSD/amd64. I don't know if the common denominator is *BSD, or amd64.... 

Anyways reverting xserver/79138eec1b49cbaca6a16f2bdd8579b5828aeb28  fixes the problem for me.

Comment 4 Michel Dänzer 2009-06-04 02:53:45 UTC

(In reply to comment #3)
> Anyways reverting xserver/79138eec1b49cbaca6a16f2bdd8579b5828aeb28  fixes the
> problem for me.

That commit has been reverted in xserver Git.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.