Re: Convert cpia driver to v4l2, drop parallel port version support?

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans Verkuil]

> Hi,
>
> I recently have been bying second hand usb webcams left and right
> one of them (a creative unknown model) uses the cpia1 chipset, and
> works with the v4l1 driver currently in the kernel.
>
> One of these days I would like to convert it to a v4l2 driver using
> gspca as basis, this however will cause us to use parallel port support
> (that or we need to keep the old code around for the parallel port
> version).
>
> I personally think that loosing support for the parallel port
> version is ok given that the parallel port itslef is rapidly
> disappearing, what do you think ?

I agree wholeheartedly. If we remove pp support, then we can also remove
the bw-qcam and c-qcam drivers since they too use the parallel port.

BTW, I also have a cpia1 camera available for testing. I can also test
ov511 (I saw that you added support for that to gspca). Ditto for the
stv680 and w9968cf.

Note that I can mail these devices to you if you want to work on
integrating them into gspca. I'm pretty sure I won't have time for that
myself.

Regards,

           Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

On 06/17/2009 09:43 AM, Hans Verkuil wrote:
>> Hi,
>>
>> I recently have been bying second hand usb webcams left and right
>> one of them (a creative unknown model) uses the cpia1 chipset, and
>> works with the v4l1 driver currently in the kernel.
>>
>> One of these days I would like to convert it to a v4l2 driver using
>> gspca as basis, this however will cause us to loose parallel port support
>> (that or we need to keep the old code around for the parallel port
>> version).
>>
>> I personally think that loosing support for the parallel port
>> version is ok given that the parallel port itself is rapidly
>> disappearing, what do you think ?
>
> I agree wholeheartedly. If we remove pp support, then we can also remove
> the bw-qcam and c-qcam drivers since they too use the parallel port.
>

Ok :)

> BTW, I also have a cpia1 camera available for testing. I can also test
> ov511 (I saw that you added support for that to gspca). Ditto for the
> stv680 and w9968cf.
>
> Note that I can mail these devices to you if you want to work on
> integrating them into gspca. I'm pretty sure I won't have time for that
> myself.
>

Yes I want to work on integrating them into gspca (as time permits).
If you could mail them to me that would be great! Esp the w9968cf one,
once that is moved to gspca, we can get rid of the entire ovcamchip stuff
(eventually it would be good to move to a model where the sensor drivers
  are seperated again, but I'm waiting to see what comes out of the
  soc / ov7660 discussion for this).

I'll send my postal address in a private mail.

Regards,

Hans

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
"Hans Verkuil" <hverkuil@xs4all.nl> escreveu:

> > I recently have been bying second hand usb webcams left and right
> > one of them (a creative unknown model) uses the cpia1 chipset, and
> > works with the v4l1 driver currently in the kernel.
> >
> > One of these days I would like to convert it to a v4l2 driver using
> > gspca as basis, this however will cause us to use parallel port support
> > (that or we need to keep the old code around for the parallel port
> > version).
> >
> > I personally think that loosing support for the parallel port
> > version is ok given that the parallel port itslef is rapidly
> > disappearing, what do you think ?
> 
> I agree wholeheartedly. If we remove pp support, then we can also remove
> the bw-qcam and c-qcam drivers since they too use the parallel port.

Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
to keep supporting them with V4L2 API ;)

That's said, while it is probably not that hard to develop a gspca-pp driver,
I'm not against removing parallel port support or even removing those drivers
due to technical reasons, like the end of V4L1 drivers.

By looking at the remaining V4L1 drivers, we have:

	ov511 - already implemented with V4L2 on gspca. Can be easily removed;

	se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
		to convert them to gspca;

	cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them
		to vidio_ioctl2 and remove V4L1 API.

	stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is
		already another saa7146 driver running V4L2, used by mxb, hexium_gemini and
		hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for
		the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert
		and test with V4L2, then maybe we can just remove it. The better conversion would
		probably be to use the V4L2 support at the saa7146 driver.

	arv - seems to be a VGA output driver - Only implements 3 ioctls:
		VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2.
		I'm not sure if this is still used in practice.

	bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport;

IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported
by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that
will still remain using only the legacy API can be dropped. Anything more converted will be a bonus



