Intel GMA 500 (Poulsbo) graphics on Linux: a precise and comprehensive summary as to why you're screwed

So, poking around idly on Google this morning, I came across the interesting fact that there is, in fact, a native Linux driver for Intel GMA 500 - Poulsbo - graphics on Linux.

Don't get excited, though. It's not like it's actually any use.

That was the summary. Here's the gory details...

As I wrote in my previous post, the GMA 500 is not really a follow up to all the previous Intel chips. It's a bit of Intel's platform with a PowerVR (those of you who've been breaking crap as long as I have may remember PowerVR as an early contender to 3DFX and NVIDIA; they've since scurried off into niche markets) chip slapped on top of it. So it's basically a whole new architecture that needs a whole new driver.

Aside from the Vaio P and a couple of other systems, there's one significant machine with the GMA 500 chip in it: the Dell Mini 12. Why's it significant? Because Dell ship it with Ubuntu.

So, yes, there's a native driver. Intel, Dell or some combination of the two contracted out to Tungsten Graphics to write a driver for it. This is presumably because Tungsten have been supporting PowerVR chips for a long time, so they know their way around the hardware. So, the driver was written, and included in the special-sauce version of Ubuntu that Dell uses, and also in Ubuntu Netbook Remix. It was even developed under the auspices of the Moblin project at first, and you can find the code in Moblin git - driver, kernel module. Where it hasn't been touched for eight months.

This is the first clue that all is not well. Up to that point it all looks fairly straightforward, but after that it rapidly goes to the dogs.

Trying to get the thing to work on a modern distribution, the first thing you notice is that it's messy code. The kernel driver consists of a copy of about half of drm, with all sorts of stuff included and built that doesn't really need to be. And it's not remotely in sync with current drm. All it really ought to be is a few files which should have rapidly been merged into Mesa upstream. There's even a comment in the code that shows the authors are aware of this, saying that one fairly trivial change should be done before the code is contributed upstream. But the change hasn't been done to any Tungsten-, Dell-, Intel- or Ubuntu-sourced version of the code I can find, so it's still a mess languishing in its own repository.

The second thing you notice is it doesn't build with any kernel post-2.6.24, due to that issue and a couple of others.

The third thing you notice, if you're lucky, is that it's not even really the latest version of the code, and this is where things get really odd. As I mentioned, the copies of both the X driver and kernel module in git have not been touched for eight months. However, squirrelled away in dank corners of the Ubuntu empire, you'll find rather later versions of the code. It has eventually been figured out that the latest version of the X driver code is this one, if you combine the 'upstream' tarball (which is not, in fact, available anywhere 'upstream' that anyone I know of can find) and Ubuntu patch in that directory. The latest version of the kernel module code is stuffed in Ubuntu's Miscellaneous Kernel Modules tarball - this one.

The further you dive down the rabbit hole, the odder things get. The X driver seems to depend on a proprietary firmware file, called msvdx_fw.bin, for...something. Apparently it's needed for 3D acceleration and video playback acceleration to work. You can download this file from a post in an extensive and frequently messy and/or downright ill-informed Ubuntu forum thread on the topic. And, as far as I can tell, nowhere else. It also seems to depend on a supplementary X driver, Xpsb, for the same things - without both the firmware and Xpsb, 2D video playback acceleration and 3D acceleration don't work. I don't know where the heck you find that. The source trees definitely don't build it.

Some of this is documented - in passing, seemingly more as an example case than anything else - here. A page that's just sort of lying in the Ubuntu Wiki. Again, I only found it through the giant forum thread. The associated Launchpad project is listed as 'Approved', since May 2007, but 'Not started'. With no other information.

So, anyway. I picked my way through this bizarre minefield and then tried to get the fricking thing to work.

First I hacked up a patch for the kernel module myself to make it build, not really knowing what I was doing. But it seems to more or less work. When it loads, it gives me a native resolution framebuffer. Out of interest, trying to start X with the fbdev driver at this point gets started and shows the grey dithered "X is starting up now" screen, but then hangs the system with caps lock and scroll lock lights flashing. Interesting result, but not what I was really looking at anyway.

Later on, while trying in vain to find some combination that would work, I found that Olivier Blin of Mandriva has been poking at this stuff, as he has a cleaner patch to make it build against 2.6.27 in his personal scratch directory: here. So I tried building with that patch instead of my own hack. They seem to work about the same.

