From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Jean-Francois Moine <moinejf@free.fr>
Subject: Re: RFC: Move the deprecated et61x251 and sn9c102 to staging
Date: Mon, 10 Jan 2011 08:46:19 -0200 [thread overview]
Message-ID: <4D2AE37B.2020105@redhat.com> (raw)
In-Reply-To: <4D2ADF4C.4020709@redhat.com>
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
prev parent reply other threads:[~2011-01-10 10:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-01 19:53 RFC: Move the deprecated et61x251 and sn9c102 to staging Hans Verkuil
2011-01-02 10:41 ` Mauro Carvalho Chehab
2011-01-02 11:25 ` Hans Verkuil
2011-01-02 12:02 ` Jean-Francois Moine
2011-01-02 16:34 ` Hans de Goede
2011-01-02 18:33 ` Hans de Goede
2011-01-02 20:13 ` Hans Verkuil
2011-01-03 16:20 ` Hans de Goede
2011-01-09 12:02 ` Hans de Goede
2011-01-10 1:33 ` Mauro Carvalho Chehab
2011-01-10 10:28 ` Hans de Goede
2011-01-10 10:46 ` Mauro Carvalho Chehab [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2AE37B.2020105@redhat.com \
--to=mchehab@redhat.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=moinejf@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.