The VPU part could be because of missing firmware. Check if the vpu files
are present in /lib/firmware.
As for MP4, this is a known problem. You are building Chromium, not
Chrome. MP4 support is part of the restricted feature set, which is
included in Chrome but not Chromium. Try a WebM
As for the decoder itself: I implemented it in the Chromium media
framework, in media/ . I simply took the vpx decoder code, copied it, and
modified it to use the VPU. I had VP8, MPEG2, MPEG4, and h264 decoding
working. It wasnt much code, but unfortunately, the interfaces tend to
change
The Vivante libraries can map the physical buffers produced by
the VPU directly, so they could do format conversion on their
way to the graphics stack if the Chromium bindings have access
to that (the single copy I referred to above).
in my experience zero-copy really means zero memcpy()
Tearing is very bad for animated user interfaces. I know there is
functionality at kernel level to sync to the screen refresh rate, but the
Vivante drivers would have to make use of it. Is there any more information
on this problem? Perhaps some not-yet-released but announced drivers with
On Thu, Aug 29, 2013 at 4:03 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Tue, Aug 27, 2013 at 3:52 PM, John Weber rjohnwe...@gmail.com wrote:
On 8/27/13 12:53 PM, Eric Nelson wrote:
Thanks Christian,
On 08/27/2013 10:36 AM, Christian Betz wrote:
hi everyone.
i've cloned fsl
://u-boot.10912.n7.nabble.com/U-Boot-RFC-PATCH-ARMV7-Patch-to-fix-hard-float-build-issues-td22107.html
On Fri, Aug 30, 2013 at 3:23 AM, Christian Betz
christian.b...@gmail.com wrote:
On Thu, Aug 29, 2013 at 4:14 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Tue, Aug 27, 2013 at 10:25 PM
Signed-off-by: Christian Betz christian.b...@gmail.com
---
default.xml |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/default.xml b/default.xml
index a21bf60..e79f4a4 100644
--- a/default.xml
+++ b/default.xml
@@ -8,7 +8,7 @@
remote fetch=git
include repo command lines and basic explanation of master-next
along with caveats.
Signed-off-by: Christian Betz christian.b...@gmail.com
---
README | 20
1 file changed, 20 insertions(+)
diff --git a/README b/README
index af19e1f..6edc544 100644
--- a/README
+++ b
On Wed, Aug 28, 2013 at 12:43 PM, Daiane Angolini
daiane.angol...@freescale.com wrote:
I've been running some tests on master-next.
I used the following commands. Do you know any other I could run?
RESULTS:
$ DISPLAY=:0 glxgears
108 frames in 5.0 seconds = 21.508 FPS
$ DISPLAY=:0
i've already gotten a dylan build working on a imx6qsabresd, but I'm
trying to test out the latest bleeding edge code in master-next with a
zealz gk802 HDMI dongle.
I am using master-next for all the meta-fsl-* layers and master for
the other repos and attempting to bitbake core-image-base. all
hi everyone.
i've cloned fsl-community-bsp-platform and created a master-next
branch with the correct repo XML file to use master-next branch for
all the meta-fsl-* repos and master for the rest. this makes building
and testing master-next from scratch a bit easier.
this was pretty trivial to do
i'm a bit late to this thread, but can I attempt to clarify the
procedures? please correct me if i get something backwards.
the patch submission/approval/merge process generally works like so
with regards to how things land in various branches:
1. submit patch to mailing list and work through
On Thu, May 2, 2013 at 4:36 PM, Otavio Salvador ota...@ossystems.com.br wrote:
On Thu, May 2, 2013 at 4:49 PM, PAPARO Nino (MM)
nino.pap...@magnetimarelli.com wrote:
Hello,
I’m trying to create the minimal image possible with just x11, a webkit
browser and dhcp for an imx6 sabre lite board.
hi everyone,
i'm working with a freescale imx6q dev board from freescale. though
our freescale application engineers recommended LTIB, i already have
experience using openembedded on two different arm platforms and x86
(before yocto was created). in short: i want to use yocto, but i'll
drop back
14 matches
Mail list logo
