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?

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

X is currently running as:
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:

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

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.

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:

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:

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.

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:
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!

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

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

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:

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

Yep; I'm logged into it now. Sure:
http://deesto.pastebin.com/GiZWqQRk
No errors that I can see; the only warnings are:
There doesn't seem to be anything newer in the repos, and I have a feeling the radeon driver is already somewhat experimental, as it includes 'git' in its version:
#yum list installed *radeon*

You're currently using the 'radeonhd' driver, not the 'radeon' driver. While radeonhd should, theoretically, work, it doesn't see as much development or testing as the radeon driver. If you didn't have an xorg.conf file in your home directory specifying radeonhd, Xorg should, in fact, default to the radeon driver.

Adam

Unfortunately, that's because there is no non-hd driver available, according to yum: 'yum list *radeon*' returns the same two packages as 'yum installed *radeon*'. Maybe I'm missing an additional repo?
I get the same results if I delete xorg.conf and reboot, which is in fact what I've just done, same exact results. :(

Does /usr/lib64/xorg/modules/drivers/radeon_drv.so exist? It should, because that's the default driver F12 uses for all radeon GPUs. I don't know what that's packaged as, but it should definitely exist. Try specifying the radeon driver and then pastebin the log file if it doesn't work.

adamk75: yes; both radeon_drv.so and radeonhd_drv.so are there. 'sudo X -configure' gave me a fairly sizable conf file to work with, and it did include a "radeonhd" driver entry. I changed this to "radeon" and rebooted, and I can't tell why, but the Xorg logs still show the "radeonhd" module being loaded in addition to "radeon", same results.

Really, please pastebin the log file :-)

Adam

This is another attempt, even after uninstalling the radeonhd driver via yum ... go figure!
http://deesto.pastebin.com/QZgExVyU

Well the radeonhd driver is clearly still on your filesystem. If you actually removed it via yum, then there is something wrong with your fedora installation, which you need to resolve before trying to get compositing working. Unfortunately, I really don't have any idea what 'something' is at the moment.

Adam

The 'hd' driver was eventually removed after a few restarts. It's definitely gone now and no reference to it in the conf.

Now Xorg isn't looking for that, but still not working:
http://deesto.pastebin.com/tKazhr60

Now some new errors there: including some looking for a module called 'fgl.renamed.libglx'. Oddly enough, 'FGL.renamed.libglx.so' does exist in modules/extensions; why the 'FGL' is lower-case in the log, I'm not sure, especially, since it's referenced as 'FGL' in xorg.conf.

That's still the old Xorg log file. Also, if you have fgl* files on your system, you apparently still have the remnants of the fglrx driver installed all your system.

Sorry ... please refresh the page; I edited my post with the right log file (I think; too much pastebin going on here): http://deesto.pastebin.com/tKazhr60

OK, we're getting closer, but clearly there is still something not quite working here... First, Xorg is using /root/xorg.conf.new. Did you tell it to do that?

Second:

You still have the FireGL drivers installed, at least partially. They need to be *completely* removed in order for Xorg to work with the open source drivers.

Adam

Thanks ... let me clear up a few things:
- the fglrx stuff was left behind by the proprietary driver. I did a re-install and un-install to clean up the cruft, which seemed to work.
- that xorg.conf.new was the default name for the file generated by 'X -configure'. I have rebooted and rerun this using the usual file name.
- after all that, still the same %$#^& result: http://deesto.pastebin.com/NS33bWrg

The odd thing is that the driver clearly sees both monitors connected to DVI ports.

Wait... Are you actually running 'startx' or just 'Xorg' (or 'X')?

Adam

I wasn't manually running anything ... just booting into init 5, and then when it hung, I was running 'X' in a separate TTY to test. If I run 'startx' from there, I do get a graphic environment, but barely: just a bare desktop, no menu, no launchers. The only thing new I see in the Xorg log after doing 'startx' is '(II) AIGLX: Suspending AIGLX clients for VT switch".

No offensive, but we're backtracking here. The problem is that ATI doesn't fully support KMS. We've already determined that. Deesto, until KMS is fully supported by ATI, you have to have the radeon.modeset=0 line if you want any video support at all.

As to the other problem, if the issue is what adamk said in his first post than, unfortunately, it confirms my previous statement: it is a driver issue. There is nothing you can do about it. File a bug report with ATI, describe the issue, try whatever they might suggest trying, but unfortunately, you'll probably just have to wait and hope. For now, you'll have to live with the open-source drivers, and without compositing (and for that matter, just about any other 3D) support.

Unfortunately, Linux users have to live with the cruel reality that they are a tiny slice of the computing community. And those of us within the community who want 3D support for effects, gaming, or whatever have to live with the reality that we are a tiny slice of that tiny slice of the computing community; Linux is still primarily a development and server OS.

What that means for us, the end users, is that graphics support S U C K S. There isn't anyway around it. Developers have little to no interest in providing the same support to the Linux community as they do to Windows users, for example, as we are such a tiny market. Sorry.

Alright, it's almost sounding to me like X is capable of running, but kdm/gdm are failing to launch, and 'startx' is failing to start up a window manager or desktop environment... Let's try this... Boot into runlevel 3 and then run 'xinit /usr/bin/gnome-session' (assuming /usr/bin/gnome-session exists, of course).

Does that start X and gnome?

Adam

The fglrx drivers do not support KMS, and never will. The open source 'radeon' driver however, does. So there is no need to use radeon.modeset=0 when using using the 'radeon' driver as he is now using.

