Who will be there? Is there a BoF or something similar organized?
> 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons.
> I hope several person are anticipated and made a small step for final goal.
I should be able to join, at least for the part related to buffer pools and
related top
On Tuesday, March 08, 2011 15:01:10 Andy Walls wrote:
> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
> > Hi all,
> >
> > We had a discussion yesterday regarding ways in which linaro can assist
> > V4L2 development. One topic was that of sorting out memory
VCM, CMEM, PMEM.
I'm sure that last list is incomplete.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Sunday, February 27, 2011 20:49:37 Arnd Bergmann wrote:
> On Saturday 26 February 2011, Edward Hervey wrote:
> > >
> > > Are there any gstreamer/linaro/etc core developers attending the ELC in
San Francisco
> > > in April? I think it might be useful to get together before, during or
after the
On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote:
> On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
> > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote:
> > > 2011/2/24 Edward Hervey :
> > > > What *needs* to be solved is an API for d
et&target=gst-openmax.png
>
>
Are there any gstreamer/linaro/etc core developers attending the ELC in San
Francisco
in April? I think it might be useful to get together before, during or after the
conference and see if we can turn this discussion in something more concrete.
It seems
a look at this. I hope that the CMA + HWMEM combination is exactly
what we need.
Regards,
Hans
> I think there is *much* interest
> in this mechanism, people just don't know from the name what it
> really does. Maybe it should be called mediamem or something
> ins
ystems can use. It's not a good idea to tie this
to any specific framework like GEM. Instead any subsystem should be able to use
the same subsystem-independent buffer pool API.
The actual code is probably not too bad, but trying to coordinate this over all
subsystems is not an easy task.
>
be *much* easier, though.
A good argument for doing this work is that this API can hide which parts of
the video subsystem are hardware and which are software. The application really
doesn't care how it is organized. What is done in hardware on one SoC might be
done on a DSP instead on anot
rk on key projects, deliver great tools, reduce industry wide fragmentation
and provide common foundations for Linux software distributions and stacks to
land on."
Spot on, I'd say :-)
Just for the record, let me say again they the V4L2 community will be very
happy to assist with this
libraries. It's way too early.
Regards,
Hans
>
>
> Thanks
> Sachin
>
> On Wed, Feb 9, 2011 at 1:13 PM, Hans Verkuil wrote:
>
> > On Wednesday, February 09, 2011 07:34:09 Sachin Gupta wrote:
> > > Looking at ppt from Robert , it seems v4l2 subd
practice I don't see this happening anytime soon. It would
be a very interesting experiment though.
Of course, if you don't care about getting drivers in the kernel, then I won't
stop you from using OpenMax. Personally I think that attempt to write a generic
framework like OpenMax is highly problematic due to the wildly different video
hardware implementations and the many different types of features.
BTW, if there are features missing in V4L2 that are needed to write an OpenMAX
framework on top of it, then please let us know.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
h environment. Let me know if
> > there is any other alternative.
> >
> > Regards,
> > Subash
> > ___
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
>
--
Hans Ver
e registers or makes mailbox calls to a separate DSP/CPU.
It hasn't been done yet since the V4L2 has only recently matured enough to
support such systems, and because of the often closed-source nature of such
systems.
Regards,
Hans
--
Hans Verkuil - vid
was probably never a consideration.
However, the V4L2 API and internal framework is improving rapidly, so it
is now much more attractive for powerful video hardware.
BTW, the main mailinglist for all things V4L is linux-me...@vger.kernel.org.
Regards,
Hans
> Why not ask Hans Verkuil and
15 matches
Mail list logo
