prototype of a USB v4l2 driver?

Hi,

I would like to learn more in detail how a video driver works.
Basically in the last days I've looked at pwc to see why it is not so robust with mplayer. I found something in the streaming ioctl calls.

As an exercise I would like to port it to the "best" and "more elegant" framework, reusing as much as possible the existing v4l2 framework are writing as little code as possible (e.g. using videobuf). And remove all the v4l1 code.

I would like to know which is the best USB driver to look at. Which is the best USB driver that implements videobuf?

This is a good overview of a driver
http://lwn.net/Articles/203924/

I think vivi.c is an other good one.

Does anybody have any other good reference to look at?

Quoted 7 lines

This is a good overview of a driver
http://lwn.net/Articles/203924/

I think vivi.c is an other good one.

Does anybody have any other good reference to look at?

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.

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.

Quoted 4 lines · Hans de Goede

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

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.

The a natural question that comes to me:

Shouldn't many more USB drivers be implemented as subdrivers of gspca?

Quoted 12 lines · Andrea

Quoted 9 lines · Hans de Goede

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.

Quoted 4 lines

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.

Quoted 21 lines

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;
};

Quoted 5 lines

1) providing ctrls (+ functions to handle settings)
2) functions to open/stream/close etc...

It does not seem too bad.

It isn't.

Quoted 3 lines

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.

Quoted 42 lines · Hans de Goede

Quoted 9 lines · Andrea

Quoted 8 lines · Hans de Goede

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.

Quoted 4 lines

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.

Quoted 21 lines

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;
};

Quoted 5 lines

1) providing ctrls (+ functions to handle settings)
2) functions to open/stream/close etc...

It does not seem too bad.

Quoted 8 lines

It isn't.

Quoted 3 lines

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.

I guess quite a few drivers have extra features which might be missing in other usb based ones. Best is probably to have a look at all available ones and cherry pick the best ideas and easiest to understand parts.
I think they are all on a certain level of quality right now.

* gspca
* uvcvideo
* em28xx from mcentral.de

Quoted 1 line · Markus Rechberger

On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <[email protected]>

Quoted 8 lines · wrote:

Quoted 8 lines

Quoted 5 lines · Andrea

Quoted 3 lines · Hans de Goede

Andrea wrote:

What kind of device, I think that for webcams you;re best using

gspca,

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

(now merged in mecurial), that handles all the usb specific stuff,

buffer

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

management, etc. In general it makes it easy to write a webcam

driver

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

allowing you to focus on the interaction with the cam, rather then

having to

Quoted 38 lines

Quoted 38 lines

Quoted 8 lines

Quoted 3 lines

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.

Quoted 27 lines

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.

Quoted 8 lines

Quoted 8 lines

It isn't.

Quoted 4 lines

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

Quoted 10 lines

Quoted 3 lines

before gspca (version 2, as you currently see in mercurial) was around.

I guess quite a few drivers have extra features which might be missing in other usb based ones. Best is probably to have a look at all available ones and cherry pick the best ideas and easiest to understand parts.
I think they are all on a certain level of quality right now.

Quoted 5 lines

* gspca
* uvcvideo
* em28xx from mcentral.de

Well these 3 drivers (in case of gscpa driver group) target different classes of hardware:

gspca:     pre uvc webcams (and nothing more then that)
uvcvideo:  uvc devices
em28xx:    em28xx based devices, which can be dvd, analogtv, webcam, etc,

Quoted 8 lines · Markus Rechberger

On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <[email protected]>

I guess quite a few drivers have extra features which might be missing in other usb based ones. Best is probably to have a look at all available ones and cherry pick the best ideas and easiest to understand parts.
I think they are all on a certain level of quality right now.

Quoted 4 lines

* gspca
* uvcvideo
* em28xx from mcentral.de

Well these 3 drivers (in case of gscpa driver group) target different classes of hardware:

gspca:     pre uvc webcams (and nothing more then that)
uvcvideo:  uvc devices
em28xx:    em28xx based devices, which can be dvd, analogtv, webcam, etc, etc.