That is just not true. The open source drivers do support opengl compositing on his GPU with the mesa-drivers-experimental package in F12. Gaming will be more hit or miss, but new enough versions of the drivers will certainly run ut2004 and even doom3.

Now the question is: Why aren't the drivers working properly on his setup. I'm actually not convinced they don't work, based on my line of questioning. I hope to confirm that fact, though.

Adam

Again, I'm not trying to discourage you from helping, Adam, but please read through the initial posts before trying to troubleshoot the issue. Taken from the Arch Linux wiki:


Ergo: KMS is not supported by ATI. You can't solve the problem of an unsupported feature by tweaking!

If the proprietary drivers won't work with Fedora 12 at this point, he's just going to have to live with with the open-source drivers, or switch back to his Nvidia card.

Ah my apologizes on that one. Still, the reason they aren't working is still the KMS issue. See my above post.

EDIT: Unless there have been some updates updates that I'm unaware of (the Arch wiki is usually pretty bleeding edge), the issue still stands.

EDIT 2: (I just can't seem to think ahead today!) Again, the open source drivers do work as long as he disables KMS. See:

Thanks Alex, and sorry for backtracking. But even after restoring the radeon modeset directive (and the vga directive) in grub.conf, I'm getting the same (simulated) hang at boot. Xorg log still shows no errors, and the only warning after the "radeon" driver is loaded in the log is about color tiling not yet being supported.

I'm pretty frustrated at this point, and upset with myself for not doing more homework before ordering this card. I'd done a quick search and saw a few blog posts about having the card up and running in Fedora 12, all of which don't seem to make any sense at this point. And all to save my company $15 under the cost of a comparable nVidia card.

I really don't give a rats ass what the Arch Wiki says. KMS works on ATI cards. Perhaps his card has a particular quirk that KMS is not used to. If that's the case, I'd like to find out. Chances are there are updated drivers on Koji that fix this issue (if it is a driver issue, which I still doubt) since the primary developers of the open source driver commit directly to Fedora.

And, finally, even if he has to disable KMS for some reason, 3D should still work.

Adam

Please try my xinit suggestion.

Adam

Yes: xinit gets me the same barebones gnome session as before.

Sorry guys: I didn't mean to cause any trouble,

OK. Well we're getting somewhere, at least. The driver is at least somewhat functional. We need to figure out why gnome isn't fully starting. Can you try 'xinit /usr/bin/gnome-terminal' and see if X starts up with a usable terminal? The, from within that terminal (assuming you get that far), try '/usr/bin/metacity --replace &' to see if the gnome window manager will then start up?

Adam

Ah, I didn't realize that. From your post, I thought that with the open source drivers X worked perfect minus your compositing support. Obviously the problem lies somewhere else, hopefully Adam will be able to help you in solving it.

Now to another point:

Seriously?! I try to quote a general reference to support my case and that's how you reply?! I'm not trying to say that the Arch wiki is the end all of information, or that I'm any more than generally knowledgeable on this, I'm just quoting a reference. I don't think I was rude in my posts, and if I was I apologize. But please: grow the hell up.


But that aside, good luck on this one.

Alright, my apologies for the remark about the Arch Wiki. The fact is that Fedora is considerably different from any other distribution. The kernel contains many bleeding edge features, including the latest and greatest code in KMS (at least at the time F12 was released.. A lot has changed since then). One of the selling points of F12 was the use of KMS by default on all radeon hardware and the ability to use 3D acceleration on r600/r700 GPUs. Obviously that doesn't mean it will work for everyone, but I just hadn't seen anything in the first two pages of this thread to suggest that this really was a driver issue.

So, to be fair, while I really don't care what the Arch Wiki says about KMS in this instance, I could have been more tactful about saying so :-)

Adam

I can indeed get to a gnome terminal after installing the gnome-terminal package (I am running KDE -- and xinit kdestart also gives me a gui terminal). The problem there seems to be that even though the terminal starts in both cases, I can't get to it to type anything: no mouse or keyboard activity is registered,

Please pastebin your /etc/X11/xorg.conf file. I suspect the lack of keyboard and mouse input is due to this:

Adam

Hmmm ...
http://deesto.pastebin.com/7Fu07eYH

Screen0 and Mouse0 are definitely there ... interesting that only one screen is there too.

In the ServerLayout section, try adding this line and then restart X:

Basically, Xorg tries to use hal to autodetect input devices. If you let Xorg do that, and yet you define your own mouse and keyboard devices, bad things can happen. If you want to define the Mouse and Keyboard, you should tell Xorg *not* to use hal, which is what that option does.

Adam

It looks like adding Option "AutoAddDevices" "off" got the devices loaded ... and then unloaded at the end of the X load?
http://deesto.pastebin.com/k70k7jgN

Also got a bunch of these when trying to 'xinit gnome-terminal':

Boy, you have more problems than anyone I've seen in a long time.

Alright, so if you remove the /etc/X11/xorg.conf, and just let Xorg detect everything, do the mouse and keyboard work when you run 'xinit /usr/bin/gnome-terminal'?

Adam

Heh, no comment, except that's both funny and pathetic.
Nope: screen flickers like crazy in the terminal, otherwise it's exactly the same as before: all black except for white terminal, and can't get mouse or keyboard input.

Alright, how about using this as your xorg.conf:

This way we let Xorg configure the input devices, but we specify everything else regarding the video card. When this happens ("all black except for white terminal, and can't get mouse or keyboard input") are you able to switch to a console and kill X?

Adam