RFC: Move the deprecated et61x251 and sn9c102 to staging

RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans Verkuil]

The subject says it all:

If there are no objections, then I propose that the deprecated et61x251 and
sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.

If there are no objections, then I'll make a patch for this.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Mauro Carvalho Chehab]

Em 01-01-2011 17:53, Hans Verkuil escreveu:
> The subject says it all:
> 
> If there are no objections, then I propose that the deprecated et61x251 and
> sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.

Nack.

There are several USB ID's on sn9c102 not covered by gspca driver yet.

It seems to me that et61x251 will also stay there for a long time, as there are
just two devices supported by gspca driver, while et61x251 supports 25.

Btw, we currently have a conflict with this USB ID:
	USB_DEVICE(0x102c, 0x6151),

Both etoms and et61x251 support it, and there's no #if to disable it on one
driver, if both drivers are compiled. We need to disable it either at gspca_etoms
or at et61x251, in order to avoid users of having a random experience with this
device.

> 
> If there are no objections, then I'll make a patch for this.
> 
> Regards,
> 
> 	Hans
> 
Cheers,
Mauro

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans Verkuil]

On Sunday, January 02, 2011 11:41:31 Mauro Carvalho Chehab wrote:
> Em 01-01-2011 17:53, Hans Verkuil escreveu:
> > The subject says it all:
> > 
> > If there are no objections, then I propose that the deprecated et61x251 and
> > sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.
> 
> Nack.
> 
> There are several USB ID's on sn9c102 not covered by gspca driver yet.

Why are these drivers marked deprecated then?

> It seems to me that et61x251 will also stay there for a long time, as there are
> just two devices supported by gspca driver, while et61x251 supports 25.
> 
> Btw, we currently have a conflict with this USB ID:
> 	USB_DEVICE(0x102c, 0x6151),
> 
> Both etoms and et61x251 support it, and there's no #if to disable it on one
> driver, if both drivers are compiled. We need to disable it either at gspca_etoms
> or at et61x251, in order to avoid users of having a random experience with this
> device.

Surely such devices should be removed from et61x251 or sn9c102 as soon as they are
added to gspca?

Regards,

	Hans

> > 
> > If there are no objections, then I'll make a patch for this.
> > 
> > Regards,
> > 
> > 	Hans
> > 
> Cheers,
> Mauro
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Jean-Francois Moine]

On Sun, 2 Jan 2011 12:25:21 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> > It seems to me that et61x251 will also stay there for a long time,
> > as there are just two devices supported by gspca driver, while
> > et61x251 supports 25.
> > 
> > Btw, we currently have a conflict with this USB ID:
> > 	USB_DEVICE(0x102c, 0x6151),
> > 
> > Both etoms and et61x251 support it, and there's no #if to disable
> > it on one driver, if both drivers are compiled. We need to disable
> > it either at gspca_etoms or at et61x251, in order to avoid users of
> > having a random experience with this device.  
> 
> Surely such devices should be removed from et61x251 or sn9c102 as
> soon as they are added to gspca?

The et61x251 wants to manage all etoms webcams, but only the 102c:6251
is handled (sensor tas5130d1b - the 102c:6151 contains a pas106).
The other USB ID's should be removed from this driver.

About sn9c102, some people say that the sn9c102 is working better than
gspca. Also, both drivers et61x251 and sn9c102 support cropping while
gspca does not.

Regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede]

Hi,

On 01/02/2011 12:25 PM, Hans Verkuil wrote:
> On Sunday, January 02, 2011 11:41:31 Mauro Carvalho Chehab wrote:
>> Em 01-01-2011 17:53, Hans Verkuil escreveu:
>>> The subject says it all:
>>>
>>> If there are no objections, then I propose that the deprecated et61x251 and
>>> sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.
>>
>> Nack.
>>
>> There are several USB ID's on sn9c102 not covered by gspca driver yet.
>
> Why are these drivers marked deprecated then?
>

You'll have to look at me for the deprecation marking.

