Re: prototype of a USB v4l2 driver? gspca?

[Hans de Goede <j.w.r.degoede@hhs.nl>]

Andrea wrote:
> Hans de Goede wrote:
>> Andrea wrote:
>>
>> What kind of device, I think that for webcams you;re best using gspca, 
>> (now merged in mecurial), that handles all the usb specific stuff, 
>> buffer management, etc. In general it makes it easy to write a webcam 
>> driver allowing you to focus on the interaction with the cam, rather 
>> then having to worry about looking, usb specifics, buffer management etc.
>>
> 
> I've had a quick look at the structure of gspca, and it seems that any 
> subdriver should just (easier to say that to do) fill one of those 
> structures
> 

Correct.

> struct sd_desc {
> /* information */
>     const char *name;    /* sub-driver name */
> /* controls */
>     const struct ctrl *ctrls;
>     int nctrls;
> /* operations */
>     cam_cf_op config;    /* called on probe */
>     cam_op open;        /* called on open */
>     cam_v_op start;        /* called on stream on */
>     cam_v_op stopN;        /* called on stream off - main alt */
>     cam_v_op stop0;        /* called on stream off - alt 0 */
>     cam_v_op close;        /* called on close */
>     cam_pkt_op pkt_scan;
> /* optional operations */
>     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;
> };
> 
> 1) providing ctrls (+ functions to handle settings)
> 2) functions to open/stream/close etc...
> 
> It does not seem too bad.
> 

It isn't.

> The a natural question that comes to me:
> 
> Shouldn't many more USB drivers be implemented as subdrivers of gspca?

Yes that would remove lots of code duplication, but allas they were written 
before gspca (version 2, as you currently see in mercurial) was around.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list