Cheers,
Mauro

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 06:56:21 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:

> Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> "Hans Verkuil" <hverkuil@xs4all.nl> escreveu:
> 
> > > I recently have been bying second hand usb webcams left and right
> > > one of them (a creative unknown model) uses the cpia1 chipset, and
> > > works with the v4l1 driver currently in the kernel.
> > >
> > > One of these days I would like to convert it to a v4l2 driver using
> > > gspca as basis, this however will cause us to use parallel port support
> > > (that or we need to keep the old code around for the parallel port
> > > version).
> > >
> > > I personally think that loosing support for the parallel port
> > > version is ok given that the parallel port itslef is rapidly
> > > disappearing, what do you think ?
> > 
> > I agree wholeheartedly. If we remove pp support, then we can also remove
> > the bw-qcam and c-qcam drivers since they too use the parallel port.
> 
> Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
> to keep supporting them with V4L2 API ;)
> 
> That's said, while it is probably not that hard to develop a gspca-pp driver,
> I'm not against removing parallel port support or even removing those drivers
> due to technical reasons, like the end of V4L1 drivers.
> 
> By looking at the remaining V4L1 drivers, we have:
> 
> 	ov511 - already implemented with V4L2 on gspca. Can be easily removed;
> 
> 	se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
> 		to convert them to gspca;

In time: w9968cf
> 
> 	cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them
> 		to vidio_ioctl2 and remove V4L1 API.
> 
> 	stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is
> 		already another saa7146 driver running V4L2, used by mxb, hexium_gemini and
> 		hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for
> 		the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert
> 		and test with V4L2, then maybe we can just remove it. The better conversion would
> 		probably be to use the V4L2 support at the saa7146 driver.
> 
> 	arv - seems to be a VGA output driver - Only implements 3 ioctls:
> 		VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2.
> 		I'm not sure if this is still used in practice.
> 
> 	bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport;
> 
> IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported
> by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that
> will still remain using only the legacy API can be dropped. Anything more converted will be a bonus

So, the must do list seems to be:

se401, stv680, usbvideo, vicam and w9968cf.



Cheers,
Mauro

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

On 06/17/2009 11:56 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> "Hans Verkuil"<hverkuil@xs4all.nl>  escreveu:
>
>>> I recently have been bying second hand usb webcams left and right
>>> one of them (a creative unknown model) uses the cpia1 chipset, and
>>> works with the v4l1 driver currently in the kernel.
>>>
>>> One of these days I would like to convert it to a v4l2 driver using
>>> gspca as basis, this however will cause us to use parallel port support
>>> (that or we need to keep the old code around for the parallel port
>>> version).
>>>
>>> I personally think that loosing support for the parallel port
>>> version is ok given that the parallel port itslef is rapidly
>>> disappearing, what do you think ?
>> I agree wholeheartedly. If we remove pp support, then we can also remove
>> the bw-qcam and c-qcam drivers since they too use the parallel port.
>
> Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
> to keep supporting them with V4L2 API ;)
>
> That's said, while it is probably not that hard to develop a gspca-pp driver,
> I'm not against removing parallel port support or even removing those drivers
> due to technical reasons, like the end of V4L1 drivers.
>
> By looking at the remaining V4L1 drivers, we have:
>
> 	ov511 - already implemented with V4L2 on gspca. Can be easily removed;
>

Yip, this one is a done deal :)

> 	se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
> 		to convert them to gspca;
>

I've recently bought a (second hand) stv680 cam, haven't seriously tested it yet,
so I dunno if it works with the v4l1 driver. I agree it would be good to convert these,
and I can work on this as time permits, but I won't be converting code I don't have
HW to test for.