I did this because they are unmaintained and buggy in some areas and thus really
should go away. Also note that looking at usb-id's is *not* useful with these
drivers as when Luca wrote them he simply included large lists of usb-id's without
the drivers actually being tested with cams with those id's. Usually when a bridge
supports a range of configurable id's, this is used to have one generic (win32)
driver and the usb product id indicates which sensor is used.

I did a patch removing a whole bunch of usb-id's from the sn9c102 driver in the
past as we knew which sensors those id's corresponded with and Luca's driver never
supported these sensors, so the claiming of the usb-id's was bogus.

However for many usb-id's claimed by the sn9c102 driver we don't know what sensor
they belong to (or if any devices with that id exists out there at all), so I left
them in to not cause regressions.

So if we want to see where we stand wrt replacing Luca's old drivers with gspca
subdrivers, you should look at the list of supported sensors.

I've made a list for all sn9c102 supported bridge + sensor combinations and
marked the ones which are not yet supported by gscpa:

sn9c101/102:
hv7131d
mi0343 *
ov7630
pas106b
pas202bcb
tas5110c1b
tas5110d
tas5130d1b

sn9c103:
hv7131r *
mi0360 *
ov7630
pas202bcb

sn9c105/120:
hv7131r
mi0360
mt9v111 *
ov7630
ov7660

So we have 3 models not yet supported in the sonixb driver (and sonixb
cams are quite rare now a days). And 1 model in the sonixj driver.

Note btw that I've disabled all Luca's drivers (et61x251, sn9c102 and
zc0301) in Fedora kernels for several Fedora releases already and sofar
I've received one bug report about this, which is resolved now as I
recently added support for the hv7131d sensor to the sonixb driver
(thanks to said bug report).

So all in all I believe that moving the sn9c102 driver to staging, or
at least remove all usb-id's which are a doublure with gspca's sonixb
and sonixj drivers is the right thing to do.

>> It seems to me that et61x251 will also stay there for a long time, as there are
>> just two devices supported by gspca driver, while et61x251 supports 25.
>>
>> Btw, we currently have a conflict with this USB ID:
>> 	USB_DEVICE(0x102c, 0x6151),
>>
>> Both etoms and et61x251 support it, and there's no #if to disable it on one
>> driver, if both drivers are compiled. We need to disable it either at gspca_etoms
>> or at et61x251, in order to avoid users of having a random experience with this
>> device.
>
> Surely such devices should be removed from et61x251 or sn9c102 as soon as they are
> added to gspca?

The problem is that the initial gspcav2 core + subdrivers as it entered the mainline
is derived from / a partial rewrite of the out of tree v4l1 gspca drivers / framework
as such the register init sequences for bridges + sensors were not all tested when
gspca entered the mainline so in the case of untested bridge + sensor combo's which
were already supported by Luca's mainline drivers, we added #ifdef's to use Luca's
drivers in case both are compiled in. As more and more people tested the gspca drivers
most of these #ifdef's were reversed to prefer the gspca sub drivers if both
were compiled in, one ubs-id at a time.

Looking at both drivers, the gspca one supports both the tas5130 and pas106 sensors,
where as the et61x251 driver only supports the tas5130 sensor. The conflicting usb id
102c:6151 is for a camera with the pas106 sensor, so the solution is to remove this
usb id from the et61x251 driver, as it does not support this id, despite claiming it.

Looking closer at the et61x251 driver, one finds this beauty inside
et61x251_tas5130d1b.c, which is the only sensor module for the et61x251 driver:

int et61x251_probe_tas5130d1b(struct et61x251_device* cam)
{
         const struct usb_device_id tas5130d1b_id_table[] = {
                 { USB_DEVICE(0x102c, 0x6251), },
                 { }
         };

         /* Sensor detection is based on USB pid/vid */
         if (!et61x251_match_id(cam, tas5130d1b_id_table))
                 return -ENODEV;

...

IOW the et61x251 driver, in classical Luca style if I may say so, only supports usb id
102c:6251, despite claiming many many more. So moving forward we should:

1) Remove all bogus usb id's from the et61x251 driver, as trying to use any of these
devices with it will fail, as it won't be able to find a working sensor module
(I thought I did a patch for this once before, but either my memory is failing or
  the patch got lost).

2) Since it then 100% overlaps with the etoms driver, move it to staging

