On Fri, 26 Oct 2001, Justin Schoeman wrote: > volodya@xxxxxxxxxxxxxx wrote: > > > After looking at and working with Xv, v4l and v4l2 I became somewhat > > dissatisfied with the current state of affairs. I have attached a > > description of the API that would make (at least) me much happier. > > > > I would very much appreciate comments from interested people.. > > > > thanks ! > > > > Vladimir Dergachev > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Kernel multimedia architecture > > > > ** the latest version can be obtained from ** > > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/km/km.rfc.txt > > > > 0) Motivation > > v4l, v4l2 and Xv are all suffering from the same problem: attempt to fit > > existing multimedia devices into a fixed scheme. The use of pre-defined > > structs to describe parameters of device is inherently wrong because > > these parameters vary widely. This leads to either bloating of the control > > structures with parameters used only by few devices, proliferation of > > device-specific ioctl and/or struct versioning. This also makes it increasingly > > hard to implement support for new parameters. > > > > The solution, IMO, is to move away from hard-coded models of multimedia > > devices and instead allow greater flexibility to driver developers by > > providing _symbolic_ interface. > > ... > > I don't know - I don't see anything in the interface design that can do > anything more than v4l2. In fact, for high speed capturing I can see a > number of possible catches. > > I would like to see a detailed explanation of how the capabilities > differ from those of v4l2. The major difference is in increased flexibility and stability of kernel-user space interface. On the application side: * ability to utilize advanced driver features without explicit knowledge of their behaviour * wider compatibility without the need for recompile On the kernel side: * elimination of interfaced specific headers On the driver side: * be compatible with a wide range of applications * introduce support for new features without the need to modify kernel interfaces The last point is the very important in my opinion. For example, in current specification, v4l2 has no support for TV-out in graphics cards. It has no support for setting complex parameters like gamma tables. Using memory-mapped buffers requires device specific ioctls. The goal is to create an interface that does not rely on structures defined in kernel headers for communication. > > (I also doubt that an interface this complex would ever make it into the > kernel.) It is not very complex. It is much simpler than software modem driver, for example. Ultimately these questions are best answered with a sample implementation. Would you have any other concerns/suggestions ? Vladimir Dergachev > > -justin > > > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list >
