ATI card and compositing support?

deesto · 02-23-2010, 06:35 PM

Just got a VisionTek ATI Radeon HD2600Pro, which my Fedora 12 64-bit system seems to have no problem recognizing natively (though it is peculiar that it shows up in lspci as an a 'HD3600' instead of 2600), so things seemed fine ... til I tried to start X. To be thorough: I went from an nVidia Quadro NVS 285 in the system using drivers from rpmfusion, to this card in hopes of getting better graphics and compositing support. So I tried uninstalling the nVidia drivers and kmods, blacklisting radeon and radeonhd mods, installing the stock ATI driver straight from the ATI/AMD site (which included header compilation), and starting X ... no go. Then removed that, installed the OpenDrivers stuff ... still no good. Ended up removing all Xorg configuration (literally removing xorg.conf) and starting X with bare bones. And now X will indeed start up and go into my desktop environment (KDE), but as soon as I open more than a single application window, the system becomes virtually unusable, and compositing is completely out of the question.

Any advice for drivers/config/setup to get this working? Or do I need to go back to my crappy 128MB NVS card?

Alex_Dc · 02-23-2010, 09:09 PM

Please post /var/log/Xorg.0.log, dmesg, and lspci.

Are you using KMS and/or HAL to start the Xserver, or are you using FB and/Xorg.conf?

deesto · 02-24-2010, 07:51 AM

Quote:

Originally Posted by Alex_Dc

Please post /var/log/Xorg.0.log, dmesg, and lspci.

Quote:

# lspci
00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller Hub (rev 12)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 (rev 12)
00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 12)
00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7 (rev 12)
00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 12)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 6 (rev 12)
00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 12)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 12)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 12)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 12)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 12)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 12)
00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio Controller (rev 09)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.2 RAID bus controller: Intel Corporation 631xESB/632xESB SATA RAID Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01)
07:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3600 Series
07:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series]
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)

dmesg has become a bit messy ... output here:
http://deesto.pastebin.com/GGdGjrjX
Xorg log is also a mess:
http://deesto.pastebin.com/xRjH0efk

Quote:

Are you using KMS and/or HAL to start the Xserver, or are you using FB and/Xorg.conf?

X is currently running as:

Code:

/usr/bin/X -nr -nolisten tcp :0 vt7 -auth /var/run/kdm/A:0-y5wXmw

Nothing in xorg.conf ... it didn't exist. After running the livna config tool, xorg.conf appears as below, but livna complains that fglrx and/or nvidia drivers are not found ... but it writes this anyway:

Code:

# Xorg configuration created by livna-config-display

Section "Files"
        ModulePath   "/usr/lib64/xorg/modules"
EndSection

Section "ServerFlags"
        Option      "AIGLX" "off"
EndSection

Section "Extensions"
        Option "Composite" "Disable"
EndSection

Alex_Dc · 02-25-2010, 09:25 AM

