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