As for usbvideo that supports (amongst others) the st6422 (from the out of tree
qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding
st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with.

And indeed as mentioned in another mail we should also convert the w9968cf.

> 	cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them
> 		to vidio_ioctl2 and remove V4L1 API.
>

I have a pwc cam , so I can test changes for pwc. btw current pwc oopses rather badly (GPF)
when unplugging the cam, I'll dig into this.

> 	stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is
> 		already another saa7146 driver running V4L2, used by mxb, hexium_gemini and
> 		hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for
> 		the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert
> 		and test with V4L2, then maybe we can just remove it. The better conversion would
> 		probably be to use the V4L2 support at the saa7146 driver.
>
> 	arv - seems to be a VGA output driver - Only implements 3 ioctls:
> 		VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2.
> 		I'm not sure if this is still used in practice.
>
> 	bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport;
>
> IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported
> by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that
> will still remain using only the legacy API can be dropped. Anything more converted will be a bonus
>

Big +1, having digged through many of these old drivers to convert them, they all seem rather crufty
and ugly and having them gone would be good.

While cleaning cruft, I would also like to see the following v4l2 drivers go away in time, they are all
from the same author (who mostly borrowed the reverse engineering work from the original out of tree
gspca) and he does not maintain them, and they all support cams also supported by the new gspca:

zc0301
only supports one usb-id which has not yet been tested with gspca, used to claim a lot more
usb-id's but didn't actually work with those as it only supported the bridge, not the sensor
-> remove it now ?

et61x251
Only supports using this bridge in combination with one type of sensor where as gspca
supports 2 type of sensors. gspca support is untested AFAIK.
-> ?

sn9c102
Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using
#ifdef .... macros to detect if both are being build at the same time to include usb-id's only
in one of the 2.

As seems normal for drivers from this author the driver used to claim a lot of usb-id's it
couldn't actually work with as it only supported the bridge, not the sensor. We've removed all
those and are now slowly moving over the remaining usb-ids to gspca as things get tested
with gspca.
-> Keep on moving over usb-id's then when only a few are left, drop it

Regards,

Hans

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 12:59:59 +0200
Hans de Goede <hdegoede@redhat.com> escreveu:

> 
> 
> On 06/17/2009 11:56 AM, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> > "Hans Verkuil"<hverkuil@xs4all.nl>  escreveu:
> >
> >>> I recently have been bying second hand usb webcams left and right
> >>> one of them (a creative unknown model) uses the cpia1 chipset, and
> >>> works with the v4l1 driver currently in the kernel.
> >>>
> >>> One of these days I would like to convert it to a v4l2 driver using
> >>> gspca as basis, this however will cause us to use parallel port support
> >>> (that or we need to keep the old code around for the parallel port
> >>> version).
> >>>
> >>> I personally think that loosing support for the parallel port
> >>> version is ok given that the parallel port itslef is rapidly
> >>> disappearing, what do you think ?
> >> I agree wholeheartedly. If we remove pp support, then we can also remove
> >> the bw-qcam and c-qcam drivers since they too use the parallel port.
> >
> > Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
> > to keep supporting them with V4L2 API ;)
> >
> > That's said, while it is probably not that hard to develop a gspca-pp driver,
> > I'm not against removing parallel port support or even removing those drivers
> > due to technical reasons, like the end of V4L1 drivers.
> >
> > By looking at the remaining V4L1 drivers, we have:
> >
> > 	ov511 - already implemented with V4L2 on gspca. Can be easily removed;
> >
> 
> Yip, this one is a done deal :)
> 
> > 	se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
> > 		to convert them to gspca;
> >
> 
> I've recently bought a (second hand) stv680 cam, haven't seriously tested it yet,
> so I dunno if it works with the v4l1 driver. I agree it would be good to convert these,
> and I can work on this as time permits, but I won't be converting code I don't have
> HW to test for.
> 
> As for usbvideo that supports (amongst others) the st6422 (from the out of tree
> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding
> st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with.

I have here one Logitech quickcam. There are several variants, and the in-tree
and out-tree drivers support different models. I can test it here and give you
a feedback. However, I don't have the original driver for it.

> zc0301
> only supports one usb-id which has not yet been tested with gspca, used to claim a lot more
> usb-id's but didn't actually work with those as it only supported the bridge, not the sensor
> -> remove it now ?

I have one zc0301 cam that works with this driver. The last time I checked, it
didn't work with gspca. I'll double check.

> et61x251
> Only supports using this bridge in combination with one type of sensor where as gspca
> supports 2 type of sensors. gspca support is untested AFAIK.
> -> ?
> 
> sn9c102
> Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using
> #ifdef .... macros to detect if both are being build at the same time to include usb-id's only
> in one of the 2.

Btw, it would be interesting to work with the out-of-tree microdia driver,
since there are some models that are supported only by the alternative driver. 
> 
> As seems normal for drivers from this author the driver used to claim a lot of usb-id's it
> couldn't actually work with as it only supported the bridge, not the sensor. We've removed all
> those and are now slowly moving over the remaining usb-ids to gspca as things get tested
> with gspca.
> -> Keep on moving over usb-id's then when only a few are left, drop it

It makes no sense to have two drivers for the same cams. Once having support
for all USB ID's, we can mark the alternative driver as deprecated and remove
it at the next kernel version.



Cheers,
Mauro

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

Hi all,

On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Jun 2009 12:59:59 +0200
> Hans de Goede<hdegoede@redhat.com>  escreveu:
>

<snip>

>>
>> As for usbvideo that supports (amongst others) the st6422 (from the out of tree
>> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding
>> st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with.
>
> I have here one Logitech quickcam. There are several variants, and the in-tree
> and out-tree drivers support different models. I can test it here and give you
> a feedback. However, I don't have the original driver for it.
>

Ok, what is its usb id (they tend to be unique for Logitech cams) ?

>> zc0301
>> only supports one usb-id which has not yet been tested with gspca, used to claim a lot more
>> usb-id's but didn't actually work with those as it only supported the bridge, not the sensor
>> ->  remove it now ?
>
> I have one zc0301 cam that works with this driver. The last time I checked, it
> didn't work with gspca. I'll double check.
>

Ok, let me know how it goes. If it does not work, guess what I want you to bring along
to plumbers ? (you are coming to plumbers, or .. ? )

>> sn9c102
>> Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using
>> #ifdef .... macros to detect if both are being build at the same time to include usb-id's only
>> in one of the 2.
>
> Btw, it would be interesting to work with the out-of-tree microdia driver,
> since there are some models that are supported only by the alternative driver.

Ack, only one small problem, which is another reason why Luca's drivers should slowly be phased
out, Luca has gone closed source with his sn9cxxx driver.

There is an out of tree driver for the new sn9c2xx models you talk about though, with active
developers, I've pushing them to get it into the mainline, I'll give it another try soonish.

Regards,

Hans

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 16:41:23 +0200
Hans de Goede <hdegoede@redhat.com> escreveu:

> Hi all,
> 
> On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Jun 2009 12:59:59 +0200
> > Hans de Goede<hdegoede@redhat.com>  escreveu:
> >
> 
> <snip>
> 
> >>
> >> As for usbvideo that supports (amongst others) the st6422 (from the out of tree
> >> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding
> >> st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with.
> >
> > I have here one Logitech quickcam. There are several variants, and the in-tree
> > and out-tree drivers support different models. I can test it here and give you
> > a feedback. However, I don't have the original driver for it.
> >
> 
> Ok, what is its usb id (they tend to be unique for Logitech cams) ?

The one I have is this one:

Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus

This is supported by one quickcam driver.

> >> zc0301
> >> only supports one usb-id which has not yet been tested with gspca, used to claim a lot more
> >> usb-id's but didn't actually work with those as it only supported the bridge, not the sensor
> >> ->  remove it now ?
> >
> > I have one zc0301 cam that works with this driver. The last time I checked, it
> > didn't work with gspca. I'll double check.
> >
> 
> Ok, let me know how it goes. 

The zc0301 camera is this one:

Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks

zc0301 driver says this:

[98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10
[98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected (vid/pid 0x046D:0x08AE)
[98174.713717] usb 5-2: PAS202BCB image sensor detected

The cam works as expected.

> If it does not work, guess what I want you to bring along
> to plumbers ? (you are coming to plumbers, or .. ? )

I probably won't go to LPC this year, since I'm programming to be at Japan Linux
Symposium in October, and it seems too much jet leg for me to be in Portland in
Sept and in Japan in Oct ;)



Cheers,
Mauro

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

Hi,

On 06/17/2009 05:23 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Jun 2009 16:41:23 +0200
> Hans de Goede<hdegoede@redhat.com>  escreveu:
>
>> Hi all,
>>
>> On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:
>>> Em Wed, 17 Jun 2009 12:59:59 +0200
>>> Hans de Goede<hdegoede@redhat.com>   escreveu:
>>>
>> <snip>
>>
>>>> As for usbvideo that supports (amongst others) the st6422 (from the out of tree
>>>> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding
>>>> st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with.
>>> I have here one Logitech quickcam. There are several variants, and the in-tree
>>> and out-tree drivers support different models. I can test it here and give you
>>> a feedback. However, I don't have the original driver for it.
>>>
>> Ok, what is its usb id (they tend to be unique for Logitech cams) ?
>
> The one I have is this one:
>
> Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus
>
> This is supported by one quickcam driver.
>

Ah, that is one of the 2 models I have access to, so I can promise you that one will work fine
with the new st6422 support I'm doing.

>>>> zc0301
>>>> only supports one usb-id which has not yet been tested with gspca, used to claim a lot more
>>>> usb-id's but didn't actually work with those as it only supported the bridge, not the sensor
>>>> ->   remove it now ?
>>> I have one zc0301 cam that works with this driver. The last time I checked, it
>>> didn't work with gspca. I'll double check.
>>>
>> Ok, let me know how it goes.
>
> The zc0301 camera is this one:
>
> Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks
>
> zc0301 driver says this:
>
> [98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10
> [98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected (vid/pid 0x046D:0x08AE)
> [98174.713717] usb 5-2: PAS202BCB image sensor detected
>
> The cam works as expected.
>

Hmm, bummer I don't have any zc3xx test cams with a pas202b sensor, guess I need to find one :)

>
> I probably won't go to LPC this year, since I'm programming to be at Japan Linux
> Symposium in October, and it seems too much jet leg for me to be in Portland in
> Sept and in Japan in Oct ;)
>

Ah too bad, but understandable.

Regards,

Hans

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Brian Johnson]

Hans de Goede wrote:
>>> sn9c102
>>> Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using
>>> #ifdef .... macros to detect if both are being build at the same time to include usb-id's only
>>> in one of the 2.
>> Btw, it would be interesting to work with the out-of-tree microdia driver,
>> since there are some models that are supported only by the alternative driver.
> 
> Ack, only one small problem, which is another reason why Luca's drivers should slowly be phased
> out, Luca has gone closed source with his sn9cxxx driver.
> 
> There is an out of tree driver for the new sn9c2xx models you talk about though, with active
> developers, I've pushing them to get it into the mainline, I'll give it another try soonish.
> 

Hello I'm one of the developers for the current out of tree sn9c20x driver.  What needs to be done in order
to get the sn9c20x code into the mainline? Am i right in assuming it would be preferred to move the code into 
a sn9c20x gspca subdriver rather then include the complete out of tree driver? If this is the case I can work
on a set of patches to implement our code as a gspca subdriver.

Also i have a few questions regarding submitting the patches.

1) In addition to sending them to linux-media should I CC them to anyone in particular?
2) The entire patch would likely be about 70k. Should I just send one patch or split the
thing up into several?

Thanks,
Brian

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

On 06/17/2009 08:11 PM, Brian Johnson wrote:
> Hans de Goede wrote:
>>>> sn9c102
>>>> Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using
>>>> #ifdef .... macros to detect if both are being build at the same time to include usb-id's only
>>>> in one of the 2.
>>> Btw, it would be interesting to work with the out-of-tree microdia driver,
>>> since there are some models that are supported only by the alternative driver.
>> Ack, only one small problem, which is another reason why Luca's drivers should slowly be phased
>> out, Luca has gone closed source with his sn9cxxx driver.
>>
>> There is an out of tree driver for the new sn9c2xx models you talk about though, with active
>> developers, I've pushing them to get it into the mainline, I'll give it another try soonish.
>>
>
> Hello I'm one of the developers for the current out of tree sn9c20x driver.  What needs to be done in order
> to get the sn9c20x code into the mainline? Am i right in assuming it would be preferred to move the code into
> a sn9c20x gspca subdriver rather then include the complete out of tree driver?

Yes that would be very much prefered. Not that I believe that gspca is the
best thing ever invented or anything like that. But usb webcam drivers all have a lot in
common and gspca handles that good enough, and if we ever want to make improvements like
moving usb webcams to use videobuf, having them all as gspca sub drivers means we only
need to do it once, as for example all buffer management is done by gspca.

Also after looking at the pwc driver oops at unplug, and being reminded at the ref counting
with hotplug devices going away and locking nightmare stuff we discussed some time ago,
I'm also really glad to only have all that tricky code only once.

This will also make reviewing a lot easier as there will be no tricky buffer management
and locking, etc. to review.

 > If this is the case I can work
 > on a set of patches to implement our code as a gspca subdriver.
 >

As explained above very much: "Yes please"

> Also i have a few questions regarding submitting the patches.
>
> 1) In addition to sending them to linux-media should I CC them to anyone in particular?

I have such a cam and I'm one of the people actively working on gspca, so if you could CC
me then I'm sure to notice it and review it, and it can get merged through my mercurial
(git alike vcs) tree.

> 2) The entire patch would likely be about 70k. Should I just send one patch or split the
> thing up into several?

I would hope gspca would shrink the size somewhat :) As for one patch versus incremental
patches, as this is a whole new driver one patch will do I guess, I see little use in having
non working increments in between.