Ok, you are using KMS and HAL to set the X server at this point. Radeon + KMS is known to be buggy right now, so go ahead and disable it and see if that helps. You might have to consult the Fedora wiki on just how to do this, as there may be multiple configuration files that are telling your system to use KMS, but it also might be as simple as adding "radeon.modeset=0" or "nomodeset" to your boot parameters (if you don't know what I'm talking about post the output of "cat /boot/grub/menu.lst" and I'll show you exaclty where to append the line).

Alternatively, you Xorg and dmesg outputs don't look wrong, but do look unusal. It appears X is try to configure multiple displays on start, are you using multiple displays? If not, when the system boots (and I know this might be hard as it crashes constantly) try and run xrandr, and post the output of that. Also, go ahead and post the ouput of "cat /proc/mtrr" for good measure, but I am doubting there is anything wrong with you mtrr at this point.

deesto · 02-25-2010, 08:12 PM

Hi Alex,

I know how to modify the grub boot menu (grub.conf in my case); no worries there. I'll give that a try. As far as the log output: yes, I am running multiple displays, one next to the other in "twinview" mode, and this function seems to be working fine, even without a twinview definition in xorg.conf. But the system isn't crashing per se; it's booting fine and even loads X without apparent trouble. It just goes under heavy load when trying to do anything useful within an X session.

In searching around, I came across a FAQ guide [1] that mentions a 'fglrx' package for Fedora, but this package appears to have gone AWOL in the case of Fedora 12 64-bit repos. I was told by the maintainer of this FAQ that this package does not currently work in Fedora and hasn't for some time.

[1] http://www.fedorafaq.org/#radeon

Alex_Dc · 02-25-2010, 09:11 PM

Quote:

Originally Posted by deesto

Hi Alex,

I know how to modify the grub boot menu (grub.conf in my case); no worries there. I'll give that a try. As far as the log output: yes, I am running multiple displays, one next to the other in "twinview" mode, and this function seems to be working fine, even without a twinview definition in xorg.conf. But the system isn't crashing per se; it's booting fine and even loads X without apparent trouble. It just goes under heavy load when trying to do anything useful within an X session.

In searching around, I came across a FAQ guide [1] that mentions a 'fglrx' package for Fedora, but this package appears to have gone AWOL in the case of Fedora 12 64-bit repos. I was told by the maintainer of this FAQ that this package does not currently work in Fedora and hasn't for some time.

[1] http://www.fedorafaq.org/#radeon

Gotcha. Nothing personal about the grub part, I just like to be thorough in my explainations. Also, I don't know if you've tried booting without the second display attached, but there is a whole other set of issues with multiple displays and KMS, and that might be part of your problem. In your case, it may be best to scrap the whole of KMS at this point and just go back to the old framebuffer, at least until some of these issues are sorted out. Anyway, keep me updated.

deesto · 02-26-2010, 08:06 PM

Hmm ... so you think booting with just one display attached might help things? I've been booting with both so far. What do you mean by the old framebuffer? Since it seems that the drivers that used to work for Fedora (fglrx) are no longer available, I'm willing to try most anything.

Alex_Dc · 02-26-2010, 08:47 PM

Quote:

Originally Posted by deesto

Hmm ... so you think booting with just one display attached might help things? I've been booting with both so far. What do you mean by the old framebuffer? Since it seems that the drivers that used to work for Fedora (fglrx) are no longer available, I'm willing to try most anything.

Refer to my previous post about KMS for suggestions, but I'll outline some more technical details here (very briefly, and a bit sloppily; if you have specific questions I'll be glad to answer them).

Basically, what the problem most likely is is that KMS, Kernel Mode Setting, is not yet fully supported by ATI graphics cards. What KMS does, exactly, is it tells the kernel how to interact with your graphics card and directly set the resolution of you display. In the past this was handled by a number of different programs that were executed in "user-space" (as opposed to "kernel-space"), namely the X server and the "framebuffer".

Now what does that all mean? Basically, with KMS, on boot the kernel is able to interact with your graphics card, detect the native resolution of you monitor, and set the resolution of your monitor. What you, as the user notice when this happens is that when you switch to a console (tty), it is displayed in you native resolution.

In the past, in order to accomplish this same effect, you had to rely on a "framebuffer". What this means, is that you set a line a grub that said something to the effect of "vga=773", and that would send a message that your monitor was WxH pixels, and so your console had to be set to the same. A framebuffer would handle the setting of the resolution of your console, while whenever you switch to X, the X server would handle the setting of the resolution in X.

So when I tell you to go back to the old framebuffer method, what I basically want you to do is go ahead an follow my previous instructions and append the line "nomodeset" or "radeon.modeset=0", and also a line that reads "vga=N", where N is a number that is associated with your native screen resolution. Refer to this table for more information:

Code:

#  FRAMEBUFFER RESOLUTION SETTINGS
#     +-------------------------------------------------+
#          | 640x480    800x600    1024x768   1280x1024
#      ----+--------------------------------------------
#      256 | 0x301=769  0x303=771  0x305=773   0x307=775
#      32K | 0x310=784  0x313=787  0x316=790   0x319=793
#      64K | 0x311=785  0x314=788  0x317=791   0x31A=794
#      16M | 0x312=786  0x315=789  0x318=792   0x31B=795
#     +-------------------------------------------------+

In all, I basically want your menu.lst (or grub.conf, or whatever it is on your machine), to look something like this is you have a 1024x768x32 display:

Code:

# (1) Arch Linux
title  Arch Testing
root   (hd0,4)
kernel /2.6.33-test root=/dev/sda8 ro nomodeset(or "radeon.modeset=0") vga=790
initrd /kernel26-test.img

This should disable KMS on boot, and should solve your problems. However, you need to be aware of two issues: one, you may have to manually set the resolution of your second display as well, and two, if you have a non-standard resolution, it may not be supported. There are some other things you need to know, but if you test this and it solves your immeadiate problems, we'll talk about those.

