Display manager starts after boot, but screen remains black


I have the following problem and no idea where to start looking for a solution.

After booting, when KDM should appear, the screen remains black. I do see the mouse cursor and it changes appearance in the middle of the screen where the input fields for user and password should be. Also, I can type in user/password, press Enter and login but the screen remains black.

Xorg.0.log does not show any errors or warnings so I am a bit puzzled. init 3, init 5 does not solve the problem. Neither does CTRL-ALT-F1 to a terminal and back.

I’m running openSUSE 13.1 with KDE on a workstation with two ATI/AMD FirePro W7000 GPUs using the radeon driver on a Fujitsu B24W-6 LED display.

I had a lot of trouble setting up the Xorg server. Because the system did not initially run with KMS, I had to use the nomodeset boot parameter which precludes use of the radeon driver which we would like to use (the proprietary AMD/ATI driver seems to be outdated…). The reason for this was that the display seems to supply a faulty EDID or at least one that does not fully conform to the standard.

So I extracted the EDID by nvidia-settings on a different computer, put it under /lib/firmware/edid/ and loaded it with the appropriate kernel setting. Only then did KMS work and I thought I had found a solution to everything but alas…

I noticed that when I CTRL-ALT-F1 to a terminal and back to CTRL-ALT-F7, the following is logged:

   658.687] (II) AIGLX: Resuming AIGLX clients after VT switch
   658.710] (II) RADEON(0): EDID vendor "FUS", prod id 2066
   658.710] (II) RADEON(0): Using hsync ranges from config file
   658.710] (II) RADEON(0): Using vrefresh ranges from config file
   658.710] (II) RADEON(0): Printing DDC gathered Modelines:
   658.710] (II) RADEON(0): Modeline "1920x1200"x0.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 +hsync -vsync (74.0 kHz eP)
   658.710] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
   658.710] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
   658.710] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
   658.710] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
   658.710] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
   658.710] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
   658.710] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
   658.710] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
   658.710] (II) RADEON(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
   658.710] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
   658.710] (II) RADEON(0): Modeline "1440x900"x0.0   88.75  1440 1488 1520 1600  900 903 909 926 +hsync -vsync (55.5 kHz e)
   658.710] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
   658.710] (II) RADEON(0): Modeline "1600x900"x60.0  119.00  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz e)
   658.710] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920 2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
   661.221] (II) AIGLX: Suspending AIGLX clients for VT switch

Not sure whether these modelines are properly formatted since the identifier is not fully inside the double parentheses?

Other than that, I am really in the dark what might be the problem and what I could attempt.

pastebin of my Xorg.0.log and xorg.conf.d


The phenomenon you describe has been reported a number of times with various AMD hardware (and distros). I hope a graphics guru or knowledgeable AMD user can chime in to advise further.

Your post suggests that you are reasonably experienced with Linux, so in the meantime you might want to consider trying a newer Catalyst driver perhaps


The other option that might be worth considering is to upgrade the Xorg stack from the following repo


and try using radeon driver again. That’s about all I can offer.

In relation to the DM issue, I highly suspect you’re running into a glamour related problem … the edid seems to be an unrelated secondary issue itself, which may or may not be corrected in newer drivers …

I would remove your edid boot line option, and then attempt the following:

  • update to the kernel 3.13… http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/ … this will get you a new radeon drm/kms kernel driver
  • update the entire xorg/mesa stack as deano already alluded to … this will get you a new radeon xorg driver, a new glamour lib, a new radeonsi 3d driver, new xorg server and components…
  • then boot utilizing KMS

How many monitors are you driving? and are you using both adapters to drive them … details, details, details

Thanks for the answers deano_ferrari and Tyler_K!

We are driving a single monitor from one of the GPUs (they have four DisplayPort connectors) - I tried unsuccessfully to ascertain the BusId of the GPU we are using… dmidecode/lspci… however the manufacturer of the workstation, Fujitsu, supplies very little information. I opened the case but the relevant regions of the mainboard are obstructed by fans and if possible I will not mess around in there as this would probably void the guarantee we have with our supplier.

The Catalyst driver deano_ferrari suggests is not the proper one for our hardware - there is a different AMD FirePro and FireMW Unified Driver (called Catalyst Pro?). The beta of this driver is, according to the website, older than the release version… I tried that and it totally messed up the system.

Both of you suggest updating the Kernel/Xorg/radeon. I have little experience in adding new repositories and upgrading parts of my system, always relying on the installed repositories. I fear ending up in some “repository hell”… but I will try it if no other solution comes up!

I unsuccessfully tried a couple of things but what finally did the trick was deactivating Glamor (by commenting out the Load “glamoregl” line in the Module section of xorg.conf). Thanks again Tyler_K for suggesting this as the root of the problem.

I will attempt to update the Xorg stack and reactivate it to see if the problem has been resolved in a newer version. Also I will check out EXA and and XAA as AccelMethod.

Your graphics adapters use a gpu that is based upon AMD’s southern Islands architecture. SI (and newer) based adapters use glamor to provide 2D acceleration … in this case (i.e. SI and > based adapters), glamor is also necessary for other things such as UVD accel, as well as 3D accel to work. There is no EXA support for your devices. XAA is ancient and no longer supported in X.

The glamor related problem you’ve encountered, is a corner case issue – it happens only with respect to when two or more active adapters are using glamor. I do not know if it has been resolved yet (but that was why I suggested the updating). However, you’re only using one of these (expensive and 4 output capable!) adapters to driver a single monitor !!! (!!! this is ridiculous overkill !!! ). Just disable the unused adapter in the systems bios/efi, and you will resolve the issue … then fire the person who authorized the purchase for such an usage scenario.

The workstation is almost exclusively intended for multi-user remote login involving visualization of large sets of scientific data and CAD modeling - the single monitor is mainly there to have one more desktop computer to work on :slight_smile:

To conclude this thread, as I was not able to make both GPUs run with radeon/glamor, even using the most recent available versions, I will wait for a new proprietary driver from AMD/ATI (since the one available on their website (even the beta one) is too outdated for openSUSE 13.1.