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

  1. Yves De Muyter
    Yves De Muyter July 7, 2010 at 12:59 am | | Reply

    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

  2. DH
    DH July 7, 2010 at 4:36 am | | Reply

    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.

  3. DH
    DH July 7, 2010 at 4:44 am | | Reply

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

  4. Yves De Muyter
    Yves De Muyter July 7, 2010 at 4:50 am | | Reply

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

    -Yves

  5. Yves De Muyter
    Yves De Muyter July 7, 2010 at 4:57 am | | Reply

    DH: Do you have a link of that article ?

    -Yves

  6. DH
    DH July 7, 2010 at 6:57 am | | Reply

    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.

  7. Yves De Muyter
    Yves De Muyter July 7, 2010 at 8:39 am | | Reply

    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

  8. DH
    DH July 7, 2010 at 8:57 am | | Reply

    Well I, for one, can think of much more important things than compiz…. its cute, but not essential.

    adam: does vaapi work?

  9. DH
    DH July 7, 2010 at 9:50 am | | Reply

    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?

  10. DH
    DH July 7, 2010 at 11:18 am | | Reply

    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?

  11. DH
    DH July 7, 2010 at 12:14 pm | | Reply

    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.

  12. DH
    DH July 7, 2010 at 12:18 pm | | Reply

    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.

  13. Yves De Muyter
    Yves De Muyter July 7, 2010 at 9:47 pm | | Reply

    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

  14. Jose Bernardo
    Jose Bernardo July 8, 2010 at 12:47 am | | Reply

    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.

  15. DH
    DH July 8, 2010 at 4:17 am | | Reply

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

  16. Eric Piel
    Eric Piel July 9, 2010 at 5:56 am | | Reply

    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”

  17. Eric Piel
    Eric Piel July 9, 2010 at 5:57 am | | Reply

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

  18. DH
    DH July 9, 2010 at 10:34 am | | Reply

    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.

  19. DH
    DH July 13, 2010 at 3:24 am | | Reply

    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.

  20. Isaac Fischer
    Isaac Fischer July 13, 2010 at 11:45 am | | Reply

    I’d also appreciate an email of the SRPM, if you’d be so inclined.

    Thanks! :-)

  21. Alberto
    Alberto July 13, 2010 at 5:39 pm | | Reply

    Adam, can you send me the SRPMs please.

  22. Yves De Muyter
    Yves De Muyter July 13, 2010 at 10:16 pm | | Reply

    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

  23. Alberto
    Alberto July 14, 2010 at 5:03 am | | Reply

    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.

  24. Randy
    Randy July 14, 2010 at 8:27 am | | Reply

    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.

  25. Alberto
    Alberto July 21, 2010 at 4:25 am | | Reply

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

You can comment without reCAPTCHA by using an OpenID as the URL, or logging in with an OpenID or an old site account.

Leave a Reply