Thanks & Regards,

Hans

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Andy Walls]

On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:

> > I personally think that loosing support for the parallel port
> > version is ok given that the parallel port itslef is rapidly
> > disappearing, what do you think ?
> 
> I agree wholeheartedly. If we remove pp support, then we can also remove
> the bw-qcam and c-qcam drivers since they too use the parallel port.

Maybe I just like keeping old hardware up and running, but...

I think it may be better to remove camera drivers when a majority of the
actual camera hardware is likely to reach EOL, as existing parallel
ports will likely outlive the cameras.

My PC I got in Dec 2005 has a parellel port, as does the motherboard I
purchased 2008.

I have a 802.11g router (ASUS WL-500g) with a parallel port.  It works
nicely as a remote print server.  From my perspective, that parallel
port isn't going away anytime soon.


<irrelevant aside>
At least the custom firmware for the WL-500g
( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping
pictures and emailing away a notification.  I'm pretty sure PP webcams
are not actually supported though.

The wireless router surveillance case is probably not relevant though,
as routers are usually using (very) old kernels.
</irrelevant aside>

-Andy

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans Verkuil]

> On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:
>
>> > I personally think that loosing support for the parallel port
>> > version is ok given that the parallel port itslef is rapidly
>> > disappearing, what do you think ?
>>
>> I agree wholeheartedly. If we remove pp support, then we can also remove
>> the bw-qcam and c-qcam drivers since they too use the parallel port.
>
> Maybe I just like keeping old hardware up and running, but...
>
> I think it may be better to remove camera drivers when a majority of the
> actual camera hardware is likely to reach EOL, as existing parallel
> ports will likely outlive the cameras.