Then I poked about at the X driver. It expects to build against various headers from the version of drm in the kernel module source, not the system copies (or at least not the system copies on Fedora 10). It also expects a particular xf86mm.h, which I pulled out of the relevant Ubuntu libdrm-dev package - so already having to hack stuff up here. With that and a few other minor tweaks, I got it to build.

But...yeah, it doesn't work. With the newer version of the X driver from Ubuntu, it fails with a "could not mmap framebuffer (invalid argument)" error, almost immediately on trying to start X. With the older version from Moblin git, it just freezes on X startup. The system's still running - I can power it off clean with the power button, it shuts down properly - but X doesn't start and I can't see a console either. There's just a text cursor frozen at the top left of the screen. The last lines in Xorg.0.log are:

(II) Primary Device is: PCI 00@00:02:0 (WW) Falling back to old probe method for psb (II) Debug: psbProbe

Okay, so after a whole day spent bashing around at this crap, I can very confidently and conclusively say, it's utterly broken. By the looks of it, you can get it up and running, with a bit of futzing around, either by running Ubuntu Netbook Remix or running Ubuntu Hardy and forcing the Netbook Remix packages onto it - see the forum thread for details on that. But with any modern distro, it just doesn't look like it's going to work.

This is really silly, because the code is obviously 99% basically there and working. It just needs the people who actually know the code and the hardware to put it in the right places and not random obscure undocumented repositories, submit it upstream, and keep it up to date. But because, for whatever reason, the Intel, Tungsten, Dell and Ubuntu folks can't get their fingers out of their asses and actually provide the code in a sensible, sane and open way, few people even know it exists, no-one's seemingly working to keep it going with newer kernels, and libdrm, and no-one has a freaking clue how to use it. And every Linux user with this chipset is getting screwed.

It's not good enough, guys. Just get together, fix the freaking code, and get it in the kernel and so distributions can make it just work and everyone will be happy. Thanks.


