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.