For sure. But these are really old webcams with correspondingly very poor
resolutions. I haven't been able to track one down on ebay and as far as I
know nobody has one of these beasts to test with. I can't see anyone using
parallel port webcams. I actually wonder whether these drivers still work.
And converting to v4l2 without having the hardware is very hard indeed.

Regards,

         Hans

>
> My PC I got in Dec 2005 has a parellel port, as does the motherboard I
> purchased 2008.
>
> I have a 802.11g router (ASUS WL-500g) with a parallel port.  It works
> nicely as a remote print server.  From my perspective, that parallel
> port isn't going away anytime soon.
>
>
> <irrelevant aside>
> At least the custom firmware for the WL-500g
> ( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping
> pictures and emailing away a notification.  I'm pretty sure PP webcams
> are not actually supported though.
>
> The wireless router surveillance case is probably not relevant though,
> as routers are usually using (very) old kernels.
> </irrelevant aside>
>
> -Andy
>
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 13:26:58 +0200 (CEST)
"Hans Verkuil" <hverkuil@xs4all.nl> escreveu:

> 
> > On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:
> >
> >> > I personally think that loosing support for the parallel port
> >> > version is ok given that the parallel port itslef is rapidly
> >> > disappearing, what do you think ?
> >>
> >> I agree wholeheartedly. If we remove pp support, then we can also remove
> >> the bw-qcam and c-qcam drivers since they too use the parallel port.
> >
> > Maybe I just like keeping old hardware up and running, but...
> >
> > I think it may be better to remove camera drivers when a majority of the
> > actual camera hardware is likely to reach EOL, as existing parallel
> > ports will likely outlive the cameras.

Parallel port will still be there for some time. However, Parallel port webcams
are less common.

> For sure. But these are really old webcams with correspondingly very poor
> resolutions. I haven't been able to track one down on ebay and as far as I
> know nobody has one of these beasts to test with. I can't see anyone using
> parallel port webcams. I actually wonder whether these drivers still work.
> And converting to v4l2 without having the hardware is very hard indeed.

Maybe Alan Cox might still have some of those cams. Some of those old cameras
were used on specialized hardware, like microscopes. Maybe it still could make
sense to support them, but somebody with the hardware should convert to V4L2
and test with the real hardware. Otherwise, I agree that the better is just to
remove the parallel port camera drivers from newer kernels.



Cheers,
Mauro

Re: Convert cpia driver to v4l2, drop parallel port version support?

[Hans Verkuil]

> Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> "Hans Verkuil" <hverkuil@xs4all.nl> escreveu:
>
>> > I recently have been bying second hand usb webcams left and right
>> > one of them (a creative unknown model) uses the cpia1 chipset, and
>> > works with the v4l1 driver currently in the kernel.
>> >
>> > One of these days I would like to convert it to a v4l2 driver using
>> > gspca as basis, this however will cause us to use parallel port
>> support
>> > (that or we need to keep the old code around for the parallel port
>> > version).
>> >
>> > I personally think that loosing support for the parallel port
>> > version is ok given that the parallel port itslef is rapidly
>> > disappearing, what do you think ?
>>
>> I agree wholeheartedly. If we remove pp support, then we can also remove
>> the bw-qcam and c-qcam drivers since they too use the parallel port.
>
> Maybe I'm too nostalgic, but those are the first V4L drivers. It would be
> fun
> to keep supporting them with V4L2 API ;)

