Self introduction Hans de Goede and gspcav2
Hans de Goede
Short intro: I'm and have been a Linux developer for more then 10 years now,
including circa 5 years of kernel development.
I'm late;y mainly active as a Fedora developer and writing kernel drivers. My
current Fedora work consists mostly of:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport
As such I've joined Jean-Francois Moine in his very well done job of cleaning
up gspca (a framework for usb webcam drivers support over a 100 cams), porting
it to v4l2 and cleaning it up to make it suitable for upstream inclusion.
Thanks to JF Moine's work, gspcav2 as the new gspca is called has been merged
by Linus for 2.6.27 inclusion, yes!
A short intro about gspca, gspca is a framework for writing usb webcam drivers,
where many things common to all such drivers such as handling of usb isoc
modes, mode negotiation with userspace, buffer management, locking etc. Is all
handled by the gspca core, so that the bridge + sensor specific drivers can
focus on all the cam specific bits, without having to worry about all this.
We call our bridge specific drivers subdrivers.
I'm currently the maintainer of the sonixb subdriver, which stands for sonix
bayer, and is a driver for the sn9c101 sn9c102 and sn9c105 bridges, which all
transpart raw bayer data in their isoc packets (using a custom compression
algorithm, <sigh>).
For my better webcam support project I've bought every cheap webcam I can find,
and as such I also own 1 sn9c20x based cam. I (and Jean Francois too) would
really like to see sn9c20x support added to gspca. So I wonder if you are
interested in rewriting your current driver into a gspca subdriver.
This means less code to worry about, and a very quick path into the mainline
kernel!
###
In order for an sn9c20x driver to be acceptable for the mainline, you will have
to remove the decompression code from the driver and instead pass raw frames to
userspace. Don't worry about application support. gspca had the exact same
problem with many cams having weird custom formats and I've written a userspace
library to transparently handle conversion to normal formats for v4l2 apps, and
even added a v4l1 compatibility layer on top of this. By using this library you
thus get full v4l1 compatibility as an added bonus, and doing decompression in
userspace really is so much easier! This lib can even be used without
recompiling applications by using LD_PRELOAD (tested with skype amongst other
apps).
For some info and a general introduction about this library read:
http://hansdegoede.livejournal.com/3636.html
(a short read)
You can get the latest version of the library either here:
http://linuxtv.org/hg/v4l-dvb
And then under the v4l2-apps/lib/libv4l dir, or (easier) here:
http://people.atrpms.net/~hdegoede/libv4l-0.3.7.tar.gz
If you then add support for decompression raw frames to the libv4lconvert
subdir, then the v4l2 and v4l1 libraries will automatically pick this up.
Note you don't have todo this all at once, you could convert the driver to
gspca and keep the in kernel decompression as a step in between or first move
decompression to userspace with your current driver.
###
I don't have much time to work on this the coming weeks (as I will be writing
patches for most opensource v4l apps to use libv4l without requiring LD_PRELOAD
tricks, and sending those upstream). But I would really like to see this
happen, so I'm available for testing (I must admit I haven't tested your
current driver yet, I guess I better do that first), and answering any
questions about gspca / libv4l you may have.
Thanks & Regards,
Hans
JoJo jojo
I remember sending you an invite to this group in March,
(obviously you were too busy to join)
We (Microdia Group) are mostly "users" of webcams
that have been forced to write a driver to help support our webcam under Linux.
(we tried getting spca/gspca folks to help us but no developer bothered with it)
- Luca R ( SN9C1xx maintainer) had a working driver but refused to
opensource it
- Nicolas V (Syntek author/maintainer) helped us get started(fork).
We had been following your work with gspca, congrats on getting it in shape !
We do plan to get sn9c2xx support into the linux kernel, & we
appreciate any help.
A way forward towards better webcam support in Linux kernel, I would suggest
that the next logical step for you to help SN9C1xx & sn9c3xx webcams
get better support
from gspca.
A lot of users on this group have sn9c1xx/sn9c3xx webcams that don't work yet,
if you have some time to spend, i would much rather that they benefit
from atleast
"some" level of support under Linux.
Also is there any plan to merge Syntek webcam support into GSPCA ?
And btw which Microdia webcam do you have ?
-JoJo
Hans de Goede
> Hi Hans
>
> I remember sending you an invite to this group in March,
> (obviously you were too busy to join)
Erm I've been using this mail address for opensource work now for 9 years, so I
get a lot of mail, also a lot of spam, and a lot of invitations todo who knows
what, so this probably got marked as spam, sorry about that. Well anyways in
the end we've found each other.
> We (Microdia Group) are mostly "users" of webcams
> that have been forced to write a driver to help support our webcam under Linux.
> (we tried getting spca/gspca folks to help us but no developer bothered with it)
I'm sorry to hear that, the old gspca has been loosing momentum a bit lately,
but the new v4l2 gspca which is now in the kernel has both me and JF Moine
spending a lot of time on it. Currently I have a lot of other higher priority
v4l things to do, but when that is done I do plan to start helping the sn9c20x
driver project and port it to gspca subdriver. If some of you could make some
initial movement in that direction that would be great, if not I understand
that too.
> - Luca R ( SN9C1xx maintainer) had a working driver but refused to
> opensource it
I know, he also has not been maintaining his other opensource drivers in any
way lately I'm afraid.
> - Nicolas V (Syntek author/maintainer) helped us get started(fork).
>
I'm not familiar with Nicolas V, not with the Syntek driver.
> We had been following your work with gspca, congrats on getting it in shape !
> We do plan to get sn9c2xx support into the linux kernel, & we
> appreciate any help.
>
As said working on sn9c20x support is somewhere on my roadmap, but it will be
atleast a month probably longer I think before I get around to this (if I'm not
completely fed up with doing webcam drivers by then).
> A way forward towards better webcam support in Linux kernel, I would suggest
> that the next logical step for you to help SN9C1xx
I'm actively working on sn9c101/2/3/5 support, JF Moine is actively working on
other sn9c1xx support (the ones which use jpeg compression). For example I've
added gain, exposure control and autogain+exposure to as number of
sn9c101/2/3/5 bridge/sensors combinations.
If you get any questions for sn9c1xx models please send them to me and JF
Moine, as for sn9c3xx webcams, I didn't even knew those existed, aren't those UVC ?
> A lot of users on this group have sn9c1xx/sn9c3xx webcams that don't work yet,
> if you have some time to spend, i would much rather that they benefit
> from atleast "some" level of support under Linux.
Well if you're one of those sn9c1xx users and are reading this, please try
gspcav2, see:
http://moinejf.free.fr/gspca_README.txt
And then get back to us.
> Also is there any plan to merge Syntek webcam support into GSPCA ?
We would love for as many drivers as possible to become gspca subdrivers, as we
believe having one common core for usb webcams is good, as that allows driver
authors to focus on supporting the cams as best as they can. There are no
plans, but if you can get us in touch with Nicolas V we will do our best to
make this as easy as possible. But currently but JF Moine and I are swamped
with gscpa related "work" already, so what we really need is for driver authors
to jump in and port their drivers their selves.
> And btw which Microdia webcam do you have ?
lsusb says:
Bus 001 Device 004: ID 0c45:62bb Microdia PC Camera with Microphone (SN9C202 +
OV7660)
Thats as far as I got, I bought this for 10 euros in some computer store, to
have another cam to gspca test with and when I saw it was sn9c20x I tossed it
asside. As said I plan on porting your work to gspca, and then I'll be using
this cam to test, but thats for the future.
In the mean time if you want I can run some tests does say what you want me
todo (as long as it doesn't need windows, I currently don't have any windows
machines around, I guess I'll have to get one eventually for this webcam stuff,
but that hasn't happened yet).
Regards,
Hans
JoJo jojo
On Sat, Jul 26, 2008 at 8:43 PM, Hans de Goede <j.w.r....@hhs.nl> wrote:
> JoJo jojo wrote:
>>
>> Hi Hans
>>
>> I remember sending you an invite to this group in March,
>> (obviously you were too busy to join)
>
> Erm I've been using this mail address for opensource work now for 9 years,
> so I get a lot of mail, also a lot of spam, and a lot of invitations todo
> who knows what, so this probably got marked as spam, sorry about that. Well
> anyways in the end we've found each other.
>
np ;-), I just meant to say that you were very busy with gspca.
>
>> We (Microdia Group) are mostly "users" of webcams
>> that have been forced to write a driver to help support our webcam under
>> Linux.
>> (we tried getting spca/gspca folks to help us but no developer bothered
>> with it)
>
> I'm sorry to hear that, the old gspca has been loosing momentum a bit
> lately, but the new v4l2 gspca which is now in the kernel has both me and JF
> Moine spending a lot of time on it. Currently I have a lot of other higher
> priority v4l things to do, but when that is done I do plan to start helping
> the sn9c20x driver project and port it to gspca subdriver. If some of you
> could make some initial movement in that direction that would be great, if
> not I understand that too.
>
We are working on core functionality & also trying to get it into the
kernel currently.
Only the people with the h/w can help workout the functionality, once done
we can try any/all options at your convenience.
>> - Luca R ( SN9C1xx maintainer) had a working driver but refused to
>> opensource it
>
> I know, he also has not been maintaining his other opensource drivers in any
> way lately I'm afraid.
>
He's still signin' off on patches isn't he ?
>> - Nicolas V (Syntek author/maintainer) helped us get started(fork).
>>
>
> I'm not familiar with Nicolas V, not with the Syntek driver.
>
http://lxr.linux.no/linux+v2.6.26/drivers/media/video/stk-webcam.c
>> We had been following your work with gspca, congrats on getting it in
>> shape !
>> We do plan to get sn9c2xx support into the linux kernel, & we
>> appreciate any help.
>>
>
> As said working on sn9c20x support is somewhere on my roadmap, but it will
> be atleast a month probably longer I think before I get around to this (if
> I'm not completely fed up with doing webcam drivers by then).
>
In that case, you better start documenting everything about webcams
before you lose interest !!
Seriously, lack of documentation is one of the limiting factors for all our
webcam driver efforts.
>> A way forward towards better webcam support in Linux kernel, I would
>> suggest
>> that the next logical step for you to help SN9C1xx
>
> I'm actively working on sn9c101/2/3/5 support, JF Moine is actively working
> on other sn9c1xx support (the ones which use jpeg compression). For example
> I've added gain, exposure control and autogain+exposure to as number of
> sn9c101/2/3/5 bridge/sensors combinations.
>
> If you get any questions for sn9c1xx models please send them to me and JF
> Moine, as for sn9c3xx webcams, I didn't even knew those existed, aren't
> those UVC ?
>
No they aren't UVC, else Laurent would have helped us.
https://spreadsheets.google.com/ccc?key=pyuKEu_RW054Jep2-2In1Fg&hl=en
>> A lot of users on this group have sn9c1xx/sn9c3xx webcams that don't work
>> yet,
>> if you have some time to spend, i would much rather that they benefit
>> from atleast "some" level of support under Linux.
>
> Well if you're one of those sn9c1xx users and are reading this, please try
> gspcav2, see:
> http://moinejf.free.fr/gspca_README.txt
>
> And then get back to us.
>
>> Also is there any plan to merge Syntek webcam support into GSPCA ?
>
> We would love for as many drivers as possible to become gspca subdrivers, as
> we believe having one common core for usb webcams is good, as that allows
> driver authors to focus on supporting the cams as best as they can. There
That begs the question, what is the overhead on using your architecture
(some of our users are into embedded applications)
> are no plans, but if you can get us in touch with Nicolas V we will do our
> best to make this as easy as possible. But currently but JF Moine and I are
> swamped with gscpa related "work" already, so what we really need is for
> driver authors to jump in and port their drivers their selves.
>
That helps you validate the work that you have done,
but with the limited time that we have, how does it help our users ?
User's priority is getting a functional driver first, then they may
prefer to have it already
in the kernel tree.
>> And btw which Microdia webcam do you have ?
>
> lsusb says:
> Bus 001 Device 004: ID 0c45:62bb Microdia PC Camera with Microphone (SN9C202
> + OV7660)
>
> Thats as far as I got, I bought this for 10 euros in some computer store, to
> have another cam to gspca test with and when I saw it was sn9c20x I tossed
> it asside. As said I plan on porting your work to gspca, and then I'll be
> using this cam to test, but thats for the future.
>
If you want, we do have ms-windows sniffUSB logs for 62bb here
http://files.zenum.net/microdia/sniffusb_logs/0c45/62bb/
and other webcams here
http://files.zenum.net/microdia/sniffusb_logs/0c45/
We also have a lot of documentation here
https://groups.google.com/group/microdia/web
and here
https://groups.google.com/group/microdia/files
If you can help us improve the documenation that will be super !
> In the mean time if you want I can run some tests does say what you want me
> todo (as long as it doesn't need windows, I currently don't have any windows
> machines around, I guess I'll have to get one eventually for this webcam
> stuff, but that hasn't happened yet).
>
If you want to just test your webcam without the microphone,
you may force your 0c45:62bb webcam to identify as 627b which is supported
get the source here
https://groups.google.com/group/microdia/web/testing-microdia-driver-draft
> Regards,
>
> Hans
>
-JoJo
Hans de Goede
> Hi Hans
>
> kernel currently.
Getting it into the kernel will be much easier through gspca I believe, also
with gspca you loose a lot of stuff to worry about, which allows you to focus
on core functionality much more.
>>> We had been following your work with gspca, congrats on getting it in
>>> shape !
>>> We do plan to get sn9c2xx support into the linux kernel, & we
>>> appreciate any help.
>>>
>> As said working on sn9c20x support is somewhere on my roadmap, but it will
>> be atleast a month probably longer I think before I get around to this (if
>> I'm not completely fed up with doing webcam drivers by then).
>>
> In that case, you better start documenting everything about webcams
> before you lose interest !!
Everything I learn which is not trivial and not documented elsewhere gets
documented through extensive source code comments.
> Seriously, lack of documentation is one of the limiting factors for all our
> webcam driver efforts.
>
I know, its a big pain to not have datasheets.
>> We would love for as many drivers as possible to become gspca subdrivers, as
>> we believe having one common core for usb webcams is good, as that allows
>> driver authors to focus on supporting the cams as best as they can. There
>
> That begs the question, what is the overhead on using your architecture
> (some of our users are into embedded applications)
>
Not much, if any at all, for example gscpa_core + sonixb driver is much smaller
then the sn9c102 driver currently in the mainline kernel.
>> are no plans, but if you can get us in touch with Nicolas V we will do our
>> best to make this as easy as possible. But currently but JF Moine and I are
>> swamped with gscpa related "work" already, so what we really need is for
>> driver authors to jump in and port their drivers their selves.
>>
>
> That helps you validate the work that you have done,
> but with the limited time that we have, how does it help our users ?
usb webcam drivers have 2 hard parts:
1) getting usb isoc setup, interrupt handling, buffer management between kernel
and userspace, including locking and allowing multiple opens as the v4l2
stanard subscribes right and bug free. Add proper usb disconnect handling to
that with proper refcounting!
2) Knowing what to send to the webcam to get it todo certain things and what to
expect.
1) Is something which is shared by all non UVC webcams, by solving this once
and for all gspca frees developer time to work in 2, also since it avoids code
duplication it seriously reduces the chances for bugs to creep in. So gspca (or
rather a generic framework for non UVC webcams) makes for better code and
allows developers to spend more time on supporting new cams, thus it is a
benefit for the end user. Really if you've written usb webcam drivers for 2 or
3 different bridge types, you start getting tired of writing (and maintaining!)
the same code over and over again.
> User's priority is getting a functional driver first, then they may
> prefer to have it already
> in the kernel tree.
>
That depend on your definition of user, only a very small percentage of all
Linux users are capable of installing out of tree drivers.
One last note, if you port the driver to gspcav2 now, we can probably get it
into the mainline for 2.6.27, expanding your tester base enormously which also
is a good thing to do.
Regards,
Hans
Dawid Stawiarski
(http://linuxtv.org/hg/~jfrancois/gspca/file/6ad059fe3782/linux/
drivers/media/video/gspca/sonixj.c and
http://linuxtv.org/hg/~jfrancois/gspca/file/6ad059fe3782/linux/drivers/media/video/gspca/sonixb.c),
I think that it should be quite easy to port microdia to that
architecture. existing drivers are both smaller than 1.5K lines of
code, most of which is the sensors initialization stuff, and parts
that can be threated as a template. For someone who already knows
microdia well (all the workflow, and the registers usage) making
sn9c20x the gspca subdriver wouldn't be that hard. The code would be
smaller, and easier to maintain, and would get faster to the mainline
kernel (which for most users is a big plus).
barbolani
The picture you draw sounds promising, I'd like to try your approach
with the 6260. Could you provide some links that explain how to get
the sources for the gspca?
I've been able to find in this newsgroup everything required to build
and load the microdia module and have at least my cam basic
functionality working. Even started investigating how to make the cam
output different resolutions, but with very little progress and time
devoted lately.
I'm not sure if gspca hacking will be so "simple", so I'd appreciate
pointers for the existing documentation.
harry
about 1 day on non-working solutions. I happen to have an Acer with
"Orbicam" that in fact is a Suyin Microdia 6260 and I was going to
give up, I guess from the above that some almost-working drivers are
ready to be tested. :-))
Note that I'm trying different Linux versions such as Kubuntu and
Mandriva, but I haven't managed to install any program or driver from
scratch yet...