On Thursday 10 February 2011 08:17:31 Linus Walleij wrote:
>
> > OMX main purpose is to handle multimedia hardware and offer an
> > interface to that HW that looks identical indenpendent of the vendor
> > delivering that hardware, much like the v4l2 or USB subsystems tries to
> > do. And yes optimally it should be implemented in drivers/omx in Linux
> > and a user space library on top of that.
I believe Hans was pretty clear on this: A new subsystem for video input
is not going to happen in the kernel, since there already is one. It took
over a decade to migrate all drivers from v4l1 to v4l2, nobody right
now feels in the mood to rewrite all the drivers once more.
> Thanks for clarifying this part, it was unclear to me. The reason being
> that it seems OMX does not imply userspace/kernelspace separation, and
> I was thinking more of it as a userspace lib. Now my understanding is that
> if e.g. OpenMAX defines a certain data structure, say for a PCM frame or
> whatever, then that exact struct is supposed to be used by the
> kernelspace/userspace interface, and defined in the include file exported
> by the kernel.
I don't think it can work that way. OpenMAX can only define a user-level
API, not a kernel-level API. We can extend v4l2 in ways to make it
easier to implement OpenMAX libraries on top of it, but there is not
going to be a duplication of kernel interfaces for the sake of following
a specific API in the upstream kernel.
> > It might be that some alignment also needs to be made between 4vl2 and
> > other OS's implementation, to ease developing drivers for many OSs
> > (sorry I don't know these details, but you ST-E guys should know).
>
> The basic conflict I would say is that Linux has its own API+ABI, which
> is defined by V4L and ALSA through a community process without much
> thought about any existing standard APIs. (In some cases also predating
> them.)
Some people would argue that on the contrary, the standard was
written without an understanding of reality and existing practice
if it tries to specify a kernel-level ABI ;-)
This has happened a lot before, and it generally doesn't help the
adoption of those standards.
> This coupled with strict delivery deadlines and a marketing will
> to state conformance to OpenMAX of course leads companies into
> solutions breaking the Linux kernelspace API to be able to present
> this.
>
> Now I think we have a pretty clear view of the problem, I don't
> know what could be done about it though :-/
We can't stop anyone from shipping incompatible kernels, but we can
help the Linaro members understand the problem.
If the goal is to state OpenMAX conformance, it would certainly
be a good idea to have people work on providing a hardware-independent
OpenMAX IL implementation on top of V4L2 and make sure it works with
all the devices.
Arnd
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
