On Mon, 29 Oct 2001, Gerd Knorr wrote:
> > > GUI without knowing what these values are actually good for. Or even
> > > know whenever it is useful to build a GUI for it or not.
> >
> > First of all such a GUI is relatively easy to build: see gamma controls in
> > XV. Secondly, you are presenting a shaky argument: GUI is hard to built
> > hence do not let user adjust them at all..
>
> There are cases where it is quite useless to build a GUI: If you have a
> device with hardware compression support and want to set DCT
> coefficients for example. It is (like gamma table) just a list of
> values, but you certainly don't want present the same GUI for them to
> the user. For the DCT coefficients it probably would be reasonable to
> present no GUI at all, or let the user only pick one of a few reasonable
> choices.
>
Well, I am not saying that GUI needs to be presented for everything that
can be adjusted, at least not unless requested explicitly by the user.
> > > I don't see how your approach handles this.
> >
> > Ahh, it is not there yet. I did not want to do it until there is a simple
> > driver to experiment with. It would be along the lines of
> > HUE_DEPENDENT_ON=....
>
> And this means? If hue depends on foo, the application should read back
> the hue value and update the GUI if foo has changed?
Let me do it with mixers ;)
VOLUME1
VOLUME2
VOLUME2_DEPENDENT_ON=MIXER1
This means that VOLUME2 is the master control of VOLUME1.
Perhaps I should change it to VOLUME1_MASTER=VOLUME2 ...
>
> > > > Additionally nonone will need to include kernel headers to compile the
> > > > application.
> > >
> > > Why do you want to avoid this?
> > >
> >
> > 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.
>
> > > > Also, mmaped buffers + character device fits a larger category then just
> > > > the devices mentioned in v4l2 specifications. Granted the specification
> > > > can be extended, but the new driver will have to distribute not only its
> > > > source but a patch to the kernel headers. The scheme will avoid this.
> > >
> > > And why this is better? You likely still have to teach the applications
> > > about the new features of the driver if you actually want to use them
> > > (unless there are just a few new controls, but this case can easily
> > > handled with v4l2 too).
> >
> > You don't have to invent a new kernel header just to support a new set of
> > devices.
>
> 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.
> > v4l2 is quite a lot bettern than v4l. But it is quite static.
>
> I consider a static API a good thing. Code often lives for years, and
> it is nice if your five year old source code build and works just fine
> ...
>
This sounds more as an argument between assembler and C. Each has its
place.
> > Think about
> > what needs to be done to enable gamma tables for video out - this is not
> > trivial..
>
> Yes, we'll basically need new v4l2 ioctls for it.
>
> > > I doubt this fixes the problem (driver devel time) you've mentioned.
> > > Most of the time of the driver development is needed for the code which
> > > talks to the hardware. Building a simple v4l(2) ioctl interface which
> > > just says "I can nothing but capture, and the format list is YUV422" is
> > > easy compared to the other work which needs to be done for a working
> > > driver. v4l(2) doesn't force you to wait with the release until you
> > > have a full-featured driver ...
> >
> > It's not. What I want to be able to do is to release a driver that
> > supports basic functionality plus a bunch of device-specific stuff for
> > which no API exists. Then, with more experience, we can make an API.
>
> Nobody stops you from creating some temporary device-specific ioctls for
> playing and testing ...
>
> 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.
>
> > > > * kernel structures force a specific model onto a driver
> > >
> > > The control strings you want to read() and write() to the driver do
> > > exactly the same, because they must have some clear defined semantic to
> > > make the whole model actually workable.
> > >
> >
> > The benifit is that we dont have to define it in the kernel headers. Right
> > now if I want to add a new ioctl I have tons of problems:
> >
> > * how do I communicate to the application source the new structs
> > I am using ?
>
> 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 ?
> > * what do I do if someone uses the same ioctl in the kernel source
>
> ???
Same ioctl number, in the kernel headers..
>
> > * what happens if I want to add a new field during driver
> > development ? (users will see crashing applications..)
>
> No.
>
> v4l2 has a few reserved[x] in the structs to allow such extentions
> without breaking binary comparibility.
>
> If you add a new field to a struct the ioctl magic number changes
> because the size of the struct has changed. This can be used to add new
> fields without breaking stuff (althrought it starts to become ugly here,
> drivers have to support both old and new versions of the ioctl). Look
> at SOUND_MIXER_INFO vs. SOUND_OLD_MIXER_INFO in linux/soundcard.h for a
> example.
>
And then we run out of them.. and we can run out of magic number too..
> > > > * 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.
>
> > > > * confuse applications when a driver does not implement a field
> > >
> > > With v4l2 controls this shouldn't be a issue any more.
> >
> > What if the driver does not support counting dropped frames ?
>
> -EINVAL or something like that.
But supports every other field.
>
> > 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.
> > > > However, this is hard to implement with ioctl's as they rely on fixed
> > > > length structures. You would have to call first to find out the size of
> > > > the buffer you need (which the driver would have to compute) and then the
> > > > second time to get the data. Eeeks.
> > >
> > > Wrong. Look at the specs for the v4l2 controls.
> >
> > Can I return a string as a value ? (For a device specific control).
>
> Multiple choice controls have strings for each value.
>
With no way to pass strings (and their meaning) from the driver to the
user applications.
> > Can I set/read gamma values ?
>
> Gamma values yes (tables no).
>
> > > > them with read/writes on the control device. With the added benifit that
> > > > we can select on it to wait for an event.
> > >
> > > v4l2 expects drivers to support select too, so you can wait for your
> > > capture requests using select.
> >
> > Which means one more thing in the driver to support.
>
> Of course a driver needs some code to support select(), it doesn't work
> with black magic. What else do you expect?
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 ?
Also, v4l select will not work (as far as I understand) when the driver is
using memory-mapped buffers.
Vladimir Dergachev
>
> Gerd
>