Now, on another note, I mentioned your second display because (again) KMS has some issues with trying to set a primary screen resolution to the resolution of a (sometimes nonexistant) external display. However, when this happens the problems that arise usually do not manifest in the way you described, so I am skeptical that this is the problem.

Edit: Also, be aware as you are going about this operation that

1) there may be multiple system files that enable KMS, and KMS+framebuffer don't always play nice. So, first try appending the line "nomodeset" (or "radeon.modeset=0"), booting, then switching to a console to see if KMS was disabled. If it was, the text on the console should be rather large and grainy. If KMS is successfully diabled, only then should you add the "vga=N" part.

2) Not all arguments work equally for some reason I don't understand. If the argument "nomodeset" doesn't work, go ahead and try "radeon.modeset=0", and see if this works.

3) When appending the line "vga=N" if you only know that you monitor resolution is, for example, 1024x768, but don't know the depth (i.e. whether it is a 1024x768x32 or 1024x768x256) just go ahead and pick one and reboot. If you picked the worng one all that will happen is that you will get an error message on boot, will have to select an option from a list, and then you can go right back into grub and try another vga option.

4) If your resolution is non-standard, just pick the closest resolution and go with that.

deesto · 03-01-2010, 01:38 PM

Thanks a lot Alex. So I added 'radeon.modeset=0 vga=346' to my kernel line in grub.conf (I have dual widescreen 1680x1050 monitors, and I found a code '369' that was supposed to work at this resolution but didn't for me), and I see no error or warning lines in the X log. There are a bunch of info lines listing all possible modes, including:

Code:

(II) RADEON(0): Modeline "1680x1050"x59.9  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz)

On boot, my screens got swapped (not a big deal, and easy to fix once things are settings), and compositing is disabled as expected, but things seem otherwise fine to this point.

Alex_Dc · 03-02-2010, 12:14 AM

Quote:

Originally Posted by deesto

Thanks a lot Alex. So I added 'radeon.modeset=0 vga=346' to my kernel line in grub.conf (I have dual widescreen 1680x1050 monitors, and I found a code '369' that was supposed to work at this resolution but didn't for me), and I see no error or warning lines in the X log. There are a bunch of info lines listing all possible modes, including:

Code:

(II) RADEON(0): Modeline "1680x1050"x59.9  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz)

On boot, my screens got swapped (not a big deal, and easy to fix once things are settings), and compositing is disabled as expected, but things seem otherwise fine to this point.

Compositing is disabled? Whether you are using KMS or a framebuffer shouldn't affect your compositing. Are you using the proprietary or open source drivers right now? If you want the compositing and 3D, then go ahead and install the proprietary drivers, they should work just as well as the open source now that you have your boot options configured correctly.

Now, we're not quite done yet, there are a few things that you need to be aware of. First, does "346" correspond to the actually resolution of your monitors, or just something close? Unless you do a lot of work directly on the console, it isn't really a big deal in itself to have completely correct frambuffer resolution, we just want a framebuffer on the console that's at least pretty close to the native resolution of the monitor. However, be aware that if you have an incorrect framebuffer resolution that in some unusual cases it will lead to the X server being set in an improper resolution. If you find this happening to you, go ahead and follow the Fedora wiki/guide instructions for creating and configuring an Xorg.conf file. Mostly, the settings should be correct, you will just need to ensure that the screen resolution is properly set.

Second, you may notice when switching between a console and the X server that you will now see a "flicker". This is perfectly normal and unavoidable, albeit, undesirable behavior. This "flicker" occurs because you now have the X server setting video output for X and the kernel setting the video output for your console. Before, with KMS, the kernel would set the video output of each. As such, now your machine must hand over control of you video output from the X server to the kernel when switching to a console, and vice versa when switching back to the X server. There is nothing you can do about this.

