ATI card and compositing support?
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? |
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? |
Quote:
Quote:
http://deesto.pastebin.com/GGdGjrjX Xorg log is also a mess: http://deesto.pastebin.com/xRjH0efk Quote:
Code:
/usr/bin/X -nr -nolisten tcp :0 vt7 -auth /var/run/kdm/A:0-y5wXmw Code:
# Xorg configuration created by livna-config-display |
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. |
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 |
Quote:
|
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.
|
Quote:
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 Code:
# (1) Arch Linux 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. |
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) |
Quote:
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! |
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 [1] http://support.amd.com/us/gpudownloa...2&lang=English [2] http://deesto.pastebin.com/K74jpbBM |
Quote:
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. |
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 |
Quote:
Code:
07:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series] |
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 |
All times are GMT -5. The time now is 03:37 PM. |