###

I notice that the zc0301 driver is missing from your list to move to staging, it
100% overlaps with the gspca zc3xx driver. And where as the zc0301 driver
only claims to support 2 usb-id's (and 2 sensor types), the gspca zc3xx driver
supports 53 usb id's and 19 sensor types.

Note that the zc3xx bridge is special in that the usb-id does not always uniquely
identify a bridge/sensor combo. One needs to do actual i2c bus probing to figure
out which sensor is attached (like with the ov51x / ovfx2 bridges)...

And the zc0301 driver claims to support the 0ac8:303b, which is a generic
id, which may ship with many types of sensors, including many not supported by
the zc0301 driver, so effectively it only supports 1 usb-id properly.

So the zc0301 driver should be moved to staging too IMHO.

Regards,

Hans

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede]

Hi,

One small correction to the sn9c102 sensor table, the
mt9v111 sensor is handled by sonixj, so the table of
bridge/sensor combi's supported by sn9c102, looks like this:

sn9c101/102:
hv7131d
mi0343 *
ov7630
pas106b
pas202bcb
tas5110c1b
tas5110d
tas5130d1b

sn9c103:
hv7131r *
mi0360 *
ov7630
pas202bcb

sn9c105/120:
hv7131r
mi0360
mt9v111
ov7630
ov7660

So only 3 raw bayer + custom compression models supported by
sn9c102 are not supported by gspca_sonixb, and all jpeg models
are supported by gspca_sonixj. Porting the 3 remaining models
over should be relatively easy, but I (I more or less maintain
the sonixb driver) really need hardware access to ensure things
stay working.

Second correction, I was looking at an old tree and failed to
notice that the zc0301 driver has already bitten the dust
(good!).

Regards,

Hans

