Shiny new Intel gfx drivers (2.3.0)

As it has been announced on several mailing lists, Intel released version 2.3.0 of their X driver. Being back from vacation and all, I’ve only just committed it to portage. Here are a few things Gentoo users might want to know about it.

  • This version is definitely not as disruptive as 2.2.0 (which will probably be remembered as one of the worst driver releases in all of Xorg history). Overall, it really is an incremental release on top of 2.2 with all the bug fixes.
  • Laptop users of i915 chipsets and newer should enjoy new xrandr options to control how the image is displayed on the LCD when not using its native resolution: the old behavior was to stretch the image in both X and Y directions, now the driver supports stretching with aspect ration constraints and not stretching the image at all to keep a 1:1 ratio.
  • i965 does have a video overlay and I think it’s enabled by default now.
  • XvMC support should be much better now on i945 and newer. As I can’t test XvMC (and I don’t really need it anyway), some testing might be interesting. Please let me know how it works on your systems, I’d like to hear from you 🙂
  • Not really technical but very important IMHO: the new release process is now much much smoother. Intel decided to release a new driver every quarter and that’s a great improvement. “Release early, release often”. Intel now also releases beta versions of the driver. It might not seem like much, but it does make my job a lot easier and it really helps to get real users to test drivers on their systems. And it shows: only hours after each beta, bugs get reported and fixed. If only more FOSS projects could work like that…

As a whole, it’s a good release that shows that even big companies such as Intel can successfully build communities that are committed to quality and openness. Big props to all who worked on it.

On the Gentoo side of things, here are some additional notes:

  • As it looks today, 2.3.0 is a prime candidate for stabilization. As such, I encourage all stable users to unmask it and try it on their systems. It should work properly with xorg-server-1.3. If not, please don’t hesitate to open a bug.
  • I’d also like to remind everyone that opening a bug in Gentoo’s bugzilla is a great step to get your problems solved. But in the case of the Intel driver, there’s very little I can actually do to fix bugs: I don’t work for Intel, I don’t know their code nor how the hardware works, I just know about bugs and patches. So if I ask you to open a bug in FreeDesktop’s bugzilla, it’s not because I don’t want to fix the bug, it’s just that I can’t do it myself. Users who actually take the time to do so are usually rewarded by having their issue fixed in a matter of days. So please, take the time to report bugs upstream, it’s in your best interest.

Now, off to work.

Follow up to Diego’s and Luca’s posts

Funny how sometimes different people try to fix the same issues at the same time.

First, I’d like to provide a little insight into Libtool and Dolt because a few people have been talking about it for a week or so, but not that many people know what libtool really does, yet everybody agrees on hating it. 😀

Libtool started as a brilliant idea to have one script that could be used to compile C files and link the resulting object files into whatever we want : executables, static libraries or dynamic libraries. That’s what /usr/bin/libtool does. It’s a cross platform LIBrary TOOL, all in a 218KB shell script. All that code knows about all the C compilers out there, all the linkers and all the subtleties in the command line arguments each and every one supports.

The problem with libtool is that it’s a 218KB shell script. Everytime you build something with an Autotooled project that uses libtool (so basically, all projects that build libraries), for every C file in that project, libtool gets called.

For C++ files, it’s not that big a deal since g++ is quite slow. But for plain C, it’s a whole other issue, as running libtool can sometimes be slower than the actual compiling of the C code it’s used for.

That’s where Dolt kicks in. Basically, Dolt is set up during ./configure and will create a small shell script that takes the same arguments that libtool does. But instead of being 218KB, it’s only going to be a few dozens of lines because ./configure did all the hard work of knowing which compiler and linker are going to be used. Dolt is basically a caching system for libtool. And that’s good.

Now, libtool 2.2 is supposed to be much faster than 1.5.26, and that’s a good thing too because Dolt doesn’t speed up all the operations. Dolt only kicks in for the compiling, not the linking. So all in all, Dolt + libtool-2.2 should be a very good thing for Gentoo users. Let’s hope both gain wide acceptance by upstream projects.

Let’s move on to .la files. Those are text files that everybody has on their systems. Just take a look in /usr/lib, there’s one for almost every .so file. Those are again something libtool creates for the following reasons :

  • .la files contain information about both dynamic (.so) and static (.a) libs. .a files unlike ELF .so files do not contain dependencies, so .la files contains those deps. So this is an interesting feature, but mostly aimed for those who need static binaries.
  • Dynamic libraries have different naming conventions on different operating systems. .la files make it somewhat easier to be cross-platform.

In theory, .la files are a very good thing… In practice, they hurt us more than they do help solve problems.

  • When building applications with dynamic libraries, .la files contain redundant information and therefor are quite useless.
  • When using --as-needed in your LDFLAGS, .la files won’t benefit from the work done by the linker to prune unneeded libraries because .la files are generated by libtool and not the linker. Diego said he would try to write a script that could clean up .la files, but it’s still not a good long-term solution.
  • File system pollution… I have 1096 .la files on a “standard” Gentoo systems with Gnome and a few other apps. ‘Nuf said.

“Well, why don’t you remove them? Can’t libtool work correctly without .la files?”

The simple answer is Yes, libtool can work without .la files, but there are exceptions. Basically those include any app that use libtool’s dlopen wrapper library. libltdl expects .la files to work properly, so that’s a PITA. Apps in that category include PulseAudio, Dia (although I’ve fixed it in upstream, awaiting for a new release), … and KDE.

Yep, KDE 3 really sucks on that very point because if you remove KDE’s .la files, it will just not work anymore. I truly hope KDE 4 doesn’t have that flaw (could anyone let me know?).

I have a plan for the Gnome Herd, which I will probably explain when I have some time to work on it 🙂 Hopefully, it should make everyone happy.

Update: I’ve been reminded (and how could I ever forget!) that KDE 4 uses CMake, so it’s thankfully immune to that problem. 🙂


Folks who follow Intel drivers development have probably noticed that Intel released 2 release candidates in the past 2 weeks.

.901 has been in Portage for a little while, and so far, no one has reported bugs with it. That’s a big first in recent Intel history! .902 was released a couple days ago but I have not yet added it to Portage. And the reason is quite simple: it basically breaks all i855 laptops (including mine!)

The gory details is that the second RC saw a few patches to enable LFP fitting and rescaling properties through xrandr, which is a cool stuff to have anyway. But for now, this feature only works on i915 and above (chips below i855 don’t seem to offer any sort of scaling or fitting, if I understand correctly)

So once this bug has been sorted out, I’ll put .902 with the correct patch in portage for y’all to test. Please do try those releases and push them to the limit: use xrandr, use Xv, use DRI, (maybe not suspending though, that part of the driver still looks shady to me), and please report bugs!

And remember, for each non-dupe bug that you open, God spares a kitten.