Category Archives: Intel GFX Drivers

It’s been too long…

*sigh* I should have written this post a long time ago, but I didn’t. My bad…

And just yesterday, Sune was rightfully complaining about the situation. Now it’s my turn to blog and to let you in on all the secrets I’ve been withholding :)

Quick xorg-server 1.5 Input How To:

If you’ve built xorg-server with the USE=hal, you might have weird issues with your synaptics touchpad or weird keyboard layouts.

There are currently 2 ways of configuring input in Xorg :

  1. Disabling HAL in Xorg: it basically tells Xorg not to look at HAL for input devices and it’ll only read your xorg.conf for configured devices. If you don’t want to muck around with HAL yet, it’s probably a good option. Just stick this piece in your xorg.conf and you’ll be fine.
    Section "ServerFlags"
        Option "AutoAddDevices" "false"
    EndSection
  2. Migrate to HAL: this is not exactly trivial and might require a lot of tweaking. But once you wrap your head around it, it’s not that complicated.

    The idea is to completely remove all the InputDevice sections from your xorg.conf (or even to completely remove your xorg.conf) and let Xorg request input devices from HAL. But we can modify HAL to return configuration values to Xorg.

    For some examples of this method, I suggest reading this sample file which contains almost all the needed documentation.

    Don’t forget to read /var/log/Xorg.0.log towards the end, that’s where input handling prints warnings and errors.

Intel graphics driver with xorg-server 1.5

For some reason, the server crashes if your xorg.conf file tries to load the i810 driver instead of the intel driver. This is indeed really weird as the former has been a symlink to the latter ever since 2.0.0 came out. I’m guessing the migration to libpciaccess broke some assumptions about driver names.

A lot of people have been bit by this, including me, but I of course do intend to properly fix this. First I need to do the pkgmove, and then I’ll just remove all references to “i810″ from installed files (mostly the symlink to the driver and the duplicate man page). Finally, I’ll make the driver print out elog messages if you still have the old driver name in your xorg.conf

GEM

Although I first believed otherwise, a lot of users were actually using TTM with xorg 1.4. Since TTM has been dropped from Mesa and the supporting bits have been removed from the Intel driver, a lot of people are anxiously waiting for GEM support to arrive.

First the good news, I’m actually working on that. I’m tracking branches and building code.

The bad news… it doesn’t work, at least not yet. Intel developers are busy adding support for G4x chipsets and older ones such as my 855GM are not the immediate priority. I’ve asked for help on the various mailing lists but I’m still waiting. To be honest, I’m not even sure I’ve built the various components with the right configure options…

My plan is to wait a little bit for the kernel bits to settle (right now, devs are hacking up 5~10 patches per day for the 2.6.28-rc1 merge window!) before asking again.

Watch this space in the coming weeks if you are interested in Intel graphics on a Gentoo system near you :)

Cheers

Intel Drivers… again…

Just a quick post to let you all know that xf86-video-i810-2.4.2 has hit portage in ~arch.

Here’s my request : please test the hell out of it !! :)

It seems to be a good improvement over the original 2.4.0 release as it has less flicker, but it needs some serious testing. I think there are still cases where I can see flickering but the conditions seem to vary over time and I can’t reliably reproduce the issue.

So please test this new release as much as you can and let me know how it works for you. Bugs should be filed in Bugzilla and not in the comments ;)

As for the new 2.5 branch, it should hit ~arch with a big fat package.mask over the next couple of days.

Oh, and now I’m part of the X11 Team as I have to work with X stuff for my job, I might as well contribute some efforts there too.

Cheers!

Update : Please please file bugs if you still see flickering! Bugs won’t solve themselves! Thanks :)

Intel driver update

Hi all,

Just a quick update to let you know that I’ve just put x11-drivers/xf86-video-i810-2.4.1 to Portage.

Overall, I’m not very happy with this release. It’s definitely not as smooth as 2.3.2 which turned out to be very solid. So please test it out with a recent xorg-server (read, 1.4.2) and let me know in bugzilla if anything breaks.

Again, be prepared to continue the bug hunt in FreeDesktop’s bugzilla as my Intel Powers ™ are very limited. It just so happens that half a dozen Intel developers also roam there, so all in all, it’s a good place to file bugs. Just add “remi at gentoo dot org” as a CC on those bugs so I can keep track of the issues.

Thanks

Update :

Josh asked me a couple questions and the answers might interest all those of you who have Intel chips but don’t follow X development closely. So here goes :

My Thinkpad R61i has an Intel X3100 chip, so I’ll be sure to test out the new drivers. I am sorta scared by your blog post, but, well, as long as I quickpkg the relevant packages before upgrading, I should be okay, right? ;)

