Video acceleration and Poulsbo news

This is quite a quiet time for QA as we’re just sitting around waiting for F13 to come out and writing up some documentation, so I took the opportunity to work on my packaging stuff.

I’ve sent a new navit build to the review request bug, so that may _finally_ make it into the repos soon. On my private repos, some good news, some bad.

The good news – I’ve updated the video-experimental repo with the latest builds of libva, vdpau-video and mplayer-accelerated. I’ve also added the shiny new gstreamer-vaapi. Unfortunately that doesn’t work on my current test system (a laptop with NVIDIA graphics, the proprietary driver, and vdpau-video); mplayer-accelerated works just fine in that setup, but Totem barfs when I try and play any video. I’ll be in touch with Gwenole to see what he thinks about that. It’d be interesting to hear from anyone else who’s playing with these packages whether gstreamer-vaapi works; all you have to do to test it is install it and then try and play a video in totem.

The bad news is on the Poulsbo front. I decided to just say ‘screw it’, updated the Vaio P to Fedora 13, and tried it out with psb, with Olivier’s patches from Mandriva. Unfortunately, it don’t work. The kernel module loads okay, X starts up, it loads and then X just stops. The system’s up, hitting power gives a clean shutdown, but the screen is blank and can’t see even the virtual consoles any more. I’ll try and figure out what the problem is, but it’s looking tricky at the moment.

Since I jumped straight to F13 I actually didn’t get a chance to test F12, so I don’t know whether that works! It’s a bit tricky to set it up so I can test, but if I get the free time I might try.

