> > 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 what exactly is bad with the v4l2 controls? > On the kernel side: > * elimination of interfaced specific headers Ok, you replace the '#define V4L2_CID_HUE 0x???' with the magic string "HUE" then. The point is? > On the driver side: > * be compatible with a wide range of applications ??? Sorry, but I don't see why your approach handles this better than v4l2. > * introduce support for new features without the need to modify > kernel interfaces Hmm. I don't like the idea to add new stuff that easily. People tend to do quick&dirty hacks + crazy stuff with it, leading to more incompatibilies between drivers and applications. > 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. Which device specific ioctls? They are common for _all_ v4l2 devices. > The goal is to create an interface that does not rely on structures > defined in kernel headers for communication. Why do you want to do that? Gerd -- Netscape is unable to locate the server localhost:8000. Please check the server name and try again.