On 01/02/2011 05:34 PM, Hans de Goede wrote:
> Hi,
>
> On 01/02/2011 12:25 PM, Hans Verkuil wrote:
>> On Sunday, January 02, 2011 11:41:31 Mauro Carvalho Chehab wrote:
>>> Em 01-01-2011 17:53, Hans Verkuil escreveu:
>>>> The subject says it all:
>>>>
>>>> If there are no objections, then I propose that the deprecated et61x251 and
>>>> sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.
>>>
>>> Nack.
>>>
>>> There are several USB ID's on sn9c102 not covered by gspca driver yet.
>>
>> Why are these drivers marked deprecated then?
>>
>
> You'll have to look at me for the deprecation marking.
>
> I did this because they are unmaintained and buggy in some areas and thus really
> should go away. Also note that looking at usb-id's is *not* useful with these
> drivers as when Luca wrote them he simply included large lists of usb-id's without
> the drivers actually being tested with cams with those id's. Usually when a bridge
> supports a range of configurable id's, this is used to have one generic (win32)
> driver and the usb product id indicates which sensor is used.
>
> I did a patch removing a whole bunch of usb-id's from the sn9c102 driver in the
> past as we knew which sensors those id's corresponded with and Luca's driver never
> supported these sensors, so the claiming of the usb-id's was bogus.
>
> However for many usb-id's claimed by the sn9c102 driver we don't know what sensor
> they belong to (or if any devices with that id exists out there at all), so I left
> them in to not cause regressions.
>
> So if we want to see where we stand wrt replacing Luca's old drivers with gspca
> subdrivers, you should look at the list of supported sensors.
>
> I've made a list for all sn9c102 supported bridge + sensor combinations and
> marked the ones which are not yet supported by gscpa:
>
> sn9c101/102:
> hv7131d
> mi0343 *
> ov7630
> pas106b
> pas202bcb
> tas5110c1b
> tas5110d
> tas5130d1b
>
> sn9c103:
> hv7131r *
> mi0360 *
> ov7630
> pas202bcb
>
> sn9c105/120:
> hv7131r
> mi0360
> mt9v111 *
> ov7630
> ov7660
>
> So we have 3 models not yet supported in the sonixb driver (and sonixb
> cams are quite rare now a days). And 1 model in the sonixj driver.
>
> Note btw that I've disabled all Luca's drivers (et61x251, sn9c102 and
> zc0301) in Fedora kernels for several Fedora releases already and sofar
> I've received one bug report about this, which is resolved now as I
> recently added support for the hv7131d sensor to the sonixb driver
> (thanks to said bug report).
>
> So all in all I believe that moving the sn9c102 driver to staging, or
> at least remove all usb-id's which are a doublure with gspca's sonixb
> and sonixj drivers is the right thing to do.
>
>>> It seems to me that et61x251 will also stay there for a long time, as there are
>>> just two devices supported by gspca driver, while et61x251 supports 25.
>>>
>>> Btw, we currently have a conflict with this USB ID:
>>> USB_DEVICE(0x102c, 0x6151),
>>>
>>> Both etoms and et61x251 support it, and there's no #if to disable it on one
>>> driver, if both drivers are compiled. We need to disable it either at gspca_etoms
>>> or at et61x251, in order to avoid users of having a random experience with this
>>> device.
>>
>> Surely such devices should be removed from et61x251 or sn9c102 as soon as they are
>> added to gspca?
>
> The problem is that the initial gspcav2 core + subdrivers as it entered the mainline
> is derived from / a partial rewrite of the out of tree v4l1 gspca drivers / framework
> as such the register init sequences for bridges + sensors were not all tested when
> gspca entered the mainline so in the case of untested bridge + sensor combo's which
> were already supported by Luca's mainline drivers, we added #ifdef's to use Luca's
> drivers in case both are compiled in. As more and more people tested the gspca drivers
> most of these #ifdef's were reversed to prefer the gspca sub drivers if both
> were compiled in, one ubs-id at a time.
>
> Looking at both drivers, the gspca one supports both the tas5130 and pas106 sensors,
> where as the et61x251 driver only supports the tas5130 sensor. The conflicting usb id
> 102c:6151 is for a camera with the pas106 sensor, so the solution is to remove this
> usb id from the et61x251 driver, as it does not support this id, despite claiming it.
>
> Looking closer at the et61x251 driver, one finds this beauty inside
> et61x251_tas5130d1b.c, which is the only sensor module for the et61x251 driver:
>
> int et61x251_probe_tas5130d1b(struct et61x251_device* cam)
> {
> const struct usb_device_id tas5130d1b_id_table[] = {
> { USB_DEVICE(0x102c, 0x6251), },
> { }
> };
>
> /* Sensor detection is based on USB pid/vid */
> if (!et61x251_match_id(cam, tas5130d1b_id_table))
> return -ENODEV;
>
> ...
>
> IOW the et61x251 driver, in classical Luca style if I may say so, only supports usb id
> 102c:6251, despite claiming many many more. So moving forward we should:
>
> 1) Remove all bogus usb id's from the et61x251 driver, as trying to use any of these
> devices with it will fail, as it won't be able to find a working sensor module
> (I thought I did a patch for this once before, but either my memory is failing or
> the patch got lost).
>
> 2) Since it then 100% overlaps with the etoms driver, move it to staging
>
> ###
>
> I notice that the zc0301 driver is missing from your list to move to staging, it
> 100% overlaps with the gspca zc3xx driver. And where as the zc0301 driver
> only claims to support 2 usb-id's (and 2 sensor types), the gspca zc3xx driver
> supports 53 usb id's and 19 sensor types.
>
> Note that the zc3xx bridge is special in that the usb-id does not always uniquely
> identify a bridge/sensor combo. One needs to do actual i2c bus probing to figure
> out which sensor is attached (like with the ov51x / ovfx2 bridges)...
>
> And the zc0301 driver claims to support the 0ac8:303b, which is a generic
> id, which may ship with many types of sensors, including many not supported by
> the zc0301 driver, so effectively it only supports 1 usb-id properly.
>
> So the zc0301 driver should be moved to staging too IMHO.
>
> Regards,
>
> Hans

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans Verkuil]

Hi Hans,