94 Responses

  1. koukou73gr
    koukou73gr May 24, 2010 at 9:43 am | | Reply


    Ubuntu people seem to have a grasp at it with the 1.7 Xorg though. Is there any recent/official document someplace regarding the building process etc etc for Fedora kernel packages? I am really clueless with regards to this, but since have it working and you don’t have F12 anymore, maybe I could try and have a shot at it.

  2. koukou73gr
    koukou73gr May 24, 2010 at 1:18 pm | | Reply

    I think they’ve gone beyond that… Mandriva’s patches are against 0.31, they are using 0.32.1 and their repository seem more active.

    See: and their discussion at: Both links and some comments from one of their people are in the comments of your previous entry about this:

  3. marcus
    marcus May 25, 2010 at 10:47 am | | Reply

    I’ve been running F12, and since a week F13. using the xorg-x11-server-Xorg package and Poulsbo driver from F11.

    Would be much nicer to have the driver work with newer X-servers, but this works well enough for me for now. With some creative use of yum-priorities I can even do automatic yum updates without any packages breaking.

  4. koukou73gr
    koukou73gr May 27, 2010 at 5:36 am | | Reply

    Ok, I gave it a try and hit what you saw:

    “[…]Unfortunately, it donโ€™t work. The kernel module loads okay, X starts up, it loads and then X just stops. ”

    Then I went on and run it from an ssh connection, which reveals that had a problem to load:

    X: symbol lookup error: /usr/lib/xorg/modules/drivers/ undefined symbol: xf86AddModuleInfo

    The thing is strange, because the driver is actually patched to include this function (because it was removed from Xorg1.7). See:

    [root@ao751 ~]# nm /usr/lib/xorg/modules/drivers/ | grep AddModule
    00005f50 t xf86AddModuleInfo

    After the error X doesn’t hang, it just exits, but leaves the console trashed. The machine is still working though perfectly and accessible through the network, no oops or any other error message is logged.

    I guess this is probably a compilation thing, the symbol is either not exported, or the dynamic linker can’t find it…

    Your expertise would be appreciated ๐Ÿ™‚

  5. koukou73gr
    koukou73gr May 28, 2010 at 3:09 am | | Reply

    Holly cr… I just got a desktop with psb_drv :0
    Details in a few…

  6. koukou73gr
    koukou73gr May 28, 2010 at 4:28 am | | Reply

    Ok, now that my excitement is over, I can write what I did.

    Basically, the culprit was that ‘t’ flag for the symbol in nm output. This indicated a local symbol, not a global (exported) one. Hence the dynamic linker can’t find it. Why is it local? Because the driver was built with -fvisibility=hidden (still…). Olivier I believe said he had removed that option, but in the sources I got + patches, that option was still there. So to cut a long story short, I added

    __attribute__ (( visibility (“default”)))

    in the xf86AddModuleInfo definition in psb_drv.c and rebuild. The resulting had the symbol properly exported now (‘T’ instead of ‘t’).

    Reruning X, revealed one more symbol, mmCreateDRM which was defined in libmm/mm_drm.c . This function was again patched in because it was removed upstream and was “hidden” by the -fvisibility setting as well. Somehow the trick with the __attribute__ didn’t work for this one, but since Olivier said he DID build libmm with -fvisibility=”default” instead, I went promptly and did the same in the libmm makefiles.

    And lo and behold, now X starts prompty and I have a desktop running at lightspeed compared to the VESA driver before ๐Ÿ™‚

    The catches:
    – No XV support (only software render, stretching full screen kills perfomance…)
    – No 3D support broken (eg. desktop icons don’t get rendered)

    In xorg.conf

    Section “Extensions”
    Options “Composite” “Enabled”

    and Option “ShadownFB” “true” in the driver section (this I believe is there ti kill 3D component).

    Most other needed options have been patched into the driver as defaults if I understand correctly. One can browse the relevant thread mentioned above in the Ubuntu forums and pick a complete xorg.conf from jbernardo.

    Hibernation and resume works w/o problem, backlight control works through /sys/classes/backligh and the gnome backlight control applet but not with Fn keys.

    This is on a AO751h with Fedora 12. The only source packages I needed to build were the kernel psb module and the Xorg driver.

    That’s all !

  7. koukou73gr
    koukou73gr May 28, 2010 at 11:52 am | | Reply

    “Itโ€™s neat that you have it working with just the kernel and driver components, though, thatโ€™s actually entirely F/OSS =)”

    I wish :p

    Of course, I have the rest of the stuff installed, only I “borrowed” them from your F11 builds rather than building from source, per your suggestion that they haven’t changed….

    Ubuntu people say 3D is really broken. Also that Compiz requires a GLX extension psb do not support, hence it can never work: they suggest enabling Composite instead. XV and/or vaapi (?) video acceleration, they’re trying for it, but not there yet. Maybe I could look into the latter, but (again) I have no idea where to start ๐Ÿ™ Any pointers?

    Could you please make a push into RPM Fusion for F12 as well?

  8. koukou73gr
    koukou73gr June 7, 2010 at 3:59 am | | Reply

    Update with regards to RPM pushing?

  9. koukou73gr
    koukou73gr June 7, 2010 at 4:11 pm | | Reply

    Some more progress:

    “I found a bug in Xorg 1.7.6 EXA code that prevents our driver to work. After this little fix I have opengl working on Lucid without ShadowFB. Now we need to get this into Lucid or maybe we post our own packages for poulsbo for the time being ?

    Yves De Muyter”

  10. Jose Bernardo
    Jose Bernardo June 8, 2010 at 5:26 am | | Reply

    Well, I was going to give you the news, but it seems koukou beat me to it – 3D is now fixed – there are two patches by Yves de Muyter:
    (xrandr rotation).
    The first applies on xorg, fixing a exa bug, the second on the psb driver.

  11. kdekorte
    kdekorte June 8, 2010 at 7:54 am | | Reply


    Then I hope it pours soon.. Actually having the psb driver in rpmfusion would be very helpful for F13.

  12. kdekorte
    kdekorte June 8, 2010 at 9:09 am | | Reply

    Could someone post step by step instructions for getting the driver to work from source?

  13. koukou73gr
    koukou73gr June 11, 2010 at 2:24 am | | Reply

    Good news, seems Xorg core patch might not be needed after all:

  14. woogie
    woogie June 11, 2010 at 5:19 am | | Reply

    Does it look like there is any hope of getting the Xorg patch into Fedora 13? If not, that seems like it makes it a much bigger effort to maintain the poulsbo drivers in a separate repo

  15. DH
    DH June 11, 2010 at 8:01 am | | Reply

    Looks like the patch has been accepted in X for 1.9 and is to be backported for 1.7 and 1.8 as well.

    So I guess at this point, we just grab all the relevant SRPMs (psb driver components + xserver), chuck in the various patches and modifications, build, install, and call it a day.


  16. koukou73gr
    koukou73gr June 12, 2010 at 4:53 am | | Reply

    They’ve setup a different repo for this experiment.
    If they commit anything it will be here:

    The patch to Xorg core for EXA is essentially this:

    — xorg-server-1.7.6/exa/exa_classic.c.orig 2010-06-08 06:09:48.626645082 +0200
    +++ xorg-server-1.7.6/exa/exa_classic.c 2010-06-08 06:14:23.146669781 +0200
    @@ -247,10 +247,12 @@
    Bool ret;

    + void* old_ptr = pPixmap->devPrivate.ptr;
    if (pExaScr->info->PixmapIsOffscreen) {
    pPixmap->devPrivate.ptr = ExaGetPixmapAddress(pPixmap);
    ret = pExaScr->info->PixmapIsOffscreen(pPixmap);
    – pPixmap->devPrivate.ptr = NULL;
    + pPixmap->devPrivate.ptr = old_ptr;
    } else
    ret = (pExaPixmap->offscreen && pExaPixmap->fb_ptr);

    However, Yves is set to change the Xorg-psb driver to use the EXA_mixed rather than the EXA_classic API (which has been unmaintained and mostly unused… for a long time). When he releases this, the aforementioned Xorg patch is unneeded.

    Adam, maybe you could contact Yves directly to get hold of his latest changes towards EXA_classic.

    ps. Did you changed your hosting after your “crash”? After your site came back accessing it from home is unbearable, while from work is still like normal.

  17. sindikat
    sindikat June 14, 2010 at 12:41 am | | Reply

    Hi, Adam! I’m a user of Asus Eee PC 1201HA, so i also wait for the “Poulsbo” driver in RPM-Fusion repos. I send you my moral support, so that you wouldn’t think your work is useless (=

  18. DH
    DH June 14, 2010 at 7:10 am | | Reply

    Looks to me that he’s trying to actually upgrade the psb driver from using exa_classic to exa_mixed. The whole point of this is that exa_classic is “not really maintained anymore”, which explains the blackscreen bug that was solved by the patch (above) to the xserver.

    The other problems that exist currently are, of course, the crash on shutdown, xv for some applications/machines/???, and starting opengl apps at login time (apparently its fine if after login time…)

    I think we’re all grown up enough to not use xv, crashing on X shutdown is fine, and no need to start opengl apps at login time (who does that?).


    And honestly, I think that its enough now. Intel said something about releasing some new drivers in JULY, so I figure that it really isn’t worth worrying about too much more than “good enough” until after evaluating their new drivers (which may be sufficiently better to just completely forget about these old drivers…)

    Anyways, good news is that the patch HAS been pushed to both 1.8 and 1.9 now.

  19. DH
    DH June 14, 2010 at 8:12 am | | Reply

    The point is that his next patch isn’t needed. The only patch that IS needed is the one that you’ve already de-inverted, which fixes exa_classic to work with the existing psb driver. The next patch he’s talking about is to modify the psb driver to work with exa_mixed instead of exa_classic.

  20. DH
    DH June 14, 2010 at 8:15 am | | Reply

    In other words: don’t waste your time waiting for it.

  21. Jose Bernardo
    Jose Bernardo June 16, 2010 at 6:42 am | | Reply

    Well, I’ve spoken with Yves, and he gave me the go-ahead, with the following caveats:
    “This is preliminary and based on a hack, not very certain it will work.
    It SHOULD be slower than EXA_classic as there is no caching being done on pixmaps in offscreen memory. I’m not so certain
    what impact that might have on Poulsbo chipset though… Things that should go slower is re-use of pixmaps and rendering of glyphs (which is essentially the same).”

    The EXA_Mixed patch is here:
    The patch to stop Xv hanging (but which doesn’t fix it, unfortunately) is here:

    If any of you guys can fix suspend and X hanging at exit…

  22. Jose Bernardo
    Jose Bernardo June 16, 2010 at 8:58 pm | | Reply

    Yves emailed me again, he is testing now a “proper” implementation of “EXA_mixed”, so if you want to wait for the weekend, it will probably be ready by then.

  23. Alberto
    Alberto June 17, 2010 at 3:19 pm | | Reply

    Hello, I have fedora 13 in acer aspire one AO751h.

    I compiled xorg-x11-drv-psb and generated the rpm from the sources of Adam srpms for kernel But when I startup the computer hangs up (blank screen). Please help me.

  24. irv englander
    irv englander June 22, 2010 at 9:09 am | | Reply

    Adam, thank you for all your work til now. You’re wonderful! I had a massive ext4 failure and had to reinstall my entire system on my Acer netbook, Was running F11 and your psb driver worked well. New install is F13, and now I’m stuck I guess; the yum install came back with “nothing to install” so I assume the fsb driver is specific to F11.

    I truly hope that you’ll be able to create a new yum file for F13 in the not too distant future. If it offers any moral support, this netbook is my favorite little computer ever. But it needs the hi-res widescreen display. The vesa driver is limited to 1024×768, period, and I’ve never had any success modifying it.

    Thanks, Adam. You’re the best. I wouldn’t be using this machine so much if it were’;t for your support and great work.

  25. DH
    DH June 22, 2010 at 2:21 pm | | Reply

    There are 4 things you can do to make it work;

    a) (ok option, little crunchy, but sortof works) apply the exa_classic patch listed above to the xserver source, compile, and install,
    b) (second best option) apply the preliminary exa_mixed patchES above to the psb driver,
    c) (easiest, but the very least function) set shadowfb to true in your xorg.conf
    d) (best option) wait for the “final” (ish) exa_mixed patches and for Adam to compile the thing and send it over to rpmfusion.

  26. Jose Bernardo
    Jose Bernardo June 23, 2010 at 7:23 am | | Reply

    Hi Adam,
    Correct, I am still waiting for Yves. As soon as we have it working I’ll notify you guys. The problem is that on our team Yves is the only one with the expertise to pull this through, and he probably also has a job and a life…

  27. Alberto
    Alberto June 23, 2010 at 10:38 am | | Reply

    Thank you DH for answer.

    a) (ok option, little crunchy, but sortof works) apply the exa_classic patch listed above to the xserver source, compile, and install,
    — Looks complicate.

    b) (second best option) apply the preliminary exa_mixed patchES above to the psb driver,
    — I have the xorg-x11-drv-psb-0.31.0-15.fc13.src.rpm. This rpm provide xserver-xorg-video-psb_0.31.0.orig.tar.gz, but for the patches that you mentioned before I need the 0.36.0. Where can I dowload this version?

    c) (easiest, but the very least function) set shadowfb to true in your xorg.conf
    — Not work for me ๐Ÿ™
    In Xorg.0.log:
    [ 33.494] (==) PSB(0): Default visual is TrueColor
    [ 33.494] (**) PSB(0): Option “ShadowFB” “true”
    [ 33.494] (==) PSB(0): Use hardware cursor.
    [ 33.494] (==) PSB(0): Not using ACPI for LVDS detection.
    [ 33.494] (II) Loading sub module “dri”
    [ 33.494] (II) LoadModule: “dri”
    [ 33.495] (II) Reloading /usr/lib/xorg/modules/extensions/
    [ 33.495] (II) PSB(0): Debug: psbPreinitXpsb
    [ 33.495] (II) Loading sub module “Xpsb”
    [ 33.495] (II) LoadModule: “Xpsb”
    [ 33.496] (II) Loading /usr/lib/xorg/modules/drivers/
    [ 33.496] (II) Module Xpsb: vendor=”Tungsten Graphics Inc.”
    [ 33.496] compiled for 1.6.0, module version = 0.1.0

    d) (best option) wait for the โ€œfinalโ€ (ish) exa_mixed patches and for Adam to compile the thing and send it over to rpmfusion.
    I’m desesperate!!! counting days.

  28. DH
    DH June 23, 2010 at 12:01 pm | | Reply

    I must have missed that he built it from your JUST your srpms… in any case, his answer to (a) suggests that (d) is probably his ONLY real option ๐Ÿ˜‰

    @Alberto: if you REALLY THOROUGHLY read everything in this thread (and linked to from this thread) and understand it, then there is definitely enough to make this work. But judging by your answers, you don’t seem to have quite enough experience dealing with source code and patches to work through this. This I base on you saying that applying just the exa_classic patch looks complicated…. that’s really about as easy of a patch as it gets.

    Don’t take this as a put down, just trying to be realistic. In fact, successful or not, I would encourage you to TRY since you’ll at least learn something in the process.

    Note that there are a bunch of different “sets” of patches. The MINIMUM set of patches is needed to make the shadowfb=true option work. On top of that, the exa_classic patch can fix it so you can get rid of the shadowfb. After that (or as an ALTERNATIVE to that), you can go into the preliminary exa_mixed patches — i.e. work through it from the least required to the best available.

  29. Alberto
    Alberto June 24, 2010 at 5:04 am | | Reply

    Thanks DH, I’ll do my best effort to apply the patches. How I said before I apply patches and recompile from srpms (give some credit ;)). But I’m pretty sure in this days I’ll have working the poulsbo driver for fedora 13.

  30. Randy
    Randy June 24, 2010 at 8:46 pm | | Reply

    Hi Adam,

    Just offering more moral support, and hoping that Intel comes through in July. My AO751h has become my ever so portable workhorse. I’d like to get faster scrolling and maybe some video acceleration.

  31. DH
    DH June 29, 2010 at 10:01 am | | Reply

    It doesn’t look too promising that Yves is going to be getting the “better” version of the exa_mixed patch going. He says that the current version is fine to use, but isn’t putting much into it due to the risk of it all being obsoleted the moment that emgd hits meego.

    Seems like this is the time to put something up on rpmfusion. If/when the “better implementation” comes, it is fairly trivial to replace the obsolete patches in the SRPM and rebuild.

  32. Yves De Muyter
    Yves De Muyter June 29, 2010 at 12:11 pm | | Reply

    Did you guys try the patch I sent a couple of weeks ago?
    It should work without patching xorg… Only XV is not working when there is no compositing manager running…


  33. DH
    DH June 30, 2010 at 4:21 pm | | Reply

    The ones you’re looking for were posted just above…

    By Jose Bernardo June 16th, 2010 at 6:42 am
    –there’s a couple of PASTBIN links.


  34. Woogie
    Woogie July 4, 2010 at 11:19 am | | Reply

    I’m glad I’m not the only one who is confused as to what patch is what. If I’m following things right, I should be able to take Adam’s F12 source RPMS, apply some patches from Mandriva, and then apply some patches from Yves, and then have an at least somewhat functional driver. Is that correct? Can anyone point me at the exact patches, because I guess every time I try to figure things out, I get interrupted before I can. I don’t think I will care about poulsbo by the time my unborn child graduates, but it is looking like I won’t have time to figure this out until then.

  35. Jose Bernardo
    Jose Bernardo July 4, 2010 at 12:59 pm | | Reply

    Adam, I just pushed into our ppa, at Yves suggestion.
    @alberto the renumbering of the source to 0.36 was basically a mistake. We (I) do need to clean up our source tree…

  36. Yves De Muyter
    Yves De Muyter July 5, 2010 at 9:15 pm | | Reply

    Does anybody know where our version numbers come from? Is it mandriva that took control over the versions of driver?

    In any case, Xv in non-comp-managed mode is broken and it looks like an xorg/exa problem again. I can’t access the pixmap address because in that ‘direct’ mode the pixmap is ‘pinned’ and that again is because mplayer (and most other apps) tell it to do that. I will have to add code to essentially handle pixmaps ourselves in the driver…

    I wanted to wait before doing that job and see what comes out of meego. But now it looks like Intel doesn’t care about their poulsbo customers… It is a shame, this chip is capable of sooo much more than there is in our current driver (it is basically all pixman sse2 CPU code right now)…


  37. DH
    DH July 6, 2010 at 12:08 pm | | Reply

    Yves: Have you looked in the meego repo recently?

  38. Adam Williamson
    Adam Williamson July 6, 2010 at 12:58 pm | | Reply

    Oh,goody, so now we get a completely proprietary driver from PowerVR, which as a fun bonus includes its own GL libraries?

    That’s MUCH better!

    Excuse me while I go and drink heavily for a few weeks.

    (See pvr-bin.spec if you want a good laugh, or cry, depending on how you react to a company that thinks it’s a great idea to set up library versioning by creating symlinks in the spec file. Where do they *find* these people?)

  39. Adam Williamson
    Adam Williamson July 6, 2010 at 1:03 pm | | Reply

    yves: I version my packages from the versions in the UNR package names. I think in your Ubuntu-community-verse, lucazade starting adding .1s to those version numbers a while back, which confused the hell out of me for a while.

    I work from the repo at:

    which is, as far as I’m aware, the last place Canonical/Dell/Intel/whothehellever kept up to date. The version of the X driver there is 0.32.0, which is the version I use for my package. The revision numbers obviously are my own. I don’t follow Mandriva’s, as we’re not sharing a spec, we just share patches.

Leave a Reply

Your email address will not be published. Required fields are marked *