Intel Arrandale graphics and kwin compositing issues in 11.3+KDE4.5.3

I have repeatable x lockups and graphics artifacts when enabling compositing with kwin (KDE 4.5.3) using opengl on a core i3 with arrandale graphics. You can crash it repeatedly by doing things like switching window decorations. I’m pretty sure the same issue effects kde 4.4. The problems go away if you disable compositing or switch to xrender, but performance and feel suffer greatly.

My drivers are “vanilla” updated 11.3 - Xorg intel “2.12.0” and opengl “Mesa DRI Intel(R) Ironlake Mobile GEM 20100328 2010Q1” and “OpenGL version string: 2.1 Mesa 7.8.2”.

I believe this is a known issue - I have seen a number of threads here at opensuse reporting a version of the issue - but I haven’t seen any solutions posted other than to avoid using accelerated compositing. I have read the SDB: Configuring graphics cards and graphic card practical theory resources and have spent a fair amount of time trying various options. I have skipped trying IEGD as I believe Intel isn’t targeting arrandale with that release but that might be a mistake on my part.

KDE seems to track this same issue (or similar) as a known bug here: and resolved it as an upstream (intel driver) bug and suggests updating to newer drivers.

Along those lines, I have looked at the newly released Intel 2010Q3 graphics package Intel Linux Graphics: 2010Q3 to hopefully resolve the issue. In particular, it updates mesa to 7.9 which the kde bug suggests. I’m up for compiling these out of their git trees, but I wanted to ask before I jumped in.

My questions:

  • Have I missed some easier known working solution or does this seem like a bad idea for some reason?
  • Is there a prepackaged version of these or similar that I haven’t discovered?
  • Has anyone built these and found that it fixed their compositing problems?
  • Does anyone have any experience with how “tied” these various components are? Might I be able to just upgrade mesa for example, or is it likely I need to use the bulk or all of the matching set of 10Q3 releases?
  • There are some notes about Xorg 1.9 being suggested at least for one component. Anyone know if I’m likely to end up having to rebuild Xorg and kde etc to go along with these? I might want to surrender early in that case.

Obviously I’m not looking for answers to all those questions, just if anyone has any insight about any of them or has other advice I’d be obliged.


I do not think you have missed any easier solution.

YES, but there are risks to install the latest Intel driver. There is a packaged version here:

and if one looks inside xorg-x11-driver-video-7.5-131.2.src.rpm by typing:

rpm -qp xorg-x11-driver-video-7.5-131.2.src.rpm -l

one will see the rpm was build with the source code: xf86-video-intel-2.13.901.tar.bz2
… ie the packaged intel 2.13 driver.

But in my experience over 50% of the time when one installs drivers from the X11 repository, it completely breaks one’s system forcing a re-install.

Thanks for the help & wisdom. Also, thanks for the pointer about inspecting the src rpm to check the component versions. I’ll make sure I have a good backup and try out the package and report back in case anyone else is interested.

Brilliant. I now have kwin happily compositing with hardware acceleration without any of the previously associated x crashes or any apparent new problems. So far, this was 100% successful

For anyone else reading along, the process was pretty close to painless:

  • I backed up my root partition
  • I added the Xorg repo:
  • In software management, I switched to the repository view, selected the XOrg repo and clicked “Switch system packages to the versions in this repository”
  • Hit accept to the large number of package upgrades
  • ~2mins later (~180MB) the upgrade was complete
  • I rebooted, everything worked as expected including my custom grub/kde boot/kdb/kde themes/etc
  • I switched from Xrender to OpenGL and things just sped up - no crashes or visual artifacts so far.

For reference:

Linux crabapple #1 SMP PREEMPT 2010-10-25 08:40:12 +0200 x86_64
Qt: 4.6.3
KDE Development Platform: 4.5.3 (KDE 4.5.3) “release 8”

New version strings:

  • X.Org X Server (1.9.3 RC 1) (Release Date: 2010-11-13)
  • Module intel: vendor=“X.Org Foundation” compiled for, module version = 2.13.901
  • OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile GEM 20100330 DEVELOPMENT
  • OpenGL version string: 2.1 Mesa 7.9

I see that the repo must be quite active based on the XOrg build being 3 days old. In your experience, is my success probably based on hitting a “lucky” set of package versions akin to hitting a good nightly build vs. a bad nightly build? Or does my success bode well for others looking to solve similar arrandale rendering problems?

I’ve only had about 3 hours worth of uptime with the new XOrg, I will try to follow up after I’ve put it through some daily use and note any new issues I run into.

Thanks again oldcpu, this undoubtedly worked out much more smoothly than me trying to build everything myself from the intel git trees.

Glad to read it worked.

If I may make a suggestion, since you now have a baseline that ‘works’, I recommend you IMMEDIATELY backup the rpms that you had to add, in case you need to roll back to this new ‘baseline’ configuration.

You can figure out what rpms were recently added by typing:

rpm -qa --last

which will give you a chronological list of installed rpms. If that scrolls by too fast (which it tends to do) you can redirect the output of the command to a text file with:

rpm -qa --last > myrpmlist.txt

and open up myrpmlist.txt with a text editor. Take a look at look at the date of the rpms that were installed, and figure out the one’s that you recently installed.

Then go to the repository and download those rpms, and save them on your hard drive in a directory /home/tslivingston/mybackups or something like that.

Those rpms are changed every few days, so you should do this ASAP.

I also recommend you now remove the X11/xorg repository from your repository list. As I noted the rpms on that repository are unstable and while the rpms there works now, new ones may break tomorrow.

Good luck and glad to read of a measure of success here.