On Sunday, January 02, 2011 19:33:31 Hans de Goede wrote:
> Hi,
> 
> One small correction to the sn9c102 sensor table, the
> mt9v111 sensor is handled by sonixj, so the table of
> bridge/sensor combi's supported by sn9c102, looks like this:
> 
> sn9c101/102:
> hv7131d
> mi0343 *
> ov7630
> pas106b
> pas202bcb
> tas5110c1b
> tas5110d
> tas5130d1b
> 
> sn9c103:
> hv7131r *
> mi0360 *
> ov7630
> pas202bcb
> 
> sn9c105/120:
> hv7131r
> mi0360
> mt9v111
> ov7630
> ov7660
> 
> So only 3 raw bayer + custom compression models supported by
> sn9c102 are not supported by gspca_sonixb, and all jpeg models
> are supported by gspca_sonixj. Porting the 3 remaining models
> over should be relatively easy, but I (I more or less maintain
> the sonixb driver) really need hardware access to ensure things
> stay working.
> 
> Second correction, I was looking at an old tree and failed to
> notice that the zc0301 driver has already bitten the dust
> (good!).

Thank you for your very helpful answer.

Can you make a patch removing all the bogus usb IDs from these drivers?
And anything else that you think it bogus for that matter. Once that's
done we should see if we will move it to staging.

Based on what you said, I'm in favor of that.

Best regards and a Happy New Year!

	Hans

