Le 14/06/2012 07:02, Davide Cavalca a écrit :if you do a clone (from scratch) then build for example i386 config then switch to arm,
Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:
Hello,
I installed the near-latest (yesterday) trunk on two systems - one
Pandaboard and one Pandaboard ES. Here are the build command lines :
$ make geexbox-xbmc-omap4-pandaboard_defconfig
$ make
(faced the known make-3.81 issue, copy the correct tarball in the make
source directory, et restart make)
What's the known make issue?
you've got an error for make , script get doesn't dowload the package
same for kernel
Tom
Davide
Il 2012-06-13 23:54 Nikolay Nikolaev ha scritto:
Le 14/06/2012 07:02, Davide Cavalca a écrit :
What's the known make issue?
if you do a clone (from scratch) then build for example i386
config then switch to arm,
you've got an error for make , script get doesn't dowload the
package
same for kernel
I have described the issue before, it's basically this:
Once a file is downloaded, it's "meta" is copied in
.stamps/$package/get (look scripts/get for reference)
"cp -p $PACKAGES/$1/meta $STAMP"
Now when the package has a flavor or device specific "meta" this is
wrong.
I have proposed a patch which was discarded at the time.
Ah, I see what you mean now; yes, this is indeed a bug. Could you please repost your patch?
Agree, we can probably get rid of the make overlay for omap4.
The story for panda is like that:
- we switched to make 3.82, which has known backward compatibility
issues
- we applied all the patches we found that can help us overcome this
issues
- for XBMC, make 3.82 still causes problems
- Tom added make 3.81 for panda
- once you issue "make geexbox....panda_defconfig" in order to build
the kconfig-frontends the "make 3.82" is downlaoded and compiled
- then when "make" starts to build the panda binaries - "script/get"
checks that there's already .stamps/make/get and does not download
"make 3.81"
- unpack for package 'make' fails since there is now "make
3.81.tar.gz"
- the solution is at this stage to manually download 3.81 sources an
put them in sources/make/ or to rm .stamps/make/get
A long term solution is:
- xbmc currently is build with -j2 (enforced)
- for my arm based snowball i build it safely with make 3.82
- I think we can safely remove make 3.81 package from panda's folder
Are there any side effects to setting fullscreen?
I've seen this as well, it looks like some issue with EDID. Can
you try running xrandr by hand and forcing a resolution?
set fullscreen to true in advancedsettings.xml
Tom, I removed this thing - will have to push it back
Davide
Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:
> Hello,
>
> I installed the near-latest (yesterday) trunk on two systems - one
> Pandaboard and one Pandaboard ES. Here are the build command lines :
>
> $ make geexbox-xbmc-omap4-pandaboard_defconfig
> $ make
>
> (faced the known make-3.81 issue, copy the correct tarball in the
> make
> source directory, et restart make)
What's the known make issue?
> Compilation went ok. I noticed that the know problem with gstreamer
> has been "corrected" by not building gstreamer at all.
> Install went ok (copy boot/* on a VFAT, and the tar.gz content on an
> ext4 FS on a Sandisk Extreme SD/HC (advertised bandwidth: 30MB/s)).
Bandwidth is irrelevant, as SD card access on panda is awfully slow.
I'd recommend using USB if you need fast storage.
> Boot went ok (I'm also facing some sound-related issue, but that's
> not
> the subject here.)
>
> The problem I'm trying to solve is related to video playback: playing
> an full HD h.264 video is painfully slow, with around 2 to 4 frames
> per second. I face a similar issue when I try to play videos that
> come
> from the web (I installed the Funny or Die video addon). On web
> videos
> at least, I probably hit a fillrate related issue - as playing the
> video in 640x480 on the pandaboard is acceptable(*).
>
> Has anyone ever seen these symptoms ? I suspect that this is related
> to the fact that the video rendering is not hw accelerated but
> instead
> is decoded to a buffer and later sent to the video subsystem. I might
> be wrong on that as I have limited time to insestigate the issue.
> gstreamer might help here (that would require a fix for the
> omap4/gstreamer).
You are correct: video is being software decoded, hence slow. Making
the hardware decoding work entails:
- making ducati work (the decoding engine)
- making gst-ducati work (the gstreamer bridge to ducati)
- patching xbmc with the gstreamer patch (which is against a different
xbmc version and needs to be manually adapted)
This is currently a work in progress; all the bits and pieces for this
are available and known to work, it's "just" a matter of finding the
right combination and putting it all together.
> (*) for unknown reasons, we were able to boot xbmc on 640x480, the
> image was using approx 1/4 of the screen, and the X screen was using
> the full HD resolution ; the mouse cursor was able to move all accros
> the screen.
I've seen this as well, it looks like some issue with EDID. Can you try
running xrandr by hand and forcing a resolution?
Davide