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.