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.


koukou73gr wrote on 2010-05-24 17:43:
Bummer... 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.
adamw wrote on 2010-05-24 18:01:
I tried F12 a couple of days ago, didn't work either. Not sure why, finding it hard to care; I may just run MDV 2010 on mine. Ubuntu users are probably using the same patches I am, from Mandriva - . You can just grab the .src.rpms from RPM Fusion to work from, if you like. The only changes from what's already there are the additional patches to the X driver packages, which you can find above. The other packages are all unchanged.
koukou73gr wrote on 2010-05-24 21:18:
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:
adamw wrote on 2010-05-25 15:06:
I don't see anything there that's not in MDV. A lot of the changes there are Ubuntu specific housekeeping stuff, to do with the exact way they package things. From the forum discussion it looks like they have things working flakily with no 3D on Ubuntu 10.04, which is no better than what MDV has at present. Possibly I may have libdrm-poulsbo packaged wrong for f12 and f13, but I'm finding it really hard to get the motivation to care right now :/
marcus wrote on 2010-05-25 18:47:
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.
adamw wrote on 2010-05-25 19:18:
yikes, that sounds fragile, but kudos. =) I briefly looked at porting X server 1.6 to F12 when F12 was new, but doing it properly is a giant pain, as all sorts of subsidiary X packages need adjusting.
koukou73gr wrote on 2010-05-27 13:36:
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 :)
adamw wrote on 2010-05-27 15:17:
Thanks for taking the time to look into that for us! I concur with your diagnosis; that's definitely one of the issues Olivier patched for in Mandriva (it was one of the main stumbling blocks). I don't think I have any more expertise than you do here, but I'll ask some X folks if they have any ideas...
koukou73gr wrote on 2010-05-28 11:09:
Holly cr... I just got a desktop with psb_drv :0 Details in a few...
koukou73gr wrote on 2010-05-28 12:28:
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" EndSection 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 !
adamw wrote on 2010-05-28 15:16:
wow, thanks for looking into it. to have any shot at 3D and video playback acceleration you need to rebuild and install the psb-firmware and xpsb-glx packages - they contain the proprietary bits necessary to enable that. It's neat that you have it working with just the kernel and driver components, though, that's actually entirely F/OSS =) i'd be interested if you're able to get 3D with the above packages, and if you notice any instability with longer-term use... I'll try and find some time to push packages with your changes at some point soon. thanks again. I might have trouble getting libmm changed though :/
adamw wrote on 2010-05-28 15:17:
oh, n/m, I see you mean the libmm that's part of the psb driver.
adamw wrote on 2010-05-28 16:09:
ok, I confirm much the same result here - the driver works with -fvisbility=default whacked into the spec, on F13 (yay). Without shadowfb enabled X crashes as soon as I get to the desktop (boo), I'm guessing because it tries to start compiz and fails massively. With shadowfb enabled - which indeed seems to have the side-effect of disabling 3D - I get a desktop (yay). I'll talk to blino about the 3D stuff... thanks for the investigation!
koukou73gr wrote on 2010-05-28 19:52:
"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?
koukou73gr wrote on 2010-06-07 11:59:
Update with regards to RPM pushing?
koukou73gr wrote on 2010-06-08 00:11:
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"
adamw wrote on 2010-06-08 01:15:
thanks for all the info, folks. i'm finding it hard to work up the old caring muscles for poulsbo any more, especially when it's 20 degrees and sunny outside, but i'll really try to find some time to fix up the packages and update rpm fusion. possibly when it's raining. =)
Jose Bernardo wrote on 2010-06-08 13:26:
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: (3D/Xv) and (xrandr rotation). The first applies on xorg, fixing a exa bug, the second on the psb driver.
kdekorte wrote on 2010-06-08 15:54:
Adam, Then I hope it pours soon.. Actually having the psb driver in rpmfusion would be very helpful for F13.
adamw wrote on 2010-06-08 16:00:
right. if it can actually work with 3D and video acceleration it's probably worth getting off my butt and doing. not sure if I can get the X devs to put the X fix in though. =) let me go bug ajax about it.
kdekorte wrote on 2010-06-08 17:09:
Could someone post step by step instructions for getting the driver to work from source?
koukou73gr wrote on 2010-06-11 10:24:
Good news, seems Xorg core patch might not be needed after all:
woogie wrote on 2010-06-11 13:19:
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
DH wrote on 2010-06-11 16:01:
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. Excellent.
adamw wrote on 2010-06-11 17:34:
yeah, you can do that if you like. it's best (and also easiest) to rebuild in mock, but to do so involves a bit of twiddling as you have to set up a private repo for the packages which depend on OTHER packages in the set to build (since the other package that you just built obviously isn't available in a public repo). having to do that to test the damn thing is one reason why I get lazy about this =) I'll try to find the EXA patch discussed in Yves' post linked above (thanks, koukou) and throw that at it. Honest, I will. I just booted up the P again! That's twice this month!
adamw wrote on 2010-06-11 17:40:
reading through a bit further, looks like yves wants to fix a crash on X shutdown before publishing his exa patch. I'd take it without that. who the hell shuts down X anyway? heh. where does yves' stuff go, anyway? It doesn't seem to be the stuff at that he's talking about, but a PPA that Ubuntu users are using...
koukou73gr wrote on 2010-06-12 12:53:
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 @@ ExaPixmapPriv(pPixmap); 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.
adamw wrote on 2010-06-12 16:10:
yes, I know what the core patch is, if you look at the bug I actually submitted a reformatted version of it. =) it was the exa_mixed change that I was talking about. No, I haven't changed my hosting. The site's hosted off my home internet connection, which seems to get far far slower at evenings and on weekends (PST); I think my ISP is under-provisioned for the load when everyone's home from work. So yeah, I'm not surprised you see slow responses at some times, there's nothing I can do about it (besides switching to external hosting, which I'm not inclined to do, it costs too much and I like running my own boxes :>)
sindikat wrote on 2010-06-14 08:41:
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 (=
DH wrote on 2010-06-14 15:10:
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?). References: 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.
adamw wrote on 2010-06-14 15:24:
DH: I'm not sure why you say 'actually', we already discussed that - see koukou73gr's last post above. I dunno why you're discussing the merits of releasing his work so far here, because I'm not him and AFAIK, Yves isn't reading this. So it's not doing much good. =) All I'm doing is sitting here waiting for Yves to publish his patch (it may have happened in the last day or two, actually, I didn't check since Friday).
DH wrote on 2010-06-14 16:12:
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.
DH wrote on 2010-06-14 16:15:
In other words: don't waste your time waiting for it.
adamw wrote on 2010-06-14 16:19:
it's actually easier for me to wait for that patch, because that one applies to the psb driver, which I maintain. The first patch applies to the X server, which I don't maintain and have no commit access to. All I can do is wait for the X team to push an update which happens to include that patch. I'm expecting the exa_mixed patch to be available before that happens.
Jose Bernardo wrote on 2010-06-16 14:42:
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...
Jose Bernardo wrote on 2010-06-17 04:58:
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.
adamw wrote on 2010-06-22 17:18:
ienglander: I'm waiting on the exa-mixed patch discussed in the above comments. jose: I still don't see the final version of the patch in the thread or the ppa, it's not available yet right?
Alberto wrote on 2010-06-17 23:19:
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.
irv englander wrote on 2010-06-22 17:09:
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 1024x768, 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.
DH wrote on 2010-06-22 22:21:
@Alberto: There are 4 things you can do to make it work; Either: 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.
Jose Bernardo wrote on 2010-06-23 15:23:
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...
Alberto wrote on 2010-06-23 18:38:
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.
adamw wrote on 2010-06-23 19:26:
dh: if alberto's just working with the stuff currently on RPM Fusion just those changes won't be enough, because I haven't yet uploaded builds with the blino patches needed to make the thing fly on X server 1.7+ at all. you'd also have to add those patches before anything will go.
DH wrote on 2010-06-23 20:01:
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.
Alberto wrote on 2010-06-24 13:04:
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.
Randy wrote on 2010-06-25 04:46:
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.
DH wrote on 2010-06-29 18:01:
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.
Yves De Muyter wrote on 2010-06-29 20:11:
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... -Yves
adamw wrote on 2010-06-29 20:48:
hey, yves. which one was that? I'm losing track. =) basically I want a patch which makes everything work without needing to patch X (as I sure as hell am not shipping an alternate X server package). If 3D and video playback acceleration work I don't care much about Xv.
DH wrote on 2010-07-01 00:21:
@adamw: 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. exa_mixed: xv:
Woogie wrote on 2010-07-04 19:19:
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.
Jose Bernardo wrote on 2010-07-04 20:59:
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...
Yves De Muyter wrote on 2010-07-06 05:15:
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)... -Yves
DH wrote on 2010-07-06 20:08:
Yves: Have you looked in the meego repo recently?
Adam Williamson wrote on 2010-07-06 20:58:
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?)
Adam Williamson wrote on 2010-07-06 21:03:
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.
adamw wrote on 2010-07-07 08:05:
dh: yves: the build actually fails for me with the mixed patch: psb_accel.c:1324: error: 'EXA_HANDLES_PIXMAPS' undeclared (first use in this function) psb_accel.c:1324: error: (Each undeclared identifier is reported only once psb_accel.c:1324: error: for each function it appears in.) psb_accel.c:1324: error: 'EXA_MIXED_PIXMAPS' undeclared (first use in this function) psb_accel.c:1340: error: 'struct _ExaDriver' has no member named 'CreatePixmap' psb_accel.c:1341: error: 'struct _ExaDriver' has no member named 'CreatePixmap2' psb_accel.c:1342: error: 'struct _ExaDriver' has no member named 'DestroyPixmap' seems weird. I have the exact same version of the patch you guys have in your ppa. Can't really figure out a reason why offhand. However, F13 has just got X server 1.8.2, which I think has the server-side fix. So now it probably works even without the mixed patch. I'll check that. Won't help F12, though...
Yves De Muyter wrote on 2010-07-07 08:59:
What version of xorg is this? This here is 1.7.6 and it is defined here: user@tabletpc:/usr/include$ grep -ir exa_handles_pixmaps * xorg/exa.h: * EXA_HANDLES_PIXMAPS indicates to EXA that the driver can handle xorg/exa.h:#define EXA_HANDLES_PIXMAPS (1 << 3) user@tabletpc:/usr/include$ I'm going to try the powervr (pvr) driver this weekend and see how it performs. It looks like it is split up into a lot of different libraries now. -Yves
DH wrote on 2010-07-07 12:36:
I will confirm that the F13 xserver now has the exa_classic fix included, but the F12 xserver does NOT. Note however, that F12 has xserver 1.7.6, which matches the version Yves is working with.... so the exa_mixed patch might work for F12 where it isn't *as* needed for F13.
DH wrote on 2010-07-07 12:44:
Also note (esp Yves): I read from Intel's forums (an intel rep) that they weren't bothering with xserver 1.7 support since moblin/meego skipped that and went straight from 1.6->1.8. I therefore would NOT be surprised if the meego blobs fail miserably if you try with 1.7. They should (hopefully) *just work* with F13 (or other distro with 1.8... is there such?), otherwise there obviously isn't a whole lot we can do about it anyway save for running meego.... And don't forget the kernel bits....
Yves De Muyter wrote on 2010-07-07 12:50:
It looks like the Meego driver incorporates OpenGL ES 2.0. I'm not sure if that would be enough to run compiz? -Yves
Yves De Muyter wrote on 2010-07-07 12:57:
DH: Do you have a link of that article ? -Yves
DH wrote on 2010-07-07 14:57: Nothing really *conclusive* there... more of a "wouldn't be surprised if..." feeling.
adamw wrote on 2010-07-07 15:36:
yves: yeah, it's defined in exa.h in 1.8 as well. Which is why I said I couldn't see why it fails. I'll take another look at it today. I found that it does indeed work without ShadowFB "true" in F13 now, but 3D still doesn't work; it shows Mesa software rasterizer as the renderer, glxgears runs 50fps, and compiz won't run. Not sure what's going on with that, either. The Xorg.0.log seems to show it loading , but then it just apparently isn't used / doesn't work, though I can't find a relevant error in Xorg.0.log.
Yves De Muyter wrote on 2010-07-07 16:39:
You should get some Xpsb initialization message in xorg.0.log compiz doesn't run on us too, it complaints about not having OpenGL 1.3 (the binary blob is only 1.2). I can't remember the real complaint but a certain function is missing, something I wanted to experiment on when I have time (adding the function and mapping to another as there is a nearly identical function available, only slightly different name and 1 extra argument) It also looks like compiz won't like the meego driver too, see -Yves
adamw wrote on 2010-07-07 16:47:
yup, get that: [ 64.782] (II) PSB(0): Debug: psbPreinitXpsb [ 64.782] (II) Loading sub module "Xpsb" [ 64.782] (II) LoadModule: "Xpsb" [ 64.787] (II) Loading /usr/lib/xorg/modules/drivers/ [ 64.787] (II) Module Xpsb: vendor="Tungsten Graphics Inc." [ 66.271] Xpsb - [ 66.469] (II) PSB(0): [Xpsb] Disable hog plug daemon in PSB driver. [ 66.470] (II) PSB(0): [Xpsb] Started kernel request thread. [ 66.470] (II) PSB(0): Xpsb extension for 3D engine acceleration enabled. yeah, compiz fail was a particular GL function not being available, EXT_TEXTURE_FROM_PIXMAP I think.
DH wrote on 2010-07-07 16:57:
Well I, for one, can think of much more important things than compiz.... its cute, but not essential. adam: does vaapi work?
adamw wrote on 2010-07-07 17:10:
I like compiz because on the P, at least, it actually performs better than metacity, with the 3D acceleration. dunno about vaapi, didn't test it properly yet.
DH wrote on 2010-07-07 17:50:
Interesting thing... those blobs in the meego repo are apparently a totally separate driver written for what is apparently the same hardware. EMGD is still supposed to be coming soon.... Gotta wonder who thought up this brilliant waste of resources?
adamw wrote on 2010-07-07 18:03:
adamw wrote on 2010-07-07 18:48:
no go on libva either. [adamw@vaio ~]$ vainfo libva: libva version 0.31.1-sds1 libva: va_getDriverName() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit it's like the xpsb-glx stuff just isn't being used at all, even though it's in the right places, worked fine with f11, and X log claims it's being loaded. rather odd.
DH wrote on 2010-07-07 19:18:
Joel Clark @ intel agrees that there are too many drivers planned: That's an interesting error.... described as "unknown" certainly isn't promising.... Has anything major changed in the kernel that could upset this process? Does the kernel spit out anything? What does your xorg.conf look like? You couldn't have accidentally set shadowfb to true...? What does your xorg log look like?
adamw wrote on 2010-07-07 19:53:
dh: I'm hardly a kernel hacker, but the module builds and loads and doesn't appear to complain about much. I get some tracebacks of this form in /var/log/messages: Jul 6 11:52:43 vaio kernel: [] ? intel_lvds_set_power+0x58/0xad [psb] Jul 6 11:52:43 vaio kernel: [] ? intel_lvds_commit+0x37/0x3e [psb] Jul 6 11:52:43 vaio kernel: [] ? drm_crtc_set_mode+0x2ae/0x342 [drm_psb] Jul 6 11:52:43 vaio kernel: [] ? psbfb_set_par+0x1b7/0x1d7 [psb] Jul 6 11:52:43 vaio kernel: [] intel_lvds_set_power+0x58/0xad [psb] Jul 6 11:52:43 vaio kernel: [] intel_lvds_commit+0x37/0x3e [psb] Jul 6 11:52:43 vaio kernel: [] drm_crtc_set_mode+0x2ae/0x342 [drm_psb] Jul 6 11:52:43 vaio kernel: [] psbfb_set_par+0x1b7/0x1d7 [psb] not entirely sure what those are about. Don't remember whether they happened with F11. No, I haven't accidentally set shadowfb to true. I had it set to true before, to make it work. I commented that line out to do this test in the first place. Xorg.0.log is very dull. No significant errors or warnings in it. That's mainly why I'm baffled.
DH wrote on 2010-07-07 20:14:
You're right, it does look pretty dull. And everything appears to be working. As for those kernel messages... in F12 mixed in an ungodly mess with F11's xserver, I get those (or something like them) puked out all over the console. Doesn't seem to affect anything though. I'll check that out later. I might also try out an F13 kernel on F12 -- see what happens.
DH wrote on 2010-07-07 20:18:
Actually, now that I think of it, I'm not even sure if vaapi even works on mine the way I have it.... I was more concerned about getting the touchscreen working and don't think I even tried. Its an Asus T91-MT and the touchscreen drivers I have working with F12 are a little pre-alpha-ish. Better ones available for F13, but then there was always the PSB problem.
Yves De Muyter wrote on 2010-07-08 05:47:
Do you have everything in xorg.conf that is needed? I needed to add Section "DRI" Mode 0666 EndSection And this is my full xorg.conf file: Section "DRI" Mode 0666 EndSection Section "Extensions" Option "Composite" "On" Option "RENDER" "Enable" EndSection Section "Device" Identifier "Configured Video Device" Driver "psb" # Option "ShadowFB" "true" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" # Option "BackingStore" "true" # Option "XAANoOffscreenPixmaps" EndSection Somewhere in the middle of glxinfo there is this: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) GMA500 20081116 - x86/MMX/SSE2 OpenGL version string: 2.0 Mesa 7.4 OpenGL shading language version string: 1.10
adamw wrote on 2010-07-08 06:19:
I'm using the same one that worked fine in F11. Never needed that DRI section before but I can try it, I guess. It already uses EXA, you can see that from the X log.
Jose Bernardo wrote on 2010-07-08 08:47:
Well, we have vaapi working here. Of course, that with 3D enabled (ShadowFB “false”), with the exa_mixed patch. Still some crashes with mplayer-vaapi and subtitles, but one user found out these are solved if you tell mplayer-vaapi to rescale to a size that is a multiple of 16, both horizontally and vertically. I haven't had the time to test it yet.
DH wrote on 2010-07-08 12:17:
adam: I tested for kernel compatibility by adding F13's into the unholy mix and turning it into a crime against everything that's good. It can be ruled out since everything is still working perfect with it. (recap: F12 w/xserver1.6 from F11, and kernel from F13) If you don't get this figured out by this weekend, I'm going to try pulling in F12's and then F13's xserver and see what happens. If you do figure it out by then, I'm going to wipe the thing blank and install F13 normal ;)
Eric Piel wrote on 2010-07-09 13:56:
Adam, Concerning the compilation failure with EXA_HANDLES_PIXMAPS, I think it's because the driver uses it's own exa.h . The following patch fixes it by using the system version (and then you can remove the whole exa directory. --- xserver-xorg-video-psb-0.32.0.orig/src/psb_accel.h 2009-05-12 03:37:53.000000000 +0200 +++ xserver-xorg-video-psb-0.32.0/src/psb_accel.h 2010-06-12 12:49:41.020383532 +0200 @@ -35,7 +35,7 @@ #define _PSB_ACCEL_H_ #include -#include "../exa/exa.h" +#include #include "psb_buffers.h" #include "Xpsb.h"
Eric Piel wrote on 2010-07-09 13:57:
Duh... the patch got wrongly interpreted as HTML... the new line should be something like: #include &lt exa.h &gt
DH wrote on 2010-07-09 18:34:
Oh man, we're right in the middle of patch hell here. Eric: did you look at this academically? or are you also testing on psb hardware? Did you manage to get GL working? I notice that you are making changes based on Adam's most recent source rpm's, which in this case *does not* match the code that is in the google code project, which include the change that you have shown. I think we're in MAJOR need of some synchronization.... I have a feeling that all we need to do is pull in r73 from the google code site and it might... just work.
adamw wrote on 2010-07-12 18:14:
dh: except that the Google code site stuff is heavily Debian-ish, it doesn't apply any changes to the actual psb code, it just contains a debian/patches directory full of patches. I've just tried another build with the EXA mixed patch, also replaced the xf86AddModuleInfo.patch with the stubs.patch from Google Code which adds one other, mesa-related stub. That build works fine, but is the same as before - no 3D, no vaapi. Still can't figure out why. AFAICT, I have every patch from the Google Code repo in my build now. Here's all the patches I'm carrying, for the record: libdrm.patch ignoreacpi.patch xserver17.patch disable_lid_timer.patch loader.patch comment_unused.patch assert.patch stubs.patch exa_header.patch (for the #include Eric noticed) mixed.patch Oh, I'm missing that xv fix patch, but that's all.
DH wrote on 2010-07-13 11:24:
Hey Adam, you think you could upload srpms for what you have right now on your repo? ( I've managed to push my ugly mess into the grave and am having a hard time even getting it to compile with xserver 1.8, and what you have up right now are a little bit ancient. 2D-only is better than vesa ;) Thanks.
adamw wrote on 2010-07-13 14:53:
no, I don't publish anything there any more, that's why they're ancient. The Fusion packages superseded them. I'll email you my current SRPM, though.
Isaac Fischer wrote on 2010-07-13 19:45:
I'd also appreciate an email of the SRPM, if you'd be so inclined. Thanks! :-)
Alberto wrote on 2010-07-14 01:39:
Adam, can you send me the SRPMs please.
Yves De Muyter wrote on 2010-07-14 06:16:
Do you guys have a debugtrace of why it doesn't work ? I've never tested it on 1.8 though, since ubuntu 10.04 is only 1.7.6 ... Also, the bug in xorg should be fixed in the latest 1.8 because they accepted my patch. They were unwilling to put it in 1.7 since they don't support that release anymore... -Yves
adamw wrote on 2010-07-14 06:25:
"Do you guys have a debugtrace of why it doesn’t work ?" Not yet, no. "Also, the bug in xorg should be fixed in the latest 1.8 because they accepted my patch." Yes. It is. I already mentioned that, earlier. And no, I am not going to spend my days emailing SRPMs around the universe, I mailed it to DH because he's actually helping to fix stuff. I'm uploading the current state of things to RPM Fusion, but the buildsystem appears to be stuck, so I don't know how long that's going to take.
Alberto wrote on 2010-07-14 13:03:
Adam, can you upload the files in some link with the SRPMs?. You will help a lot of people (see your estadistics of this blog), we are waiting for this drivers with fedora 13.
Randy wrote on 2010-07-14 16:27:
Adam et al. thanks for taking this on, it makes my head spin just reading the comments. It looks like good progress is being made.
adamw wrote on 2010-07-14 17:19:
I just SAID I'm in the process of uploading it to RPM Fusion. sheesh!
adamw wrote on 2010-07-19 16:54:
Okay, the F13 packages are now in RPM Fusion non-free updates-testing. You should be able to just enable that repo and do 'yum install xorg-x11-drv-psb' to get the driver going. Still only works for 2D, for me anyway - I get no 3D and no vaapi, and can't figure out why. If anyone wants to help, SRPMs you can find at .
Alberto wrote on 2010-07-21 12:25:
Adam, thank you. Finally I have working the resolution 1366x768 in fc13.