pseudonymjames wrote on 2009-01-31 08:28:
Adam, Thanks for the update. I have been waiting for a post like this since the P was announced. As a mac user, I can't get myself to use Windows again as a main operating system and the form factor for the P would be ideal for me, so I was waiting with someone with more linux knowledge to give it a go. I have been following that Ubuntu thread (I posted it for you on Engadget) and it didn't inspire much hope for the P but I didn't want to give up. It looks like I will have to keep waiting before I get my own P. Good luck!
adamw wrote on 2009-01-31 16:32:
I should note that it really isn't unusable or anything with the vesa driver. It runs in a native aspect ratio resolution - 1024x600 - so nothing's squished up or weird-looking. It's obviously not as sharp as the native resolution would be, and it makes stuff like rendering web pages slower and video playback unusable, but it's livable-with for now. I dunno if I'd flat-out recommend anyone get a P until it's fixed, but you wouldn't kick yourself if you did, I don't think.
gregdek wrote on 2009-01-31 10:27:
Welcome aboard, dude. :)
adamw wrote on 2009-01-31 16:32:
Thanks, Greg :)
brteag00 wrote on 2009-01-31 17:09:
Your conclusions are basically the same as those I came to. I've been a prolific poster in the Ubuntu forums thread you mentioned, though I don't count myself in the "ill-informed" crowd. I knew it was a mess going in, but the hardware (Mini 12) fits my needs so perfectly that I couldn't pass it up. FWIW, the two binary blobs, and msvdx_fw.bin, came from the Dell-distributed Ubuntu image. The DRI file,, and the hardware-specific libva driver,, also came from there. As far as anyone can tell, they are redistributable. The Intel Embedded Graphics Driver release notes suggest that they'll be available "officially" in the next IEGD release, which (judging from previous releases' timing) should be RSN. You're perfectly right to be upset that the driver situation is so screwed up for such a promising platform. On the other side of the coin, my Netbook Remix-based install is rock-solid and performs well. It's not clear to me that there's a whole lot to be excited about in Intrepid or Fedora 10 (except a new NetworkManager, which I pulled from a PPA.) And with GEM, DRI and the X server all in flux, the state of Linux graphics in general is a mess right now anyway, so it doesn't really surprise me that Intel/Tungsten are waiting for things to settle down before they get their act together. I noticed that Phoronix picked up on the issue today. Hopefully, some better visibility will convince the people working on the drivers that a little more transparency is in their best interest, as well as ours.
adamw wrote on 2009-01-31 17:19:
Well, up to a point, Lord Copper, except - there seems to be no problem keeping xf86-video-intel up to date with the latest developments in and the kernel. Why? Because it's properly documented hardware with no stupid proprietary bits, in the proper public repositories, maintained by Intel folks who know what they're doing in concert with the developers. That's how a proper open source graphics driver project works. When you look at the psb project by comparison - no hardware docs, lots of stupid proprietary bits, hidden in obscure repositories, maintained by God-knows-who with certainly no input from the developers - clearly something has gone terribly wrong. It's been described by high-level ninjas as a 'clusterfuck', which I wouldn't say is far off the mark. Yes, the whole story with regards to next-generation stuff like GEM is in flux, but that doesn't excuse the fact that they can't even get a basic working 2D driver released properly. I don't need GEM, I don't need video playback acceleration and I don't even need 3D acceleration, all I need is a 2D driver with normal performance capabilities that'll drive the panel at native resolution. That really shouldn't be too hard to pull off. Yep, Phoronix picked it up, I asked them to. :) I've now sent the Phoronix story to Slashdot - if it gets picked up there that'll certainly get Intel's attention... As for just forgetting about it and using Ubuntu 8.04 or UNR - well, on the Vaio P, that'd have other problems. The older kernel probably wouldn't support the wireless adapter, there may even be other hardware that wouldn't work.
brteag00 wrote on 2009-01-31 22:44:
I think you misunderstood my intent. I am no Intel apologist, and I wasn't saying the situation was acceptable in the long-run -- I don't want to be stuck running Hardy forever. I was saying that, given the circumstances, I feel fortunate that there's SOME setup that works. I've certainly been around long enough to remember when that wasn't necessarily the case. The odd mix of open and proprietary reminds me of an embedded environment - like what the Open Handset people go through when they write code to control GSM modem. No surprise, since Intel has aimed Poulsbo pretty squarely at the MID market. Anyways, /. picked up the story too, so hopefully we'll see some movement on the issue. For all us frustrated Poulsbo users, thank you for agitating on this.
slothman wrote on 2009-02-01 00:10:
How can we help this along? Has anyone gotten "bug bounty" together so we could chip in for a reward for the developer who solves this?
adamw wrote on 2009-02-01 00:29:
Unfortunately that's not likely to be practical in this case. It's difficult hardware for a third party to work with without documentation, so it's not a case of it being a neglected-but-reasonably-possible task (the kind of thing that bounties work well for). If it was practical for a third party to deal with this - i.e. if there was decent developer documentation available - it'd be happening already. Without that, no reasonable 'bounty' amount of money is going to do the job. The only amount of money that might help is a very large amount paid directly to Intel to enable them to hire the people to do the job themselves faster, but I don't see anyone doing that. Intel have said they will get around to it, I'm just trying to put some pressure on to speed it up...
[...] AdamW on Linux and more » Intel GMA 500 (Poulsbo) graphics on Linux: a precise and comprehensive su.... [...]
[...] like a bloody mess. Adam Williamson of Red Hat (previously known for his Mandriva work) has shared some of his Poulsbo experiences. We will only be seeing more Intel Poulsbo devices enter the marketplace, so hopefully [...]
[...] en dispositivos MID’s y netbooks, sus drivers tienen componentes privativos y han sido duramente criticados por su deficiente [...]
[...] en dispositivos MID’s y netbooks, sus drivers tienen componentes privativos y han sido duramente criticados por su deficiente [...]
[...] en dispositivos MID’s y netbooks, sus drivers tienen componentes privativos y han sido duramente criticados por su deficiente [...]
mkelly wrote on 2009-02-24 00:34:
I just picked up a Vaio-P and noticed that when you're in Sony's Linux-based "crossbar" quickboot environment, you get a 1600x768 X session with what appears to be a native driver. Anyone know what version of Linux this quickboot environment is based on?
chizu wrote on 2009-02-25 07:10:
I've gotten native resolution to work using uvesafb and fbdev on Gentoo, a similar setup should work on Ubuntu. I'd be interested in hearing about results on older kernels (particularly if the backlight turns on after waking the laptop from sleep under the Ubuntu kernel): Here's what I did in Gentoo: @mkelly The Linux included in the startup environment is Corel InstantOn. I have the filesystem images it uses, but haven't started tearing them apart yet. Hopefully Intel and Tungsten/VMWare get us some specifications or at least something working.
mc wrote on 2009-02-26 08:23:
To add to what mkelly said: Since XMB uses Linux, you should be able to request the source code to the X environment that they used. If a binary driver was used, that might not be as helpful, but maybe it could be manually added to Fedora 10/11 or something. Perhaps you could browse the partition that XMB lives on and poke around for that driver. I wonder if we will see a VGN-P listing at soon. The main search page is I have been waiting for a form factor like the Vaio P for a long time: A small touch type-able keyboard with a display sized to the keyboard for portability. Fanless operation, LED backlighting (lower power consumption), and higher resolution are also big factors for me. The moment that I see Linux completely work on it is the moment that I will be buying one.
adamw wrote on 2009-02-26 15:09:
"Since XMB uses Linux, you should be able to request the source code to the X environment that they used." Um, nope. X is not under the GPL. It's under the X11/MIT license, which is similar to the BSD license (there's no obligation to provide source when redistributing).
[...] qui fonctionnent à la perfection. J’ai toutefois évité le Mini 10 et Mini 12 à cause de problèmes de compatibilité du chipset GMA 500 (et ils sont trop chers/encombrants, de toutes [...]
gozala wrote on 2009-03-04 15:41:
Hi Adam, I'm one of the guys thinking to buy this laptop (But I'm definitely not going to switch to windows) so I have some question regarding the laptop * Does WWAN (HSDPA) & GPS works ? * Web camera ? * Build in mic ?? Thanks in advance
adamw wrote on 2009-03-04 16:47:
WWAN / GPS - can't tell you, as they're not included in the Canadian model. Webcam works fine, but displaying the output of the webcam is very jerky because of using vesa for the graphics. With a native graphics driver this would be fine. Mic I haven't tested. It's just an Intel HDA chipset, though, so it should be fine.
gozala wrote on 2009-03-04 16:56:
One more question Do you think it could be used as primary computer or it's just a netbook
adamw wrote on 2009-03-04 17:14:
Depends on your exact usage scenario. I wouldn't be able to use it as a primary computer mainly because of the small screen real estate (my main system has 2x20" monitors...) and slow CPU (I do have to compile stuff sometimes). If those aren't major limitations for you it may be OK - it's worth noting the keyboard is really pretty decent. I was able to use it for a week when I was in Raleigh quite efficiently, but I was happy to go back to my desktop after that.
[...] thanks to a hot tip in the comments to my original post, I’ve actually got native resolution display on my Vaio P [...]
virus7 wrote on 2009-03-24 20:51:
thanks for Ur detailed post. the mini 12 is stylish, isn't it? it's a shame, hardware implemented so badly. my point is; not driver ever will help. try any ditro, use a generic vesa driver, use extensivly and watch it chrashing. so what?the driver is the reason? I do doubt that. no distro I familiar with gets the native resolution to work without that binary. may be dell tryed to save some money on the bios implementation as done before by other peaces of cheap hardware. play a dvd using the original binary, watch the mini 12 crash within secondes. too bad. such a beauty, cool technology mostly consumpting at 8 Watts power or less. the best way to find out is to install windows and see it playing dvd's. microsoft likes to work arraound the bios code as a principle. this I must confess is in such bad cases a really good point for windows! It is neither the driver not the distro it is the implementation. send it back or trash it.
adamw wrote on 2009-03-24 21:21:
I have the Vaio P, not the Mini 12. FWIW, your issues seem to be specific to the Mini 12; I've not had any crashes running the Vaio P with the vesa driver (in fact, it's never crashed at all). Your problem with native resolution may be similar to the one the P has, that's fixed in a recent vesa update for Fedora: see my later post, here.
wleewillard wrote on 2009-04-23 01:48:
I was a little to quick to the game, and was hoping to use this as my traveling work laptop. Problem I am facing now is that I work for Red Hat, and I certainly can't be running windows, but it doesn't seem anyone can get this to work with Fedora, or any other flavor of Linux. Has anyone heard of anyone having luck using just an external monitor with this? I have the vaio P series cradle that has an ethernet port, and a vga connection. Even if the included screen doesn't work, using an external monitor would be terrific, cause I could just use the work spaces. thanks for any advice!!!
adamw wrote on 2009-04-23 02:20:
the internal display on the P should work out of the box in F10 (it does for me), just at the wrong resoluton and slow because it's using vesa. if you do an official update you should get an updated vesa package which gets the native resolution working (but still slow). external monitor I really doubt will work with vesa, sorry.
wleewillard wrote on 2009-04-24 00:53:
So do I just need to wait for the kernal to be updated by the community for the GMA 500? Thanks Also have you seen this, would this work? knoppix 6 and eeebuntu remix of 8.10 both set the correct native 1600×768 resolution. They both do it by merely allowing the receny xorg to do it automatically rather than by setting anything special in xorg.conf. However you can get regular ubuntu to do the same by overriding the monitor refresh rate detection in xorg.conf. sudo vi /etc/X11/xorg.conf find the Monitor section, looks similar to this: —-snip—- Section “Monitor” Identifier “Monitor0″ ModelName “Generic Monitor” # HorizSync 28.0 - 96.0 # Warning: This may fry old Monitors # VertRefresh 50.0 - 60.0 # Extreme conservative. Will flicker. TFT default. EndSection —-snip—- coomment out any HorizSync and VertRefresh lines that aren’t already commented out, then add these two lines before EndSection: HorizSync 30 - 80 VertRefresh 50 - 90 Then reboot. xorg automatically runs at 1600×768 after that at least on xubuntu jaunty as of today. These are not specific or special numbers that actually reflect the limits of what the screen can do. They are merely wide enough to allow the automatically detected correct native 1600×768 (16 & 24 bit) to be used. I haven’t yet tracked down why xorg seems to be a lot slower in native xubuntu installed onto the 8G recovery partition on the hd than either knoppix 6, puppy linux, or eeebuntu from intrepid (8.10) all running from either usb sticks or from a 4G memorystick pro duo(*). hd access I expect to be different, especially for puppy which loads completely into ram, but xorg itself is pretty slow. Tolerable given the hardware, but other versions and even Vista all perform better on the same hardware. (*) You can’t boot directly from the ms slot, but once you have grub in the mbr and grub support files on the hd, in the former recovery partition most likely, then you can take just the kernel and initrd from say, knoppix, and put them with the other grub boot files, and the rest of the knoppix cd on the memorystick, and add a stanza in menu.lst to tell grub to load the knoppix kernel and initrd, and then init in knoppix’s inird will find the knoppix image and user-persistent-data image on the memorystick and use it automatically. So you can have knoppix always available as a boot option without having to use a seperate usb stick or having to install more than a couple megs on the hd. Also, as long as you leave Vistas ntfs filesystem alone the InstantON/XMB feature still works after installing linux over the recovery partition. Or at least as long as there is an NTFS partition and filesystem with c:\InstantON and c:\Users\Public directories & contents saved from the original install.
adamw wrote on 2009-04-24 01:56:
wleewillard: it's nothing to do with the kernel, just xorg-x11-drv-vesa . The update is already there for Fedora 10, it just improves the way vesa detects the available resolution so the native resolution gets used.
[...] poulsbo driver in Ubuntu 9.04. Thus, I’ll have to continue using my Dell Mini 12 with the shitiest version [...]
wleewillard wrote on 2009-04-30 20:40:
has anyone considered using an NDIS Wrapper, to use the windows driver, but still work with Linux..
adamw wrote on 2009-04-30 21:03:
wleewillard: ndiswrapper only works for wireless network drivers ('NDIS' is the Windows network driver model). It's not a generic wrapper for any kind of hardware driver. It would be very difficult to write such a wrapper for graphics card drivers, as the Windows and X graphics APIs are very very different.
wleewillard wrote on 2009-05-02 03:13:
Alright.. Let me do some more research... Does the HP Mini use the same graphics card? Because a friend of mine at the RH HQ was using a fedora OS with it, and had an external monitor running. Any ideas you can give me of what to ask some of the senior Fedora people?
adamw wrote on 2009-05-02 05:22:
You can just ask me. :) The original HP Mini (the 9", the 2133) used a VIA Chrome graphics chipset, which is a slightly obscure one - it's probably ranked fifth on the list of Common Graphics Adapters after Intel, NVIDIA and AMD and then Matrox - but has pretty good support through the 'openchrome' driver. openchrome's maintainer packages openchrome for Fedora, so Fedora support for that chip is pretty decent, at least F10 and probably F9 with latest updates have good native support for the internal display and external displays. The later Mini models - the Mini 1000 10" series and the revised Mini, the 2140 which stuffs a 10" screen into the same case as the 9" 2133 - use the good old Intel i945 chipset, which doesn't have the GMA 500 issues, it's well supported by the 'intel' open source driver.
wleewillard wrote on 2009-05-02 21:41:
Well crap.. Looks like I am SOL for now. Thanks!!
wleewillard wrote on 2009-05-05 02:01:
So another question. I have an old macbook I wanted to load up with fedora 11, where would I go to download the right image for it. I downloaded the entire image, but there are so many files and folders, I can't tell which one to burn as an image. Also I need the 386 one right? Thanks by the way, do you take donations to keep your sight running, and for your time?
adamw wrote on 2009-05-05 06:49:
I'd just get it from , really. If it's a REALLY old macbook - with a PPC processor - you'd want the one labelled ppc. Otherwise, yeah, i386 or i686 would be it. No, I don't take donations, I get paid well enough :). Actually I'm probably going to take the google ads down soon too, it feels a bit cheap to still be running them now.
zekeb wrote on 2009-05-05 21:47:
Hi Adam, I miss you over at the Mandriva forums, but glad you have a happy home with Fedora. I just got a new Mini10 and it sadly has the GMA 500 video device. I sure wish I had read your post before I bought it :( I am running MDV 2009.1 on it and besides the horrible graphics, it runs flawlessly under gnome. I hope that this issue is resolved shortly because as you pointed out somewhere else, there are a number of "mainstream" netbooks itching for Linux out right now that use this chip. P.S. I will be in BC next week visiting my in-laws. Scare all the rain away for us, will ya? :)
wleewillard wrote on 2009-05-07 12:47:
Adam, Would there be anyway to use the drivers and codecs available in WinDVD within a linux operating system? I know that they help the GMA 500 perform much much better using a windows operating system.
[...] Poulsbo chipset (just like the Mini 12), which is great for power consumption, but apparently a real chore when it comes to Linux support. In addition, also to keep the price low, there’s the ever [...]
Revisiting Altruism - Poulsbo & More wrote on 2009-05-22 01:32:
[...] we can’t get official figures from the Intel ARK, and the graphics drivers under Linux are a complete shambles apart from the custom 8.04 Ubuntu Builds Dell liaised with Canonical to develop. When I say [...]
[...] all due to chipset/video driver issues. This article is a little dated but gives some information: AdamW on Linux and more
[...] [4] Intel Pousbo Linux driver in Dell Mini12 Possibly related posts: (automatically generated)FOR SALE! ACER TRAVELMATE 6291Acer Aspire [...]
jhuckins wrote on 2009-07-22 15:58:
I have been pulling my hair out just trying to configure a frame buffer device at 800 x 600 resolution in RHEL 5.3 on a Poulsbo system. After porting our application that uses Qt Embedded 3.3 without X-Windows support, we are currently stuck using the QVFB virtual frame buffer to run the app, which, of course is bogus. Can anybody provide me with specific details of how to configure the platform to support a /dev/fb* device for our app? Thanks in advance, Jeff
adamw wrote on 2009-07-22 16:24:
Sorry, I've never really used a framebuffer with it. You may need to have at least the kernel module built and working to get a framebuffer device out of it...
jhuckins wrote on 2009-07-22 16:55:
OK, since I'm a newby wrt kernel framebuffer device modules, how do I get the module working? As far as I know, I do have the kernel module built. Regards, Jeff
[...] The current state of Linux drivers for the Poulsbo chipset has rightfully been described as ‘a mess‘. There is a driver available for some Linux distributions, but it does not work with the [...]
[...] [4] Intel Pousbo Linux driver in Dell Mini12 Possibly related posts: (automatically generated)No [...]
[...] And this is also the Intel that, for a more recent example, is abandoning support for the GMA500 chipset in Linux. There are open source drivers for Poulsbo, of course, but they are broken. [...]
[...] Intel GMA 500 (Poulsbo) graphics on Linux: a precise and comprehensive summary as to why you’re sc... [...]
[...] on a booklet 3G Ok, so after reading around on the net, it seems like linux on the Nokia Booklet 3G is a no go. Mostly due to the GMA500 GPU. [...]
[...] Why you are screwed with the Poulsbo [...]
[...] [1] Mais detalhes sobre porque evitar uma Intel GMA500. Meu feedback geral do netbook é positivo, mas o futuro dos drivers de vídeo é preocupante. [...]
[...] posts from Adam Williamson ( were very useful and based on that I decided to take a look at Mandriva’s svn [...]
Clusterf@ck | Libre Bytes wrote on 2010-07-22 10:00:
[...] intel-gma-500-poulsbo-graphics-on-linux-a-precise-and-comprehensive-summary-as-to-why-youre-screwed/ [...]
[...] , I’m always after any news about poulsbo drivers. First of all, many of us know why we are “screwed” , so (until lately) we had no choice except to use proprietary drivers which Adam Williamson made [...]
[...] L’odissea gma500 [...]
Intel… non ti supporto | Netgrid wrote on 2014-03-01 10:50:
[…] L’odissea gma500 […]
[…] , I’m always after any news about poulsbo drivers. First of all, many of us know why we are “screwed” , so (until lately) we had no choice except to use proprietary drivers which Adam Williamson made […]
some1 in need of intel dr lol wrote on 2014-12-08 19:19:
For the so-called "win", meaning, the internet safety wise looser type of systems, any software or drivers are NO problem to install - downside of win: no net security, as said. BIG downside of Linux nevertheless: Drivers and programs can be a pain in the u know what to either install or uninstall. Sure, most programs and scenarios work, nowadays, in mostly Linux Mint, where on my newer Lap, the graph driver installation didn't f... up my system, which did happen on lubuntu, when I tried doing lubuntu, before, directly on the lap, which I can not recommend, for the simple and correct graph driver installation from within the graphical operating system surface, brings the Lubuntu user to a dos screen after reboot -- not so Linux Mint, which survives a graph driver installation. Mint is also stabler in terms of a stable Startmenu and Panel, than let's say this not so really funny LXLE. But now, also the LXDE Mint has issues which the simple Menulibre. Do never install Alacarte on Mint, or, it can only change entires, not make new ones. I did not even find any good menu editor for Linux (Mint) until now, since now two years Mint usage of mine. Also, on my slower, older Lap, I now see, I have to on Linux, try that GMA500 unofficial repo, which gives a 404 not found error when adding the repo correctly. I gotta go with alternative drivers -- Intel says, it only supports GMA500 on Fedora. I tried anyway compiling the debian and other sources from their driver on Mint, Mint is not gonna fall down so easily as in a broken installation, and if so, no prob, I do it from fresh. What is less funny, even, is to see, that Intel cares a u know what about old HW they did. They gotta ... step onward, you know, so could we hear them say or think. But, I bought a lap, and I deserve support of the hardware, as in software-drivers for that hardware. So does every buyer of hardware. I do not need fancy new whatnot, I want to use my old hw. The problem is, that dominating companies are less under pressure than many others. When I read Intel's legal introductory text to that driver, it really reads like one big "user go to h...", in fact: "Intel is not reponsible for the functioning, nor for the efficiency of this software..." and so on. This is not what I expect from any hardware manufacturer that has a duty to give out drivers. I am sure not personallz or even any emotionally upset to the disfavor of Intel. Really not. Seriously. I do not even any dislike intel. And I DO dislike many other big companies. I still like Intel, but this here, this driver story, for a bit older graph hw of intel, ah no, please. And please, I do not subscribe to this site and place here, so please, do not answer to this post.
Dennis wrote on 2018-10-22 20:08:
I have a DN2800MT that I guess has that GMA 500 and Pear OS works on it fine. I am a hardware guy not software so all this 2d 3d stuff I dont know. Also pear comes with firefox 25 but I got 62.0.3 64 bit working on it. I am on this now.