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.
Jiri Slaby a écrit :
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?
But how to control vert./horiz. flip, ... in userspace? Well, I thought about another solution: control the helper daemon to do so (vert./horiz. flip, ...) without modifying the base driver, with a userspace interface like a configuration file or a socket communication. These operations are image processings that can be applicable to any base driver in fact. Lots of (all?) webcam drivers will want these extensions.
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?
Right, we need to identify the application accessing the node too so that the helper daemon is able to know where to put the uncompressed frame for example.
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.
Indeed, the helper daemon should not overlap the base driver capabilities. So the identity of the driver must be known ("usbvision", "stk1xx", ...), a capability database will be stored into the helper daemon.
-
Jiri Slaby -
Thierry Merle