Video acceleration and Poulsbo news

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.

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 - http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/x11-driver-video-psb/ . 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.

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: http://code.google.com/p/gma500/ and their discussion at: http://ubuntuforums.org/showthread.php?p=9259918. Both links and some comments from one of their people are in the comments of your previous entry about this: http://www.happyassassin.net/2010/04/26/poulsbo-packages-for-f12-f13-may-be-incoming/#comments

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.

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 Xpsb.so and then X just stops. " Then I went on and run it from an ssh connection, which reveals that Xpsb.so had a problem to load: X: symbol lookup error: /usr/lib/xorg/modules/drivers/Xpsb.so: undefined symbol: xf86AddModuleInfo The thing is strange, because the psb_drv.so driver is actually patched to include this function (because it was removed from Xorg1.7). See: [root@ao751 ~]# nm /usr/lib/xorg/modules/drivers/psb_drv.so | 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 :)

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...

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

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 psb_drv.so 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 !

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 :/

oh, n/m, I see you mean the libmm that's part of the psb driver.

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!

"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?

Update with regards to RPM pushing?

Some more progress: http://ubuntuforums.org/showpost.php?p=9426418&postcount=1022 "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"

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. =)

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: https://bugs.freedesktop.org/show_bug.cgi?id=28077 (3D/Xv) and http://code.google.com/p/gma500/issues/detail?id=23&can=1 (xrandr rotation). The first applies on xorg, fixing a exa bug, the second on the psb driver.

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

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

Good news, seems Xorg core patch might not be needed after all: http://ubuntuforums.org/showpost.php?p=9441834&postcount=1124

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

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.

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!

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 http://code.google.com/p/gma500/ that he's talking about, but a PPA that Ubuntu users are using...

They've setup a different repo for this experiment. If they commit anything it will be here: https://edge.launchpad.net/~gma500/+archive/fix 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.

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 (=

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: http://ubuntuforums.org/showpost.php?p=9434977&postcount=1111 http://ubuntuforums.org/showpost.php?p=9440623&postcount=1119 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.

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).

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.

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

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.

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: http://pastebin.com/cD5f5Rnc The patch to stop Xv hanging (but which doesn't fix it, unfortunately) is here: http://pastebin.com/rywjC1Ew If any of you guys can fix suspend and X hanging at exit...

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.

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 2.6.33.5-124. But when I startup the computer hangs up (blank screen). Please help me.

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.

@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.

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...

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/libdri.so [ 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/Xpsb.so [ 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.

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.

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.

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.

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.

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. http://ubuntuforums.org/showpost.php?p=9525652&postcount=1303 http://ubuntuforums.org/showpost.php?p=9525976&postcount=1305 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.

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: 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: http://pastebin.com/cD5f5Rnc xv: http://pastebin.com/rywjC1Ew

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.

Adam, I just pushed http://pastebin.com/fQMLx2Ei 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...

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

Yves: Have you looked in the meego repo recently? http://repo.meego.com/MeeGo/builds/trunk/daily/non-oss/repos/source/

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?)

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: http://netbook-remix.archive.canonical.com/updates/pool/public/x/xserver-xorg-video-psb/ 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.

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...

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

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.

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....

It looks like the Meego driver incorporates OpenGL ES 2.0. I'm not sure if that would be enough to run compiz? -Yves

DH: Do you have a link of that article ? -Yves

http://community.edc.intel.com/t5/Software-Tools-Discussions/Xorg-1-7-Support/m-p/2581#M346 Nothing really *conclusive* there... more of a "wouldn't be surprised if..." feeling.

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 psb_dri.so , but then it just apparently isn't used / doesn't work, though I can't find a relevant error in Xorg.0.log.

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 http://forum.compiz.org/viewtopic.php?f=124&t=10402 -Yves

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/Xpsb.so [ 64.787] (II) Module Xpsb: vendor="Tungsten Graphics Inc." [ 66.271] Xpsb - 5.0.1.0046 [ 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.

Well I, for one, can think of much more important things than compiz.... its cute, but not essential. adam: does vaapi work?

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.

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?

management!

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.

Joel Clark @ intel agrees that there are too many drivers planned: http://bugs.meego.com/show_bug.cgi?id=2205 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?

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. http://fpaste.org/O4XH/

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.

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.

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 - 5.0.1.0046 x86/MMX/SSE2 OpenGL version string: 2.0 Mesa 7.4 OpenGL shading language version string: 1.10

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.

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.

adam: I tested for kernel compatibility by adding F13's 2.6.33.5 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 ;)

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"

Duh... the patch got wrongly interpreted as HTML... the new line should be something like: #include &lt exa.h &gt

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.

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.

Hey Adam, you think you could upload srpms for what you have right now on your repo? (http://adamwill.fedorapeople.org/poulsbo/13/SRPMS/) 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.

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.

I'd also appreciate an email of the SRPM, if you'd be so inclined. Thanks! :-)

Adam, can you send me the SRPMs please.

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

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.

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.

I just SAID I'm in the process of uploading it to RPM Fusion. sheesh!

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 http://download1.rpmfusion.org/nonfree/fedora/updates/testing/13/SRPMS/ .

Adam, thank you. Finally I have working the resolution 1366x768 in fc13.