On IRC a couple days ago, someone popped up with an Intel i945 unable to get Compiz to start. He'd get output like this:
/usr/bin/compiz.real (core) - Fatal: No GLXFBConfig for default depth, this isn't going to work.
/usr/bin/compiz.real (core) - Error: Failed to manage screen: 0
/usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
That's pretty confusing and un-helpful. To top it off, I have an i945GM which has always worked perfectly. It seemed a lot of people agreed with "but...it's Intel. Intel always just works with Compiz...that's not right!" JDong said something had to be seriously wrong if an i945 wasn't working with Compiz. He was kind of right. I'd say anything in the kernel falls into the category of "serious," but what was actually wrong in the kernel was, thankfully, not huge. He found Bug #204762, which applies to this case. He linked to an upstream change in the Linux kernel which shows the exact problem. The bug has been marked for 8.04.1, due in July.
There are two cards called i945. Go figure. The version in my laptop is the GMA. The version in his computer is the GME. Guess what else? The kernel in Hardy knows what mine is. It has no idea what his is, beyond that it uses the intel driver. That git change makes it really obvious how you fix this: recompile the kernel with that change. Now, asking someone to recompile their kernel on the 2nd day they've been using Linux is just a little too sadistic for me, so I ended up SSH-ing into his computer and doing it for him. It worked! Yay!
So that all you who are stuck in this boat can get yours working too (without waiting til July), I've made a little script to automate it. Daniel Chen gave me some help because I don't understand how kernel ABIs work like he does, so thank you Dan. Here's what you do:
cd ~/Desktop wget http://student.seas.gwu.edu/~mac/files/945correct.sh chmod +x 945correct.sh ./945correct.sh
The first thing the script does is check to see if your hardware is affected by this bug. It will exit if the answer is no. Then it'll download the build dependencies and the source code, modify it, update the version just a bit so that Update Manager doesn't try to undo it, compile the new kernel (this part will take an hour or two depending on your machine), make debs of it, and then install those debs. Finally, it'll ask you to reboot. You don't have to reboot immediately; it simply won't go into effect until you do.
I'm not making any guarantees about this script, but the patch is known to work and worked on his computer. I turned off the "do you need this?" check and ran it on my computer without any problems. So, I think it should work for you, but if it doesn't, let me know where it screws up, OK? And pasting just "Error 2" in the comments is not enough info to debug.