Le Saturday 06 September 2008 16:41:41, vous avez écrit :
>
> Yes I know about gspca and I've researched the option of adapting the
> driver to it.
> Frankly, I don't like the coding style and layout of gspca at all and am
> not ready to put the time to adapt the driver to it as of now.
the layout ? what is so bad in it? Almost all usbcam drivers derives
from the same original driver!
> If somebody else wants to do it, go ahead and we'll see what comes out
> of it.
>
> Regards,
> Erik
basically, the work left to the driver code (called the sub driver)
consist of providing callbacks functions.
-detection/identification of chipset
-SOF detection
-going on/off
-color/contrast/flip/any video controls
The coding style is not a valid reason. Just because all
the upper layer is done and you don't need to read it
more than once ;-)
Yes, lot of code 'is going away' and it is hard to limit
writing just a few callbacks and being happy. But frankly,
once you understand how to concatenate data from
each usb URB, or interface with v4L2 and buffers management,
where is the interest of developping another flavour?
Ok, the 'registration' of the subdriver with upper layer driver is
inexistant. Only one subdriver can be activated.
But this doesn't prevent to use this model also here.
Reading the list, what come again and again is identifying
chipset, finding functions, correctly setting registers. The video
processing, usb management are rarely present except for
bugs ;-)
FYI, the interface between the upper driver and the subdriver.
(by the way, microsoft windows heaviliy uses this architecture,
called the 'minidriver' associated with a high level driver).
/* subdriver description */
struct sd_desc {
/* information */
const char *name; /* sub-driver name */
/* controls */
const struct ctrl *ctrls;
int nctrls;
/* mandatory operations */
cam_cf_op config; /* called on probe */
cam_op init; /* called on probe and resume */
cam_v_op start; /* called on stream on */
cam_pkt_op pkt_scan;
/* optional operations */
cam_v_op stopN; /* called on stream off - main alt */
cam_v_op stop0; /* called on stream off - alt 0 */
cam_v_op dq_callback; /* called when a frame has been dequeued */
cam_jpg_op get_jcomp;
cam_jpg_op set_jcomp;
cam_qmnu_op querymenu;
};
Again, clearly separating lowlevel driver code from the general common
driver code is not a bad idea ;-)
Franck
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
M560x-driver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
