On 02/22/2008 09:25 PM, Thierry Merle wrote:
> Jiri Slaby a écrit :
>> Here I would like to know if the the commands passing interface to the
>> helper daemon introduced in this patch is OK, or alternatively propose
>> some other idea ;).
>>
> It is a good starting point.
> All ioctls will be processed in the helper daemon via the process_ioctl
> command.
> read/write processings make less context switchings than ioctls.
> Further, mmap will be required to pass the compressed/uncompressed frames.
>
> The point to think about is how to identify the base driver when we
> reach the process_ioctl function.
> The helper daemon must behave in a specific way for each base driver to
> extend.
I was thinking about yet another thing. Maybe the driver should pass to the ext
layer, which conversions should be done. I mean for example vert./horiz. flip,
image rotation, which has nothing to do with V4l, but some cameras might want
this (stk11xx is good/bad example ;)). In this case no matter of chosen format,
every frame must go through the daemon to process the conversion. So I was also
thinking about passing to the ext layer in which (non-v4l = upside-down) formats
the driver can emit frames (or layer can ask through v4l ioctl callbacks). Or
just letting this on the base driver?
> I see 2 solutions:
> - identify the base driver at each request between the extended driver
> and the helper daemon,
> - instanciate a helper daemon for each base driver (that means
> concurrent accesses to /dev/v4l2_extension)
But how to distinguish the application accessing the node then?
> Identify the base driver means the helper daemon must know its
> capabilities, not only its name.
Yes. But it must in any way, needn't it? (To not return yet enumered formats for
example.)
I don't know, both have their pros and cons.