public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
	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, 03 Jan 2011 17:20:59 +0100	[thread overview]
Message-ID: <4D21F76B.9000604@redhat.com> (raw)
In-Reply-To: <201101022113.01133.hverkuil@xs4all.nl>

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

  reply	other threads:[~2011-01-03 16:14 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 [this message]
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

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=4D21F76B.9000604@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox