Re: [V4L] Re: [RFC] alternative kernel multimedia API

On Tue, 30 Oct 2001, Gerd Knorr wrote:

> > > > So I can distribute the driver and the application to use it and not
> > > > depend on the kernel version.
> > > 
> > > The exported API must not depend on the kernel version.  If the API
> > > changes in a way which isn't backward compatible, it is a kernel bug.
> > 
> > I already got a report from the user that in his kernel
> > video_register_device has 2 arguments and not 3. This is pain to deal with
> > in drivers distributed separately from kernel tree.
> 
> Internal kernel interfaces are another story, they are not fixed and are
> allways subject to change and not limited to v4l.  See the major pci
> subsystem changes from 2.2 => 2.4 for example.  The API visible to the
> application matters, this must stay backward compatible.

You are starting to see my point. I want API flexible enough not to
require #ifdef's each time a new feature is added. Driver is an
application in it's own right. While 2.2=>2.4 change is ok, I really
dislike such changes in the _stable_ kernel. 

> 
> > > I can't see why it is a problem to add a new header or new ioctls to
> > > a existing header file.  I like it this way, because the kernel headers
> > > with all the #defines and structs are providing at least a minimum of
> > > documentation.  I do often read header files when programming stuff.
> > > 
> > 
> > Because we don't know which interface is best until we experiment with
> > it. And I can't experiment without people being able to test. And the
> > easier it is to compile and install code the more testers (and developers
> > !) we get.
> 
> I can't see why ioctls don't allow you to experiment.
> 

Well, could you add then an ioctl to the current kernel so I can
experiment with it ? I want it in the kernel headers so that the
applications will compile whether or not the driver sourcecode has been
installed. Nothing fancy, just an ioctl number something along

#define V4L_VLADIMIR_DERGACHEV_PRIVATE_IOCTL     _IOWR(....)

I'll take care of the structs ;)

> > > Of course old applications don't know about the new stuff (neither the
> > > temporary nor the final versions which make in into the official API
> > > some day maybe).  But I don't see how your approach handles this better:
> > > Applications still need to be hacked to use the new stuff ...
> > > 
> > 
> > The way you write device specific appliacation is by including kernel
> > headers. If the stuff we want is not there makes a lot trouble for
> > installing and maintaining code.
> 
> No, it doesn't.  I never had trouble with xawtv.  I simply shipped a
> private copy of videodev.h with the xawtv tarball (which allowed to
> build it without hassle on 2.0.x systems which had no linux/videodev.h
> yet).
> 

Well, if it worked for you - good. I am not going that way, the versioning
issues alone are reason enough.

> > > You can't.  But I don't see why this is a issue:  The only thing a
> > > application can handle easily are controls like contrast/hue where the
> > > only thing a application needs to do is to map it to a GUI and let the
> > > user understand and adjust stuff.  The other stuff has way to much
> > > non-trivial dependences, I doubt a application can blindly use new
> > > driver features.
> > 
> > Have you ever thought that the reason we only use these controls is
> > because they are the only ones easy to implement now ?
> 
> I doubt this is just a implementation issue.  I don't believe in AI.
> 

:)))) There is a thin line between real intellegence and clever
algorithm. My bet is that a clever algorithm will suffice.

> > > > > >   * can cause problems with different compilers
> > > > > 
> > > > > Then your compiler is buggy.
> > > > 
> > > > No, I may have simply used different compilers for the kernel and the
> > > > application.
> > > 
> > > I doubt that.
> > 
> > You are kidding, aren't you ? Most distributions now come out with egcs
> > compiler 1.1.x "recommended for compiling" kernels and something newer.
> 
> I doubt that this creates trouble, not that you might use different
> compilers (I know RH ships or used to ship kgcc ...).
> 

It might. I have no desire of debugging such things.

> > > > What if the driver does not support counting dropped frames ?
> > > 
> > > -EINVAL or something like that.
> > 
> > But supports every other field.
> 
> Can't happen, there is VIDIOC_G_PERF only for this performance
> monitoring ...

You mean you won't allow a driver like that. This is precisely the
inflexibility I was talking about.

> 
> > > > What if there is a control with no min/max limits ?
> > > 
> > > Do you have a example?
> > > 
> > 
> > Overlay color key - this is basically an RGB pixel value.
> 
> 0x000000 => 0xffffff ?

If you use alpha value too you'll need all 32bits. And imagine a GUI
slider for that.. ;) 

> 
> > I would prefer minimum effort on the part of driver writer ;) At the
> > moment all I see in bttv and my own code for select is looking on some
> > already existing fields. Heck, the code is very similar to what needs to
> > be checked for a blocking/non-blocking read. Why duplicate it ?
> 
> bttv's poll function is very short for exactly this reason.  Basically I
> only have to call poll_wait with the (existing) wait queue which the IRQ
> handler will wake up once the frame capture is finished.
> 

Ohh, bttv _is_ good. I only argue against v4l :)

                            Vladimir Dergachev

> > Also, v4l select will not work (as far as I understand) when the driver is
> > using memory-mapped buffers.
> 
> v4l2 expects drivers to support select for the mmap() case too.

> 
>   Gerd
> 
> -- 
> Netscape is unable to locate the server localhost:8000.
> Please check the server name and try again.
>