May 21st, 2010
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 Xpsb.so 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 to “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.
By koukou73gr May 24th, 2010 at 9:43 am
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.
By adamw May 24th, 2010 at 10:01 am
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
By koukou73gr May 24th, 2010 at 1:18 pm
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 :/
By adamw May 25th, 2010 at 7:06 am
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.
By marcus May 25th, 2010 at 10:47 am
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.
By adamw May 25th, 2010 at 11:18 am
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
By koukou73gr May 27th, 2010 at 5:36 am
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…
By adamw May 27th, 2010 at 7:17 am
Holly cr… I just got a desktop with psb_drv :0
Details in a few…
By koukou73gr May 28th, 2010 at 3:09 am
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 !
By koukou73gr May 28th, 2010 at 4:28 am
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 :/
By adamw May 28th, 2010 at 7:16 am
oh, n/m, I see you mean the libmm that’s part of the psb driver.
By adamw May 28th, 2010 at 7:17 am
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!
By adamw May 28th, 2010 at 8:09 am
“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?
By koukou73gr May 28th, 2010 at 11:52 am
Update with regards to RPM pushing?
By koukou73gr June 7th, 2010 at 3:59 am
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”
By koukou73gr June 7th, 2010 at 4:11 pm
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. =)
By adamw June 7th, 2010 at 5:15 pm
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.
By Jose Bernardo June 8th, 2010 at 5:26 am
Adam,
Then I hope it pours soon.. Actually having the psb driver in rpmfusion would be very helpful for F13.
By kdekorte June 8th, 2010 at 7:54 am
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.
By adamw June 8th, 2010 at 8:00 am
Could someone post step by step instructions for getting the driver to work from source?
By kdekorte June 8th, 2010 at 9:09 am
Good news, seems Xorg core patch might not be needed after all: http://ubuntuforums.org/showpost.php?p=9441834&postcount=1124
By koukou73gr June 11th, 2010 at 2:24 am
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
By woogie June 11th, 2010 at 5:19 am
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.
By DH June 11th, 2010 at 8:01 am
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!
By adamw June 11th, 2010 at 9:34 am
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…
By adamw June 11th, 2010 at 9:40 am
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.
By koukou73gr June 12th, 2010 at 4:53 am
yes, I know what the X.org 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 :>)
By adamw June 12th, 2010 at 8:10 am
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 (=
By sindikat June 14th, 2010 at 12:41 am
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.
By DH June 14th, 2010 at 7:10 am
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).
By adamw June 14th, 2010 at 7:24 am
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.
By DH June 14th, 2010 at 8:12 am
In other words: don’t waste your time waiting for it.
By DH June 14th, 2010 at 8:15 am
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.
By adamw June 14th, 2010 at 8:19 am
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…
By Jose Bernardo June 16th, 2010 at 6:42 am
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.
By Jose Bernardo June 16th, 2010 at 8:58 pm
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.
By Alberto June 17th, 2010 at 3:19 pm
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.
By irv englander June 22nd, 2010 at 9:09 am
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?
By adamw June 22nd, 2010 at 9:18 am
@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.
By DH June 22nd, 2010 at 2:21 pm
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…
By Jose Bernardo June 23rd, 2010 at 7:23 am
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.
By Alberto June 23rd, 2010 at 10:38 am
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.
By adamw June 23rd, 2010 at 11:26 am
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.
By DH June 23rd, 2010 at 12:01 pm
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.
By Alberto June 24th, 2010 at 5:04 am
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.
By Randy June 24th, 2010 at 8:46 pm
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.
By DH June 29th, 2010 at 10:01 am
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
By Yves De Muyter June 29th, 2010 at 12:11 pm
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.
By adamw June 29th, 2010 at 12:48 pm
@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
By DH June 30th, 2010 at 4:21 pm
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.
By Woogie July 4th, 2010 at 11:19 am
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…
By Jose Bernardo July 4th, 2010 at 12:59 pm
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
By Yves De Muyter July 5th, 2010 at 9:15 pm
Yves: Have you looked in the meego repo recently?
http://repo.meego.com/MeeGo/builds/trunk/daily/non-oss/repos/source/
By DH July 6th, 2010 at 12:08 pm
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?)
By Adam Williamson July 6th, 2010 at 12:58 pm
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.
By Adam Williamson July 6th, 2010 at 1:03 pm
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…
By adamw July 7th, 2010 at 12:05 am
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
By Yves De Muyter July 7th, 2010 at 12:59 am
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.
By DH July 7th, 2010 at 4:36 am
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….
By DH July 7th, 2010 at 4:44 am
It looks like the Meego driver incorporates OpenGL ES 2.0. I’m not sure if that would be enough to run compiz?
-Yves
By Yves De Muyter July 7th, 2010 at 4:50 am
DH: Do you have a link of that article ?
-Yves
By Yves De Muyter July 7th, 2010 at 4:57 am
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.
By DH July 7th, 2010 at 6:57 am
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.
By adamw July 7th, 2010 at 7:36 am
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
By Yves De Muyter July 7th, 2010 at 8:39 am
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.
By adamw July 7th, 2010 at 8:47 am
Well I, for one, can think of much more important things than compiz…. its cute, but not essential.
adam: does vaapi work?
By DH July 7th, 2010 at 8:57 am
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.
By adamw July 7th, 2010 at 9:10 am
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?
By DH July 7th, 2010 at 9:50 am
management!
By adamw July 7th, 2010 at 10:03 am
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.
By adamw July 7th, 2010 at 10:48 am
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?
By DH July 7th, 2010 at 11:18 am
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+0×58/0xad [psb]] ? intel_lvds_commit+0×37/0x3e [psb]] ? drm_crtc_set_mode+0x2ae/0×342 [drm_psb]] ? psbfb_set_par+0x1b7/0x1d7 [psb]] intel_lvds_set_power+0×58/0xad [psb]] intel_lvds_commit+0×37/0x3e [psb]] drm_crtc_set_mode+0x2ae/0×342 [drm_psb]] psbfb_set_par+0x1b7/0x1d7 [psb]
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
Jul 6 11:52:43 vaio kernel: [
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/
By adamw July 7th, 2010 at 11:53 am
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.
By DH July 7th, 2010 at 12:14 pm
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.
By DH July 7th, 2010 at 12:18 pm
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
By Yves De Muyter July 7th, 2010 at 9:47 pm
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.
By adamw July 7th, 2010 at 10:19 pm
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.
By Jose Bernardo July 8th, 2010 at 12:47 am
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
By DH July 8th, 2010 at 4:17 am
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”
By Eric Piel July 9th, 2010 at 5:56 am
Duh… the patch got wrongly interpreted as HTML…
the new line should be something like:
#include < exa.h >
By Eric Piel July 9th, 2010 at 5:57 am
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.
By DH July 9th, 2010 at 10:34 am
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.
By adamw July 12th, 2010 at 10:14 am
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.
By DH July 13th, 2010 at 3:24 am
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.
By adamw July 13th, 2010 at 6:53 am
I’d also appreciate an email of the SRPM, if you’d be so inclined.
Thanks!
By Isaac Fischer July 13th, 2010 at 11:45 am
Adam, can you send me the SRPMs please.
By Alberto July 13th, 2010 at 5:39 pm
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
By Yves De Muyter July 13th, 2010 at 10:16 pm
“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.
By adamw July 13th, 2010 at 10:25 pm
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.
By Alberto July 14th, 2010 at 5:03 am
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.
By Randy July 14th, 2010 at 8:27 am
I just SAID I’m in the process of uploading it to RPM Fusion. sheesh!
By adamw July 14th, 2010 at 9:19 am
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/ .
By adamw July 19th, 2010 at 8:54 am
Adam, thank you. Finally I have working the resolution 1366×768 in fc13.
By Alberto July 21st, 2010 at 4:25 am