generically, you need to install it and then select it when you log in the details of how you install it depend on the distro and install media but there will be an installer (a sub-menu in yast or synaptic, as examples depending on whether we are still discussing suse or a debianderived distro) if you are installing from a full DVD 3.x should be available on that, but if you only have a CD or its a limited version you may not have it available there so you would have to go to the 'net to get it - assuming that you have the bandwidth available thus wouldn't be a problem just a bit of a delay as kde isn't small once you have done that the chooser you use to log in with should show the new gui as an option although its probably hidden behind something like session type so you'd need to click on that and select the appropriate option

There's a lot wrong with that driver, but that's for another topic. Drivers sometimes can behave differently with different kernel configurations, maybe that's worth a shot as well. You could copy the kernel config from a working distro (it's in /proc/config.gz) and compile a kernel with the same configuration on the other distro, and see how that works out.

This is another thing that might worth a shot. Make sure you are using the same versions of the kernel and the driver in both distros. 3rd party drivers (and specially the ATi ones) change a lot from version to version. The ATi drivers are a very buggy piece of software, specially when used when xinerama they are horrid, and the latest releases include a lot of fixes for that and many other things (i.e. hangs when exiting X and such things). The 8.9 drivers have just been made available, try them.

I may be wrong but I have the impression that this is a motherboard issue. A little research shows that this is issue occurs with both ATI and Intel cards and that the motherboard is mostly ASUS. I see a few references to Gigabyte as well, which does not really surprise me considering that Gigabyte tends to make boards that are very similar to ASUS ones.
As posted out in another thread on this subject, I was affected by the very same issue two years ago using an ATI1600 and an ASUS P5B. The system would boot up to where fglrx was supposed to be loaded, at which point it would simply freeze. With a bit of experimentation I discovered that it would boot fine if I disabled memory mapping in BIOS - which of course meant that the OS had only 2GB out of 4GB to work with and would be equivalent to simply swapping out 2GB physically. This worked for both the 32 bit kernel and the PAE kernel. When I installed a 64 bit distro and re-enabled memory mapping in BIOS, there wasn't a trace of a problem anymore. Cleary, something went very wrong in kernel space. As long as 2GB was left for I/O, all would be fine but it wouldn't be if less than 1GB was left.
Now, did anyone read the story about the Ubuntu user who kicked up a scandal after decompiling the BIOS on his Foxconn and discovering that the thing was using corrupt Linux tables? Could it be the case that ASUS and Gigabyte are using the MS compiler too, which appears to be much less strict than the Intel compiler to the point of letting this kind kind of bug slip through?

One thing that I find strange is that I can load up opensuse 11 with the fglrx drivers and my 4 gb ram without any problems , but I cannot do the same with any Ubuntu distros I have tried.
Are you saying that this is a possible kernal problem? If that is the case could I take a kernel from a place like http://www.kernel.org/ and just make my own , kind of like the way they build Arch Linux?

well, yes, you could do that. This is easy to follow:
http://www.howtoforge.com/kernel_compilation_ubuntu
If you are feeling adventurous, you can even strip it of all that you don't need, which will make your sytem boot a bit faster (but that is the only area where a custom makes your system faster).
Of course, if you compile your own kernel, you will have to use the fglrx driver that you can get straight from ATI.

Ithink that Ijust might do this. I did install Arch almost successfully a few months back, almost meaning that Icouldn't get the Fglrx driver to install , everything else worked but the fglrx.\
Thanks for the Link :)

I am wondering if I compiling my own kernel how do I make it 64bit?
(Iam a little embarrassed because I have almost totally forgotten what I did while installing my Arch linux

Well, install 64 bit whatever and compile the kernel, nothing special required - but don't forget to copy your existing config from the boot directory first.

Thanks I will do that

ok I tryed to make my own kernal and I recieved this message
"linux-br0b:/usr/src/packages/RPMS/x86_64 # rpm -ivh kernel-2.6.26.5Custom-1.x86_64.rpm
error: failed to stat /home/Shadowfire/.gvfs: Permission denied
Preparing... ########################################### [100%]
package kernel-2.6.26.5Custom-1 is already installed"
I found out that it was some bug so I thought that I could just ignore it and continued.
After about another 20 or so minutes I installed the kernel and changed the grub default to my custom kernel 2.6.26.5, Rebooted but it wouldn't boot to desktop and my computer froze Ihad to do a hard reboot and switch back to the original kernal. I am thinking that the problem is that bug.

now if I successfully make a kernel that works could I use that kernel in any linux distro on my computer?

Yes and no. You wouldn't use the same compiled binary but you can use the same config file. Considering that getting that file right is the most challenging part, that is about as good as simply re-using one kernel on another system.

Why not? The kernel doesn't link against external libs, it doesn't depend on any external api/abi. You can use the same kernel amongst all your distros without any problem.

Because on most distros, you would pack your kernel into the system specific format (deb, rpm, whatever).

And?

I mean, you install the binary image into /boot (call it vmlinuz or whatever). And then modify your grub.conf or lilo.conf to add the kernel.

All you need to boot a different distro with that kernel is to copy the same configuration over and over and change the root= parameter.... I don't see why the package management would get in the middle of that. I never use my distro's package management systems to handle my kernels. I use only vanilla kernels, and when I need a concrete patch, I patch by hand. All my distros at a given time boot the same kernel, and I see no reason why a kernel would be good for a distro and not another.

Where can I learn to do this? things like making my own patch .
I guess I should first learn how to make a kernel that works .the last one I made well didn't work properly I booted and I made to just before my desktop then my Computer froze and I had to do a hard reboot :(.
But I really want to learn how to do this correctly