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

[Mark McClelland]

I realize Gerd already replied to this, but I just had to throw in my 2 
cents...

[e-mail] wrote:

>On Mon, 29 Oct 2001, Gerd Knorr wrote:
>
>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.
>
It's an internal kernel interface, not an ioctl. Yeah, it's a PITA, but 
that's the price of progress. Just #ifdef it like I did in 
http://alpha.dyndns.org/ov511/download/ov511.c

>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.
>
That's flat-out wrong. Read the linux-kernel archives and see what Linus 
thinks about including kernel headers, esp. regarding glibc. Apps should 
keep a private copy of the header(s). This is what I do with my (yet to 
materialize) ov511-control app, and it works OK, even across ioctl changes.

>>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 I don't understand is how will your driver implement these controls 
in a generic V4L3  GUI control app automatically? No matter how powerful 
the semantic information you give to the app is, it can still only build 
interfaces from standard GUI components that it already knows about. The 
app cannot build a gamma curve control on its own. If it could, we 
wouldn't need programmers anymore :)

So, the real issue here is not whether a string-parsing API is 
ultimately more powerful than ioctls. It probably is, but at the expense 
of code size, speed, and things like:

SET GAMMA_TABLE_ENTRY 56742="exec("/bin/sh")"

The real issue is which is more maintainable. Since you have to update 
the kernel when you add new features to your (in-kernel) driver, adding 
#defines to videodev.h doesn't take much extra work.

>>>      * what do I do if someone uses the same ioctl in the kernel source
>>>
>>???
>>
>Same ioctl number, in the kernel headers..
>
Conflicts can happen, but they will usually be caught when merging 
patches into the mainline kernel. If not, then it is probably because 
someone screwed up and redefined ioctls from public ranges in their 
driver's header. That's what private ranges are for.

The same thing can happen with any name/number space, including the one 
you have devised.

>>>What if the driver does not support counting dropped frames ?
>>>
>>-EINVAL or something like that.
>>
>But supports every other field.
>
Then don't report any dropped frames (hardcode it to zero). If the 
driver can't detect dropped frames, then how will telling the app that 
it can't make any difference? The app can detect it via the frames' 
timecodes if it has to.

>>>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.
>
Export it as three integers, with range of 0-255. Remember, most 
settings values ultimately end up in integer (or less) sized hardware 
registers. Ones that don't are special cases, which can be set via a 
private ioctl. Regardless of how settings are communicated between the 
control-app and driver, you will have to build a custom GUI component 
for any oddball setting.

>>Multiple choice controls have strings for each value.
>>
>With no way to pass strings (and their meaning) from the driver to the
>user applications.
>
See struct v4l2_querymenu

>>>Can I set/read gamma values ?
>>>
>>Gamma values yes (tables no).
>>
While I appreciate the creativity and originality of your API proposal 
(not to mention the time you took to write it; you'd have to pay me $$$ 
to do that much work), I must ask: Why should we dump V4L/V4L2 and 
rewrite all of our apps and drivers, just to save you the trouble of 
adding one (private) ioctl? Is your hardware really that difficult to 
fit into V4L2?

-- 
Mark McClelland
[e-mail]
PGP public key fingerprint: 317C 58AC 1B39 2AB0 AB96  EB38 0B6F 731F 3573 75CC