Finally, there are some security issues with the old framebuffer method. This, combined with the other issue posted above, is mainly why it is being phased out. If security is a concern for you (and we're talking some esoteric exploits here, so when I say a "concern" I mean a real concern) then you'll need to look into additional ways to secure your machine. However, even if security isn't a huge concern, you must be aware of the security issues as users on your machine may need additional privileges in order to properly run some aspects of X. In particular I had an issue with Xscreensaver that left me pounding my head against the wall for a couple of weeks. I never really figured out the root of the problem, I just uninstalled Xscreensaver as I never really used it anyway. All in all, on this issue, you may find that you have no problems what-so-ever. However, I just wish to forewarn you in case you start encountering some unexplainable errors.

If you have any other questions feel free to ask. Otherwise, good luck!

deesto · 03-02-2010, 08:07 AM

Thanks Alex. My screens' native resolution is 1680x1050, so 1400x1050 is close, and as you said, that's just for the console, so not a big deal.

A big deal occurred, however, when I went ahead and installed the latest version of the proprietary drivers for the Radeon HD 2600 line from the ATI/AMD site [1]. The install went fine, as did the 'aticonfig --initial' command to modify the X config, but a reboot resulted in no more X; from the log:

Code:

dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: UpdateSpriteForScreen
(EE) Failed to load/usr/lib64/xorg/modules/drivers/fglrx_drv.so
(EE) Failed to load module "fglrx" (loader failed, 7)
(EE) No drivers available.
Fatal server error:
no screens found

The file does exist (as an ELF binary). If I delete my xorg.conf, I can get into a plain X session without issue. But if I try System Settings -> Desktop, the control app crashes with what appears to be a driver problem [2].

[1] http://support.amd.com/us/gpudownloa...2&lang=English
[2] http://deesto.pastebin.com/K74jpbBM

Alex_Dc · 03-02-2010, 05:49 PM

Quote:

Originally Posted by deesto

Thanks Alex. My screens' native resolution is 1680x1050, so 1400x1050 is close, and as you said, that's just for the console, so not a big deal.

A big deal occurred, however, when I went ahead and installed the latest version of the proprietary drivers for the Radeon HD 2600 line from the ATI/AMD site [1]. The install went fine, as did the 'aticonfig --initial' command to modify the X config, but a reboot resulted in no more X; from the log:

Code:

dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: UpdateSpriteForScreen
(EE) Failed to load/usr/lib64/xorg/modules/drivers/fglrx_drv.so
(EE) Failed to load module "fglrx" (loader failed, 7)
(EE) No drivers available.
Fatal server error:
no screens found

The file does exist (as an ELF binary). If I delete my xorg.conf, I can get into a plain X session without issue. But if I try System Settings -> Desktop, the control app crashes with what appears to be a driver problem [2].

[1] http://support.amd.com/us/gpudownloa...2&lang=English
[2] http://deesto.pastebin.com/K74jpbBM

Ouch. I'm pretty sure you're right about this being a driver issue. Unfortunately, I can't help you if this is the case, you'll just have to file a bug report with ATI and have them take care of it.

Just for good measure, try running X with Xorg.conf again, but this time ensure the SUID bit is set on the binary before you do so. This might simply be one of those weird permissions issues I mentioned.

Also, I googled a bit and there appears to be some problems running the proprietary ATI drivers without Xorg.conf at this point. Again, this is something relatively new so the bugs haven't totally been ironed out yet.

Let me know how it goes.

adamk75 · 03-02-2010, 06:49 PM

fglrx will absolutely not work on Fedora 12 since the driver doesn't yet support Xorg xserver 1.7.* Hopefully this month or next months release will support it.

Maybe I missed it somewhere in this thread already, but what happens when you install the mesa-drivers-experimental package and try to use the open source drivers?

Adam

deesto · 03-03-2010, 07:44 AM

Quote:

Originally Posted by adamk75

Maybe I missed it somewhere in this thread already, but what happens when you install the mesa-drivers-experimental package and try to use the open source drivers?

That's actually the first thing I tried, but I tried it again, just for fun. So after uninstalling the proprietary ATI driver, uninstalling the mesa-dri-drivers and mesa-dri-drivers-experimental packages, removing radeon.modeset=0 vga=346' from my grub kernel entry, and re-installing these two packages again, I am back to where I was in the beginning: no errors reported during boot, but no graphical desktop session. The boot process stops reporting after "Starting crond: [OK], Starting atd: [OK]". It just stops there. I can get into another console session and check the Xorg log (no errors) and system messages (no errors), and I can even start an X session, but that just produces a black screen, and again no X errors. 'lspci' shows the same VGA entry as before:

Code:

07:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series]

adamk75 · 03-03-2010, 07:48 AM

Odd... So the screen goes black, but the machine is still responsive? Could you grab the /var/log/Xorg.0.log file and pastebin it? Have you checked to see if there are any updates to the radeon driver in F12? Or perhaps even tried a newer version from rawhide?

Adam