> 
> Regards,
> 
> Hans
> 
> On 01/02/2011 05:34 PM, Hans de Goede wrote:
> > Hi,
> >
> > On 01/02/2011 12:25 PM, Hans Verkuil wrote:
> >> On Sunday, January 02, 2011 11:41:31 Mauro Carvalho Chehab wrote:
> >>> Em 01-01-2011 17:53, Hans Verkuil escreveu:
> >>>> The subject says it all:
> >>>>
> >>>> If there are no objections, then I propose that the deprecated et61x251 and
> >>>> sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.
> >>>
> >>> Nack.
> >>>
> >>> There are several USB ID's on sn9c102 not covered by gspca driver yet.
> >>
> >> Why are these drivers marked deprecated then?
> >>
> >
> > You'll have to look at me for the deprecation marking.
> >
> > I did this because they are unmaintained and buggy in some areas and thus really
> > should go away. Also note that looking at usb-id's is *not* useful with these
> > drivers as when Luca wrote them he simply included large lists of usb-id's without
> > the drivers actually being tested with cams with those id's. Usually when a bridge
> > supports a range of configurable id's, this is used to have one generic (win32)
> > driver and the usb product id indicates which sensor is used.
> >
> > I did a patch removing a whole bunch of usb-id's from the sn9c102 driver in the
> > past as we knew which sensors those id's corresponded with and Luca's driver never
> > supported these sensors, so the claiming of the usb-id's was bogus.
> >
> > However for many usb-id's claimed by the sn9c102 driver we don't know what sensor
> > they belong to (or if any devices with that id exists out there at all), so I left
> > them in to not cause regressions.
> >
> > So if we want to see where we stand wrt replacing Luca's old drivers with gspca
> > subdrivers, you should look at the list of supported sensors.
> >
> > I've made a list for all sn9c102 supported bridge + sensor combinations and
> > marked the ones which are not yet supported by gscpa:
> >
> > sn9c101/102:
> > hv7131d
> > mi0343 *
> > ov7630
> > pas106b
> > pas202bcb
> > tas5110c1b
> > tas5110d
> > tas5130d1b
> >
> > sn9c103:
> > hv7131r *
> > mi0360 *
> > ov7630
> > pas202bcb
> >
> > sn9c105/120:
> > hv7131r
> > mi0360
> > mt9v111 *
> > ov7630
> > ov7660
> >
> > So we have 3 models not yet supported in the sonixb driver (and sonixb
> > cams are quite rare now a days). And 1 model in the sonixj driver.
> >
> > Note btw that I've disabled all Luca's drivers (et61x251, sn9c102 and
> > zc0301) in Fedora kernels for several Fedora releases already and sofar
> > I've received one bug report about this, which is resolved now as I
> > recently added support for the hv7131d sensor to the sonixb driver
> > (thanks to said bug report).
> >
> > So all in all I believe that moving the sn9c102 driver to staging, or
> > at least remove all usb-id's which are a doublure with gspca's sonixb
> > and sonixj drivers is the right thing to do.
> >
> >>> It seems to me that et61x251 will also stay there for a long time, as there are
> >>> just two devices supported by gspca driver, while et61x251 supports 25.
> >>>
> >>> Btw, we currently have a conflict with this USB ID:
> >>> USB_DEVICE(0x102c, 0x6151),
> >>>
> >>> Both etoms and et61x251 support it, and there's no #if to disable it on one
> >>> driver, if both drivers are compiled. We need to disable it either at gspca_etoms
> >>> or at et61x251, in order to avoid users of having a random experience with this
> >>> device.
> >>
> >> Surely such devices should be removed from et61x251 or sn9c102 as soon as they are
> >> added to gspca?
> >
> > The problem is that the initial gspcav2 core + subdrivers as it entered the mainline
> > is derived from / a partial rewrite of the out of tree v4l1 gspca drivers / framework
> > as such the register init sequences for bridges + sensors were not all tested when
> > gspca entered the mainline so in the case of untested bridge + sensor combo's which
> > were already supported by Luca's mainline drivers, we added #ifdef's to use Luca's
> > drivers in case both are compiled in. As more and more people tested the gspca drivers
> > most of these #ifdef's were reversed to prefer the gspca sub drivers if both
> > were compiled in, one ubs-id at a time.
> >
> > Looking at both drivers, the gspca one supports both the tas5130 and pas106 sensors,
> > where as the et61x251 driver only supports the tas5130 sensor. The conflicting usb id
> > 102c:6151 is for a camera with the pas106 sensor, so the solution is to remove this
> > usb id from the et61x251 driver, as it does not support this id, despite claiming it.
> >
> > Looking closer at the et61x251 driver, one finds this beauty inside
> > et61x251_tas5130d1b.c, which is the only sensor module for the et61x251 driver:
> >
> > int et61x251_probe_tas5130d1b(struct et61x251_device* cam)
> > {
> > const struct usb_device_id tas5130d1b_id_table[] = {
> > { USB_DEVICE(0x102c, 0x6251), },
> > { }
> > };
> >
> > /* Sensor detection is based on USB pid/vid */
> > if (!et61x251_match_id(cam, tas5130d1b_id_table))
> > return -ENODEV;
> >
> > ...
> >
> > IOW the et61x251 driver, in classical Luca style if I may say so, only supports usb id
> > 102c:6251, despite claiming many many more. So moving forward we should:
> >
> > 1) Remove all bogus usb id's from the et61x251 driver, as trying to use any of these
> > devices with it will fail, as it won't be able to find a working sensor module
> > (I thought I did a patch for this once before, but either my memory is failing or
> > the patch got lost).
> >
> > 2) Since it then 100% overlaps with the etoms driver, move it to staging
> >
> > ###
> >
> > I notice that the zc0301 driver is missing from your list to move to staging, it
> > 100% overlaps with the gspca zc3xx driver. And where as the zc0301 driver
> > only claims to support 2 usb-id's (and 2 sensor types), the gspca zc3xx driver
> > supports 53 usb id's and 19 sensor types.
> >
> > Note that the zc3xx bridge is special in that the usb-id does not always uniquely
> > identify a bridge/sensor combo. One needs to do actual i2c bus probing to figure
> > out which sensor is attached (like with the ov51x / ovfx2 bridges)...
> >
> > And the zc0301 driver claims to support the 0ac8:303b, which is a generic
> > id, which may ship with many types of sensors, including many not supported by
> > the zc0301 driver, so effectively it only supports 1 usb-id properly.
> >
> > So the zc0301 driver should be moved to staging too IMHO.
> >
> > Regards,
> >
> > Hans
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede]

Hi,