Yes, let’s get this straight, the driver won’t eat your laptop and won’t kill kittens either. A lot of the core features do work, but there are some instabilities and some quirky behaviors, and those are the issues I’m worried about.

I normally run the hardmasked/~arch X and Intel packages, with all their quirks, on that machine, so 2.4 shouldn’t all that different.

Yep, 2.4.1-r1 is in ~arch, so ~ users will probably already have it installed by now.

I wasn’t aware of the git overlay. Are there any fixes in upstream’s git that just didn’t make it into 2.4.1? If so, I may have to make the move to the overlay.

Donnie’s X11 overlay has live ebuilds for the “master” branch of all X packages. Beware that intel/master is very different from intel/xf86-video-intel-2.4-branch. I’m currently backporting patches from the latter into Portage as they will end up in the next release anyway. So there’s no need to create a live git ebuild for this particular branch.

As for the current git master, as you may have read on Phoronix and Planet FreeDesktop, the driver is going through major changes. Definitely not for the faint of heart.

Also, when’s the namechange to xf86-video-intel?

I plan to tackle this tiny issue when Donnie decides to put Xorg 7.4 (aka xorg-server-1.5) into portage.

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.

xf86-video-i810 2.2.99.902

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.

xf86-video-i810 2.2.1 in portage

Finally, a new official release of the Intel driver.

A lot of work by Intel and the test community has been put into this release. I for one have been pushing people who posted bugs in Gentoo’s bugzilla to repost to FreeDesktop’s bugzilla. Most of these bugs have been fixed by upstream Intel devs, or at least acknowledged, which is a significant improvement over the previous situation.

Just this morning, Intel’s Gordon Jin has created an intel-gfx community mailing list. Although it requires moderator approval, it’s a great way forward.

Hopefully, b0rked releases like 2.2.0 will be caught much earlier from now on, and the number of regressions should go down as well. From a maintainer point of view, this is making my job much less painful :-)

As always, if you have any issues with this release, Bugzilla is your friend. If you’re planning to use 2.2.1 on top of xorg-server-1.3*, please keep in mind that no-one upstream has tested this configuration, and if you file any bugs, I’ll ask you to reproduce with 1.4.0.90.

Cheers

Intel video drivers 2.2.1 snapshots

Hi all,

I’ve just uploaded xf86-video-i810-2.2.1_pre20080123 as upstream wants distros to do more testing for “old” chipsets. So please, unmask this ebuild and let upstream know how it works/breaks on your hardware.

If you have any bugs, please report them directly to FreeDesktop’s bugzilla and add “remi [at] gentoo [dot] org” as a CC on the bug report. That way, I’ll know when the patch is committed and I can push another snapshot.

Thanks

Edit: I’ve changed to the Gentoo package name as to not confuse Nightmorph ;) I promise I’ll do the pkgmove as soon as possible.

xf86-video-i810 2.2.0 woes

Hi all,

Just a quick word that I’ll be masking xf86-video-i810-2.2.0. It’s currently in ~arch only so stable users don’t need to worry about losing their driver.

Why am I masking it? Well, it’s quite simple: it sucks. Not that I want to belittle upstream’s hard work, but this release is one of the worst since the new 2.x series.

  • Random segfaults on all 965 and older chipsets when using the DRI
  • XVideo is almost entirely broken on 8xx chips
  • Modesetting also doesn’t work on some chips

So while I’ll be masking 2.2.0 for now, I really would like it if people tried this driver and reported on xorg’s mailing list if they have any issues. I and others have already notified Intel devs about these issues and they are taking it seriously. But nonetheless, testing it and reporting what breaks could possibly help xorg devs identify the bugs and fix them for the next release.

Thanks for listening to this Public Announcement :)

Cheers, and Happy Holidays to all.

News update on the Intel Xorg drivers

Hi all,

This going to be like a Public Service Announcement for x11-drivers/xf86-video-i810.

  • Both Doug (Cardoe) and Josh (nightmorph) have asked me to do a pkgmove to xf86-video-intel to better match upstream’s naming. It’s been something I would have liked to see, even before Donnie (dberkholz) gave me the ownership of the driver. For now, my plan is to do the pkgmove when Intel releases a new version of the driver that can be safely unmasked.
  • On the issue of masked drivers, one of Intel’s engineers – Gordon Jim – recently asked for better community cooperation. His plan is to organize testing for older graphic chipsets which they can’t (or no longer want to) test.

    So this is a big shout out to all of us who have felt disenchanted by Intel’s latest drivers. So please, click on the above link to let him know what device you have, and that you’re willing to help. If those tests require patches, I’ll try my best to put those patches in portage (p.masked of course) for everyone to easily test and report back failures.

That’s it for now, hopefully more news about Gnome in the next couple of days.