prototype of a USB v4l2 driver?

prototype of a USB v4l2 driver?

[Andrea]

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?

Thanks for your help.

Cheers

Andrea

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

Re: prototype of a USB v4l2 driver?

[Hans de Goede]

Andrea wrote:
> 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?
> 

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.

Regards,

Hans

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

Re: prototype of a USB v4l2 driver?

[Andrea]

Hans de Goede wrote:
>> 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.
> 

Yes, it is a USB webcam: Logitech QuickCam 4000 Pro USB

I will look into gspca and see how it works.

Thanks

Andrea

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

Re: prototype of a USB v4l2 driver? gspca?

[Andrea]

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

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?
But I guess there is much more I don't know under the apparent easy interface.

Andrea

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

Re: prototype of a USB v4l2 driver? gspca?

[Hans de Goede]

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

Re: prototype of a USB v4l2 driver? gspca?

[Markus Rechberger]

On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> 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.
>

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

Markus

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

Re: prototype of a USB v4l2 driver? gspca?

[Hans de Goede]

Markus Rechberger wrote:
> On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
>> 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.
>>
> 
> 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
> 

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.

Regards,

Hans

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

Re: prototype of a USB v4l2 driver? gspca?

[Markus Rechberger]

On 7/17/08, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Markus Rechberger wrote:
> > On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <j.w.r.degoede@hhs.nl>
> wrote:
> >
> > > 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.
> > >
> > >
> >
> > 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
> >
> >
>
> 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,

dvd should be DVB, also VBI (v4l1-vbi read, v4l2-vbi-read,
v4l2-vbi-mmap) (videotext) and usb digital audio.

Markus

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

Re: prototype of a USB v4l2 driver? gspca?

[Andrea]

Hans de Goede wrote:
> Markus Rechberger wrote:
>> On Sun, Jul 13, 2008 at 9:29 PM, Hans de Goede <j.w.r.degoede@hhs.nl> 
>>
>> 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
>>
> 
> 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.
> 

I think my task is pretty limited to a webcam.
So I will start from gspca and try to work my way through it.
I am a bit scared by the size of em28xx, which seems to profide too many features for my level of 
understanding.

Andrea

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