On 01/02/2011 09:13 PM, Hans Verkuil wrote:
> Hi Hans,
>
> On Sunday, January 02, 2011 19:33:31 Hans de Goede wrote:
>> Hi,
>>
>> One small correction to the sn9c102 sensor table, the
>> mt9v111 sensor is handled by sonixj, so the table of
>> bridge/sensor combi's supported by sn9c102, looks like this:
>>
>> sn9c101/102:
>> hv7131d
>> mi0343 *
>> ov7630
>> pas106b
>> pas202bcb
>> tas5110c1b
>> tas5110d
>> tas5130d1b
>>
>> sn9c103:
>> hv7131r *
>> mi0360 *
>> ov7630
>> pas202bcb
>>
>> sn9c105/120:
>> hv7131r
>> mi0360
>> mt9v111
>> ov7630
>> ov7660
>>
>> So only 3 raw bayer + custom compression models supported by
>> sn9c102 are not supported by gspca_sonixb, and all jpeg models
>> are supported by gspca_sonixj. Porting the 3 remaining models
>> over should be relatively easy, but I (I more or less maintain
>> the sonixb driver) really need hardware access to ensure things
>> stay working.
>>
>> Second correction, I was looking at an old tree and failed to
>> notice that the zc0301 driver has already bitten the dust
>> (good!).
>
> Thank you for your very helpful answer.
>
> Can you make a patch removing all the bogus usb IDs from these drivers?

I've just send a pull request including removal of all the bogus id's
from the et61x251 driver.

The sn9x102 driver is much harder to do, this would require hunting for
windows drivers and then looking inside the .inf files to figure out what
ids which are currently not in gspca could be added. More over the real
gain would be removing support for the jpeg sn9c1xx chips (the 105 and
120 bridge support in sn9c102) as that is completely covered by
gspca_sonixj. But that is not worth the effort given that we want the
entire driver to go away sooner rather then later.

Regards,

Hans

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede]

Hi,

On 01/02/2011 09:13 PM, Hans Verkuil wrote:
> Hi Hans,
>
> On Sunday, January 02, 2011 19:33:31 Hans de Goede wrote:

<snip>

>> So only 3 raw bayer + custom compression models supported by
>> sn9c102 are not supported by gspca_sonixb, and all jpeg models
>> are supported by gspca_sonixj. Porting the 3 remaining models
>> over should be relatively easy, but I (I more or less maintain
>> the sonixb driver) really need hardware access to ensure things
>> stay working.
>>
>> Second correction, I was looking at an old tree and failed to
>> notice that the zc0301 driver has already bitten the dust
>> (good!).
>
> Thank you for your very helpful answer.
>
> Can you make a patch removing all the bogus usb IDs from these drivers?

I've managed to make some time to also sort out the sn9c1xx usb ids
situation.  I've just send a pull request which includes patches cleaning
things up. After this there are only 5 usb-ids left which will default to
sn9c102 when both are compiled in, and only 3 of those are not supported
by gspca.

So if we move the sn9c102 driver to staging we will loose support for
only 3 usb-ids. IOW I think it is time to move it to staging :)

Note I can write a patch to add untested support for these 3 to the
sonixb driver, given my experience with adding support for the hv7131d
based on the sn9c102 code, that should be doable. But it will be
completely untested :(

Regards,

Hans

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Mauro Carvalho Chehab]

Em 09-01-2011 10:02, Hans de Goede escreveu:
> Hi,
> 
> On 01/02/2011 09:13 PM, Hans Verkuil wrote:
>> Hi Hans,
>>
>> On Sunday, January 02, 2011 19:33:31 Hans de Goede wrote:
> 
> <snip>
> 
>>> So only 3 raw bayer + custom compression models supported by
>>> sn9c102 are not supported by gspca_sonixb, and all jpeg models
>>> are supported by gspca_sonixj. Porting the 3 remaining models
>>> over should be relatively easy, but I (I more or less maintain
>>> the sonixb driver) really need hardware access to ensure things
>>> stay working.
>>>
>>> Second correction, I was looking at an old tree and failed to
>>> notice that the zc0301 driver has already bitten the dust
>>> (good!).
>>
>> Thank you for your very helpful answer.
>>
>> Can you make a patch removing all the bogus usb IDs from these drivers?
> 
> I've managed to make some time to also sort out the sn9c1xx usb ids
> situation.  I've just send a pull request which includes patches cleaning
> things up. After this there are only 5 usb-ids left which will default to
> sn9c102 when both are compiled in, and only 3 of those are not supported
> by gspca.

