All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
Cc: Jean-Francois Moine <moinejf@free.fr>
Subject: Re: Question about USB interface index restriction in gspca
Date: Mon, 19 Sep 2011 22:13:12 +0200	[thread overview]
Message-ID: <4E77A258.3050806@googlemail.com> (raw)
In-Reply-To: <20110916083302.1deb338e@tele>

Am 16.09.2011 08:33, schrieb Jean-Francois Moine:
> On Thu, 15 Sep 2011 23:46:57 +0200
> Frank Schäfer<fschaefer.oss@googlemail.com>  wrote:
>
>>> For webcam devices, the interface class is meaningful only when set to
>>> USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values.
>> Does that mean that there are devices out in the wild that report for
>> example USB_CLASS_WIRELESS_CONTROLLER for the video interface ???
>>
>>> For video on a particular interface, the subdriver must call the
>>> function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit.
>> Hmm, sure, that would work...
>> But wouldn't it be better to improve the interface check and merge the
>> two probing functions ?
>> The subdrivers can decide which interfaces are (not) probed and the
>> gspca core does plausability checks (e.g. bulk/isoc endpoint ? usb class ?).
> Generally, the first interface is the video device, and the function
> gspca_dev_probe() works well enough.
>
> The function gspca_dev_probe2() is used by only 2 subdrivers and the
> way to find the correct interface is not easy. For example, the webcam
> 047d:5003 (subdriver spca1528) has 3 interfaces (class vendor specific).
> The 1st one has only one altsetting with only one interrupt endpoint,
> the 2nd one has 8 altsettings, each with only one isochronous endpoint,
> and the last one has one altsetting with 3 endpoints (bulk in, bulk out
> and interrupt). At the first glance, it is easy to know the right
> interface, but writing generic code to handle such webcams seems rather
> complicated.
I didn't want to say that it is easy to know the right interface. It is 
definitely not.
But I think we could do it better than we currently do.

Anyway, it seems there is no interest in such a patch.
Thanks for you explanations.

> So, if your webcam is in the 99.99% which use the interface 0, use
> gspca_dev_probe(), otherwise, YOU know the right interface, so, call
> gspca_dev_probe2().
Isn't it also possible that we don't know the right interface and it is 
not interface 0 ? ;-)

Regards,
Frank


  reply	other threads:[~2011-09-19 20:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 19:14 Question about USB interface index restriction in gspca Frank Schäfer
2011-09-14  6:25 ` Jean-Francois Moine
2011-09-15 21:46   ` Frank Schäfer
2011-09-16  6:33     ` Jean-Francois Moine
2011-09-19 20:13       ` Frank Schäfer [this message]
2011-09-21  8:29         ` Jean-Francois Moine

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=4E77A258.3050806@googlemail.com \
    --to=fschaefer.oss@googlemail.com \
    --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.