I have a pms ISA card and it is still on my list to convert that one to
V4L2. Shouldn't be difficult. It is my understanding that that is the very
first v4l driver, so that should satisfy any nostalgic feelings :-)

> That's said, while it is probably not that hard to develop a gspca-pp
> driver,
> I'm not against removing parallel port support or even removing those
> drivers
> due to technical reasons, like the end of V4L1 drivers.
>
> By looking at the remaining V4L1 drivers, we have:
>
> 	ov511 - already implemented with V4L2 on gspca. Can be easily removed;
>
> 	se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
> 		to convert them to gspca;
>
> 	cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to
> convert them
> 		to vidio_ioctl2 and remove V4L1 API.
>
> 	stradis - a saa7146 V4L1 only driver - I never understood this one well,
> since there is
> 		already another saa7146 driver running V4L2, used by mxb, hexium_gemini
> and
> 		hexium_orion. To make things worse, stradis, mxb and hexium_orion are
> registering for
> 		the same PCI device (the generic saa7146 PCI ID). If nobody volunteers
> to convert
> 		and test with V4L2, then maybe we can just remove it. The better
> conversion would
> 		probably be to use the V4L2 support at the saa7146 driver.
>
> 	arv - seems to be a VGA output driver - Only implements 3 ioctls:
> 		VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it
> to V4L2.
> 		I'm not sure if this is still used in practice.
>
> 	bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io
> and/or parport;
>
> IMO, after having all USB ID's for se401, stv680, usbvideo and vicam
> devices supported
> by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and
> the drivers that
> will still remain using only the legacy API can be dropped. Anything more
> converted will be a bonus

I have a cpia2 device as well that I can use to test.

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Convert cpia driver to v4l2, drop parallel port version support?

[Hans de Goede]

Hi,

I recently have been bying second hand usb webcams left and right
one of them (a creative unknown model) uses the cpia1 chipset, and
works with the v4l1 driver currently in the kernel.

One of these days I would like to convert it to a v4l2 driver using
gspca as basis, this however will cause us to use parallel port support
(that or we need to keep the old code around for the parallel port
version).

I personally think that loosing support for the parallel port
version is ok given that the parallel port itslef is rapidly
disappearing, what do you think ?

Regards,

Hans