Good!
> 
> So if we move the sn9c102 driver to staging we will loose support for
> only 3 usb-ids. IOW I think it is time to move it to staging :)

This would be a regression.

> Note I can write a patch to add untested support for these 3 to the
> sonixb driver, given my experience with adding support for the hv7131d
> based on the sn9c102 code, that should be doable. But it will be
> completely untested :(

I think that the better would be to add support for it at gspca, but wait for
some feedback before considering it working.

Cheers,
Mauro

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede]

Hi,

On 01/10/2011 02:33 AM, Mauro Carvalho Chehab wrote:
> Em 09-01-2011 10:02, Hans de Goede escreveu:

<snip>

>> I've managed to make some time to also sort out the sn9c1xx usb ids
>> situation.  I've just send a pull request which includes patches cleaning
>> things up. After this there are only 5 usb-ids left which will default to
>> sn9c102 when both are compiled in, and only 3 of those are not supported
>> by gspca.
>
> Good!
>>
>> So if we move the sn9c102 driver to staging we will loose support for
>> only 3 usb-ids. IOW I think it is time to move it to staging :)
>
> This would be a regression.
>

Yes, although I wonder if anyone will notice. Fedora has had the sn9c102
driver disabled for 3 releases now and I've received (and fixed) a single
bug in all that time about a cam not supported by gspca_sonixb which
was supported by sn9c102

>> Note I can write a patch to add untested support for these 3 to the
>> sonixb driver, given my experience with adding support for the hv7131d
>> based on the sn9c102 code, that should be doable. But it will be
>> completely untested :(
>
> I think that the better would be to add support for it at gspca, but wait for
> some feedback before considering it working.

Well I've never seen these cams in the wild. sonixb cams with vga sensors
are quite rare because they cannot do more then 7.5-10 fps. So most cam
makers did the smart thing and went with a sonixj bridge for vga sensors.

Anyways I'll do a gspca patch for adding support for the missing 3 models
(as time permits). And then we can ship that (and make it the default
if both are compiled in) for 1 or 2 cycles before moving the sn9c102 driver
to staging. Assuming we don't receive any negative feedback in those
2 cycles (or manage to fix found bugs).

Regards,

Hans

Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Mauro Carvalho Chehab]

Em 10-01-2011 08:28, Hans de Goede escreveu:
> Hi,
> 
> On 01/10/2011 02:33 AM, Mauro Carvalho Chehab wrote:
>> Em 09-01-2011 10:02, Hans de Goede escreveu:
> 
> <snip>
> 
>>> I've managed to make some time to also sort out the sn9c1xx usb ids
>>> situation.  I've just send a pull request which includes patches cleaning
>>> things up. After this there are only 5 usb-ids left which will default to
>>> sn9c102 when both are compiled in, and only 3 of those are not supported
>>> by gspca.
>>
>> Good!
>>>
>>> So if we move the sn9c102 driver to staging we will loose support for
>>> only 3 usb-ids. IOW I think it is time to move it to staging :)
>>
>> This would be a regression.
>>
> 
> Yes, although I wonder if anyone will notice. Fedora has had the sn9c102
> driver disabled for 3 releases now and I've received (and fixed) a single
> bug in all that time about a cam not supported by gspca_sonixb which
> was supported by sn9c102
> 
>>> Note I can write a patch to add untested support for these 3 to the
>>> sonixb driver, given my experience with adding support for the hv7131d
>>> based on the sn9c102 code, that should be doable. But it will be
>>> completely untested :(
>>
>> I think that the better would be to add support for it at gspca, but wait for
>> some feedback before considering it working.
> 
> Well I've never seen these cams in the wild. sonixb cams with vga sensors
> are quite rare because they cannot do more then 7.5-10 fps. So most cam
> makers did the smart thing and went with a sonixj bridge for vga sensors.
> 
> Anyways I'll do a gspca patch for adding support for the missing 3 models
> (as time permits). And then we can ship that (and make it the default
> if both are compiled in) for 1 or 2 cycles before moving the sn9c102 driver
> to staging. Assuming we don't receive any negative feedback in those
> 2 cycles (or manage to fix found bugs).

It seems perfect to me.
> 
> Regards,
> 
> Hans