working on webcam driver

working on webcam driver

[MK]

Hi.  I'm a fledgling C programmer who just started work on a usb webcam 
driver in order to learn about kernel programming.  So far, all I have 
done is gotten the device to register, and iterated through the 
available interfaces (there are nine with three endpoints each, an iso, 
an interrupt, and a bulk in).  

Anyway, before I proceed, I thought I should clarify for myself "the 
big picture" of what I am doing.  I do not have a webcam that works 
under linux, so the whole apparatus is fuzzy; I am under the impression 
that the kernel modules work with the (seperate) video4linux subsystem? 
I have the USB Video Class Specifications and am busy reading that to 
find out how the camera itself operates, but vis. the linux end of 
things, can you point me to any technical documentation that might 
clarify what the driver will be expected to do?  At this point, I am 
assuming I will have to deliver a device node, but I don't know what 
calls will be made to it etc.

Help and advice is much appreciated.  Of course, best of all would be a 
few general pointers from someone who has actually done this before...

Sincerely, Mark Eriksen

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: working on webcam driver

[Erik Andrén]

2009/5/11 MK <halfcountplus@intergate.com>:
>
> Hi.  I'm a fledgling C programmer who just started work on a usb webcam
> driver in order to learn about kernel programming.  So far, all I have
> done is gotten the device to register, and iterated through the
> available interfaces (there are nine with three endpoints each, an iso,
> an interrupt, and a bulk in).
>
> Anyway, before I proceed, I thought I should clarify for myself "the
> big picture" of what I am doing.  I do not have a webcam that works
> under linux, so the whole apparatus is fuzzy; I am under the impression
> that the kernel modules work with the (seperate) video4linux subsystem?
> I have the USB Video Class Specifications and am busy reading that to
> find out how the camera itself operates, but vis. the linux end of
> things, can you point me to any technical documentation that might
> clarify what the driver will be expected to do?  At this point, I am
> assuming I will have to deliver a device node, but I don't know what
> calls will be made to it etc.
>
> Help and advice is much appreciated.  Of course, best of all would be a
> few general pointers from someone who has actually done this before...
>

Hi Mark,
First of all, this list is deprecated. Send mails to
linux-media@vger.kernel.org if you want to reach the kernel community.

Secondly, have you researched that there is no existing driver for
your camera? A good way to start would perhaps to search for the usb
id and linux in google to see if it generates some hits.

If you don't find any existing driver, you should base your new one on
the gspca framework as it does a lot of the webcam groundwork for you.

Hope this helps,
Erik


> Sincerely, Mark Eriksen
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: working on webcam driver

[MK]

Since I'm cross-posting this (as advised) I should introduce myself by 
saying I am a neophyte C programmer getting into kernel programming by 
trying to write a driver for an unsupported webcam.  So far I've gotten 
the device to register and have enumerated the various interfaces.

On 05/11/2009 02:50:00 PM, Erik Andrén wrote:
>First of all, this list is deprecated. Send mails to
>linux-media@vger.kernel.org if you want to reach the kernel community.
>
> Secondly, have you researched that there is no existing driver for
> your camera? A good way to start would perhaps to search for the usb
> id and linux in google to see if it generates some hits.

I've done this last bit already, and I just checked out gspca.  There 
is a lot of listing for the vendor id, but not the product id, so I 
imagine there is no point in trying any of the drivers (unless I hack 
the source to accept the id string).

However, a rather unhelpful person at the linux driver backport group 
informs me "not all USB video drivers are under
drivers/media/video/usbvideo/  In fact, the majority of them are not." 
but then tells me I should take off and go find them myself "with a web 
browser" (very nice).  

Does anyone know where these drivers are located?  The same person also 
claims that the kernel now has support "for all devices that 
follow the USB video class specification, and [sic] that the additional 
23 device specific drivers in the tree* are just for non-conforming 
devices".  This kind of flies in the face of everything else I have 
read about linux and usb webcams.  I also notice that it is impossible 
to select anything other than the v4l layer with "xconfig", ie. the 
individual drivers cannot be selected.

Is it normal to include module sources in the tree without making it 
possible to configure them into a regular build?

Sincerely, Mark Eriksen

*I can only find the six under drivers/media, and nothing in 
documentation/ is of assistance

Re: working on webcam driver

[Hans de Goede]

On 05/14/2009 06:00 PM, MK wrote:
> Since I'm cross-posting this (as advised) I should introduce myself by
> saying I am a neophyte C programmer getting into kernel programming by
> trying to write a driver for an unsupported webcam.  So far I've gotten
> the device to register and have enumerated the various interfaces.
>
> On 05/11/2009 02:50:00 PM, Erik Andrén wrote:
>> First of all, this list is deprecated. Send mails to
>> linux-media@vger.kernel.org if you want to reach the kernel community.
>>
>> Secondly, have you researched that there is no existing driver for
>> your camera? A good way to start would perhaps to search for the usb
>> id and linux in google to see if it generates some hits.
>
> I've done this last bit already, and I just checked out gspca.  There
> is a lot of listing for the vendor id, but not the product id, so I
> imagine there is no point in trying any of the drivers (unless I hack
> the source to accept the id string).
>
> However, a rather unhelpful person at the linux driver backport group
> informs me "not all USB video drivers are under
> drivers/media/video/usbvideo/  In fact, the majority of them are not."
> but then tells me I should take off and go find them myself "with a web
> browser" (very nice).
>
> Does anyone know where these drivers are located?

Most non yvc (see below) usb webcams are driven through the gspca usb
webcam driver framework. This is a v4l driver which consists of gspca-core
+ various subdrivers for a lot of bridges, see drivers/media/video/gspca


   The same person also
> claims that the kernel now has support "for all devices that
> follow the USB video class specification, and [sic] that the additional
> 23 device specific drivers in the tree* are just for non-conforming
> devices".

This is correct recently the USB consortium (or whatever they are called)
have created a new spec called UVC, this is one standard protocol for all
webcams to follow. All *newer* webcams use this, but a lot of cams still
in the stores predate UVC (which stands for USB Video Class).

The first thing to find out to get your webcam supported is what kind of
bridge chip it is using, try looking at the windows driver .inf file,
typical bridges are the sonix series (often refenced to as sn9c10x or
sn9c20x), spca5xx series, zc3xx, vc032x, etc. If you see a reference
to anything like this in the windows driver .inf file (or inside dll's)
that would be good to know. Also it would be very helpful to have the usb
id of your camera.

Regards,

Hans

Re: working on webcam driver

[Theodore Kilgore]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3858 bytes --]



On Thu, 14 May 2009, Hans de Goede wrote:

> On 05/14/2009 06:00 PM, MK wrote:
>> Since I'm cross-posting this (as advised) I should introduce myself by
>> saying I am a neophyte C programmer getting into kernel programming by
>> trying to write a driver for an unsupported webcam.  So far I've gotten
>> the device to register and have enumerated the various interfaces.
>> 
>> On 05/11/2009 02:50:00 PM, Erik Andrén wrote:
>>> First of all, this list is deprecated. Send mails to
>>> linux-media@vger.kernel.org if you want to reach the kernel community.
>>> 
>>> Secondly, have you researched that there is no existing driver for
>>> your camera? A good way to start would perhaps to search for the usb
>>> id and linux in google to see if it generates some hits.
>> 
>> I've done this last bit already, and I just checked out gspca.  There
>> is a loit of listing for the vendor id, but not the product id, so I
>> imagine there is no point in trying any of the drivers (unless I hack
>> the source to accept the id string).
>> 
>> However, a rather unhelpful person at the linux driver backport group
>> informs me "not all USB video drivers are under
>> drivers/media/video/usbvideo/  In fact, the majority of them are not."
>> but then tells me I should take off and go find them myself "with a web
>> browser" (very nice).
>> 
>> Does anyone know where these drivers are located?
>
> Most non yvc (see below) usb webcams are driven through the gspca usb
> webcam driver framework. This is a v4l driver which consists of gspca-core
> + various subdrivers for a lot of bridges, see drivers/media/video/gspca
>
>
>  The same person also
>> claims that the kernel now has support "for all devices that
>> follow the USB video class specification, and [sic] that the additional
>> 23 device specific drivers in the tree* are just for non-conforming
>> devices".
>
> This is correct recently the USB consortium (or whatever they are called)
> have created a new spec called UVC, this is one standard protocol for all
> webcams to follow. All *newer* webcams use this, but a lot of cams still
> in the stores predate UVC (which stands for USB Video Class).
>
> The first thing to find out to get your webcam supported is what kind of
> bridge chip it is using, try looking at the windows driver .inf file,
> typical bridges are the sonix series (often refenced to as sn9c10x or
> sn9c20x), spca5xx series, zc3xx, vc032x, etc. If you see a reference
> to anything like this in the windows driver .inf file (or inside dll's)
> that would be good to know. Also it would be very helpful to have the usb
> id of your camera.
>
> Regards,
>
> Hans

All of the above is excellent advice, especially in view of the fact that 
you say, "There is a lot of listing for the vendor id, but not the product 
id, so I imagine there is no point in trying any of the drivers (unless I 
hack the source to accept the id string)," apparently with reference to 
the cameras supported by gspca.

>From there, things could go in several directions. First, it might 
possibly be the case that it suffices only to add the camera's Vendor and 
Product ID to an existing driver. Or, it might be a completely different 
one. Or, it might be that everything can be solved but for the fact that 
the camera is using an undocumented and unsolved compression algorithm, 
which is the ultimate obstacle to overcome and also the most difficult. 
Perhaps in addition to the list from Hans, above, an output of lsusb or 
the content of the /proc/bus/usb/devices file (available if your kernel 
supports usbfs, otherwise not) would help.

Finally, since you say that the Vendor ID appears, it could possibly be 
the case that someone is already working on support for your particular 
camera. The matter would be more clear if the Vendor and Product ID 
numbers are known.


Theodore Kilgore

Re: working on webcam driver

[MK]

Thanks much for the feedback!  Here's what happened:

Because the vendor id (0c45) is listed by the gspca website but not 
the product (612a), I decided to try inserting the id into one of the 
drivers/media/video/gspca.  When I actually grepped (had not grepped 
the tree itself yet), low and behold 612a is in sonixj.  The module 
compiles and responds to the camera, although the results in gstreamer, 
et. al, are disappointing -- the camera is not really usable, I suspect 
from the output it is the kernel driver, but I am not sure.  Since I 
didn't write this stuff, I think working alone it will be more trouble 
than it is worth to track the problem down, esp. if this is mostly a 
problem with an (obscure) inexpensive item that few linux users 
actually possess.

So, I am going to cut my "loses" early on this project and cop out.  
I've learned a bunch about the kernel and in the process written some 
nifty little char drivers that are probably more useful to me than a 
webcam anyway. I think my time would be better spent on other things, 
eg, I might become useful in someone else's (more significant) linux 
kernel/driver project.  I will have a look around.

But thanks again!  You were much nicer than mr Greg Kroah-Hartman ;) :0

Sincerely, Mark Eriksen (getting his feet wet)

Re: working on webcam driver

[leandro Costantino]

Hi Mark,
just searching "0c45:612a gspca" could save you lot of time.
I suppose you were looking at the old gspca homepage, because it
listed on Jean F. Moine site
http://moinejf.free.fr/webcam.html ( it dont know even it that page if
still updated )

About the "gstreamer", what kind of troubles are you having?. It's the
webcam streaming?
Did you follow the steps using libv4lconvert?.

I wrote that patch a year ago, so , if there's any problem let me know.
If you need help, about the lib4vlconvert thing, look at deaglecito.blogspot.com

Best Regards
Costantino Leandro

On Sun, May 17, 2009 at 12:08 PM, MK <halfcountplus@intergate.com> wrote:
> Thanks much for the feedback!  Here's what happened:
>
> Because the vendor id (0c45) is listed by the gspca website but not
> the product (612a), I decided to try inserting the id into one of the
> drivers/media/video/gspca.  When I actually grepped (had not grepped
> the tree itself yet), low and behold 612a is in sonixj.  The module
> compiles and responds to the camera, although the results in gstreamer,
> et. al, are disappointing -- the camera is not really usable, I suspect
> from the output it is the kernel driver, but I am not sure.  Since I
> didn't write this stuff, I think working alone it will be more trouble
> than it is worth to track the problem down, esp. if this is mostly a
> problem with an (obscure) inexpensive item that few linux users
> actually possess.
>
> So, I am going to cut my "loses" early on this project and cop out.
> I've learned a bunch about the kernel and in the process written some
> nifty little char drivers that are probably more useful to me than a
> webcam anyway. I think my time would be better spent on other things,
> eg, I might become useful in someone else's (more significant) linux
> kernel/driver project.  I will have a look around.
>
> But thanks again!  You were much nicer than mr Greg Kroah-Hartman ;) :0
>
> Sincerely, Mark Eriksen (getting his feet wet)
>
>
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>

What is libv4lconvert/sn9c202x.c for?

[Theodore Kilgore]

I can not seem to be able to find any such devices which use this. So 
perhaps I am not looking in the right place and someone could point me 
there.

In any event, it appears to me to have absolutely nothing at all to do 
with the decompression algorithm required by the SN9C2028 cameras. Those 
require a differential Huffman encoding scheme similar to what is in use 
for the MR97310a cameras, but with a few crucial differencew which make it 
pretty much impossible to write one routine for both. But the code in the 
file libv4lconvert/sn9c202x.c appears to me to be no differential Huffman 
scheme at all but something entirely different.

Hence my question.

Theodore Kilgore

Re: What is libv4lconvert/sn9c202x.c for?

[Hans de Goede]

On 05/19/2009 10:35 PM, Theodore Kilgore wrote:
>
> I can not seem to be able to find any such devices which use this. So
> perhaps I am not looking in the right place and someone could point me
> there.
>
> In any event, it appears to me to have absolutely nothing at all to do
> with the decompression algorithm required by the SN9C2028 cameras. Those
> require a differential Huffman encoding scheme similar to what is in use
> for the MR97310a cameras, but with a few crucial differencew which make
> it pretty much impossible to write one routine for both. But the code in
> the file libv4lconvert/sn9c202x.c appears to me to be no differential
> Huffman scheme at all but something entirely different.
>
> Hence my question.

This is for the (not yet in the mainline kernel) sn9c20x driver, just like
there is a series of sn9c10x webcam bridges from sonix there also is a serie
of 2n9c20x, these can do jpeg compression, but also their own custom
(less CPU the decompress) YUV based compression, which is supported by libv4l,
and that is what is in the sn9c20x.c file, also note the file is called
sn9c20x.c not sn9c202x.c, iow this is completely unrelated to the sn9c2028
cameras, as this is not for sn9c202x but for sn9c20x .

Hope this helps to clarify things.

Regards,

Hans


p.s.

The sn9c20x driver can be found here:
https://groups.google.com/group/microdia

Its developers are quite active I wish they would get it merged into the
mainline (and preferably first converted to a gspca subdriver, I'm not saying
gspca is perfect, but it does safe a lot of code duplication).

Re: What is libv4lconvert/sn9c202x.c for?

[Theodore Kilgore]

On Wed, 20 May 2009, Hans de Goede wrote:

>
>
> On 05/19/2009 10:35 PM, Theodore Kilgore wrote:
>> 
>> I can not seem to be able to find any such devices which use this. So
>> perhaps I am not looking in the right place and someone could point me
>> there.
>> 
>> In any event, it appears to me to have absolutely nothing at all to do
>> with the decompression algorithm required by the SN9C2028 cameras. Those
>> require a differential Huffman encoding scheme similar to what is in use
>> for the MR97310a cameras, but with a few crucial differencew which make
>> it pretty much impossible to write one routine for both. But the code in
>> the file libv4lconvert/sn9c202x.c appears to me to be no differential
>> Huffman scheme at all but something entirely different.
>> 
>> Hence my question.
>
> This is for the (not yet in the mainline kernel) sn9c20x driver, just like
> there is a series of sn9c10x webcam bridges from sonix there also is a serie
> of 2n9c20x, these can do jpeg compression, but also their own custom
> (less CPU the decompress) YUV based compression, which is supported by 
> libv4l,
> and that is what is in the sn9c20x.c file, also note the file is called
> sn9c20x.c not sn9c202x.c, iow this is completely unrelated to the sn9c2028
> cameras, as this is not for sn9c202x but for sn9c20x .
>
> Hope this helps to clarify things.
>
> Regards,
>
> Hans
>
>
> p.s.
>
> The sn9c20x driver can be found here:
> https://groups.google.com/group/microdia
>
> Its developers are quite active I wish they would get it merged into the
> mainline (and preferably first converted to a gspca subdriver, I'm not saying
> gspca is perfect, but it does safe a lot of code duplication).
>

Yes, that does help. I called the new libv4lconvert file by the name 
sn9c2028-decomp.c and that should avoid any possible name collision. But 
it was indeed rather strange to see that the sn9c20x is in libv4lconvert 
and it seems not to be in the drivers/media tree anywhere. Thanks again 
for explaining.

Theodore Kilgore

[PATCH] to libv4lconvert, to do decompression for sn9c2028 cameras

[Theodore Kilgore]

The purpose of the following patch is to do the decompression for the 
Sonix SN9C2028 cameras, which are already supported as still cameras in 
libgphoto2/camlibs/sonix. The decompression code is essentially identical 
to that which is used in the libgphoto2 driver, with minor changes to 
adapt it for libv4lconvert.

The history and antecedents of this algorithm are described in 
libgphoto2/camlibs/sonix/README.sonix, which was Copyright (C) 2005 
Theodore Kilgore <kilgota@auburn.edu>, as follows:

"The decompression algorithm originates, I understand, in the work of 
Bertrik Sikkens for the sn9c102 cameras. In the macam project for MacOS-X 
camera support (webcam-osx project on Sourceforge), the decompression 
algorithm for the sn9c2028 cameras was developed by Mattias Krauss and 
adapted for use with the Vivitar Vivicam 3350B in particular by Harald 
Ruda <hrx at users.sourceforge.net>. Harald brought to my attention the 
work already done in the macam project, pointed out that it is GPL code, 
and invited me to have a look. Thanks, Harald. The decompression algorithm 
used here is similar to what is used in the macam driver, but is 
considerably streamlined and improved."

Signed-off-by Theodore Kilgore <kilgota@auburn.edu>

-----------------------------------------------------------------------
diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/Makefile
--- a/v4l2-apps/libv4l/libv4lconvert/Makefile	Wed May 20 07:23:00 2009 +0200
+++ b/v4l2-apps/libv4l/libv4lconvert/Makefile	Wed May 20 13:10:53 2009 -0500
@@ -14,7 +14,7 @@

  CONVERT_OBJS  = libv4lconvert.o tinyjpeg.o sn9c10x.o sn9c20x.o pac207.o \
  		mr97310a.o flip.o crop.o jidctflt.o spca561-decompress.o \
-		rgbyuv.o spca501.o sq905c.o bayer.o hm12.o \
+		rgbyuv.o sn9c2028-decomp.o spca501.o sq905c.o bayer.o hm12.o \
  		control/libv4lcontrol.o processing/libv4lprocessing.o \
  		processing/rgbprocessing.o processing/bayerprocessing.o
  TARGETS       = $(CONVERT_LIB) libv4lconvert.pc
diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h	Wed May 20 07:23:00 2009 +0200
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h	Wed May 20 13:10:53 2009 -0500
@@ -51,6 +51,10 @@
  #define V4L2_PIX_FMT_MR97310A v4l2_fourcc('M','3','1','0')
  #endif

+#ifndef V4L2_PIX_FMT_SN9C2028
+#define V4L2_PIX_FMT_SN9C2028 v4l2_fourcc('S', 'O', 'N', 'X')
+#endif
+
  #ifndef V4L2_PIX_FMT_SQ905C
  #define V4L2_PIX_FMT_SQ905C v4l2_fourcc('9', '0', '5', 'C')
  #endif
@@ -193,6 +197,9 @@
  void v4lconvert_decode_mr97310a(const unsigned char *src, unsigned char *dst,
    int width, int height);

+void v4lconvert_decode_sn9c2028(const unsigned char *src, unsigned char *dst,
+  int width, int height);
+
  void v4lconvert_decode_sq905c(const unsigned char *src, unsigned char *dst,
    int width, int height);

diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
--- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c	Wed May 20 07:23:00 2009 +0200
+++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c	Wed May 20 13:10:53 2009 -0500
@@ -60,6 +60,7 @@
    { V4L2_PIX_FMT_JPEG,         V4LCONVERT_COMPRESSED },
    { V4L2_PIX_FMT_SPCA561,      V4LCONVERT_COMPRESSED },
    { V4L2_PIX_FMT_SN9C10X,      V4LCONVERT_COMPRESSED },
+  { V4L2_PIX_FMT_SN9C2028,     V4LCONVERT_COMPRESSED },
    { V4L2_PIX_FMT_PAC207,       V4LCONVERT_COMPRESSED },
    { V4L2_PIX_FMT_MR97310A,     V4LCONVERT_COMPRESSED },
    { V4L2_PIX_FMT_SQ905C,       V4LCONVERT_COMPRESSED },
@@ -460,6 +461,7 @@
      case V4L2_PIX_FMT_SN9C10X:
      case V4L2_PIX_FMT_PAC207:
      case V4L2_PIX_FMT_MR97310A:
+    case V4L2_PIX_FMT_SN9C2028:
      case V4L2_PIX_FMT_SQ905C:
      case V4L2_PIX_FMT_SBGGR8:
      case V4L2_PIX_FMT_SGBRG8:
@@ -672,6 +674,7 @@
      case V4L2_PIX_FMT_SN9C10X:
      case V4L2_PIX_FMT_PAC207:
      case V4L2_PIX_FMT_MR97310A:
+    case V4L2_PIX_FMT_SN9C2028:
      case V4L2_PIX_FMT_SQ905C:
      {
        unsigned char *tmpbuf;
@@ -699,6 +702,10 @@
  	  v4lconvert_decode_mr97310a(src, tmpbuf, width, height);
  	  tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SBGGR8;
  	  break;
+	case V4L2_PIX_FMT_SN9C2028:
+	  v4lconvert_decode_sn9c2028(src, tmpbuf, width, height);
+	  src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
+	  break;
  	case V4L2_PIX_FMT_SQ905C:
  	  v4lconvert_decode_sq905c(src, tmpbuf, width, height);
  	  tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SRGGB8;
diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/sn9c2028-decomp.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/v4l2-apps/libv4l/libv4lconvert/sn9c2028-decomp.c	Wed May 20 13:10:53 2009 -0500
@@ -0,0 +1,158 @@
+/*
+ * sn9c2028-decomp.c
+ *
+ * Decompression function for the Sonix SN9C2028 dual-mode cameras.
+ *
+ * Code adapted from libgphoto2/camlibs/sonix, original version of which was
+ * Copyright (c) 2005 Theodore Kilgore <kilgota@auburn.edu>
+ *
+ * History:
+ *
+ * This decoding algorithm originates from the work of Bertrik Sikken for the
+ * SN9C102 cameras. This version is an adaptation of work done by Mattias
+ * Krauss for the webcam-osx (macam) project. There, it was further adapted
+ * for use with the Vivitar Vivicam 3350B (an SN9C2028 camera) by
+ * Harald Ruda <hrx@users.sourceforge.net>. Harald brought to my attention the
+ * work done in the macam project and suggested that I use it. The
+ * macam project is also licensed under the GPL. One improvement of my own
+ * was to notice that the even and odd columns of the image have been reversed
+ * by the decompression algorithm, and this needs to be corrected during the
+ * decompression.
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ */
+
+#include "libv4lconvert-priv.h"
+
+/* Four defines for bitstream operations, used in the decode function */
+
+#define PEEK_BITS(num,to) {\
+	if (bitBufCount < num) {\
+		do {\
+			bitBuf = (bitBuf << 8)|(*(src++));\
+			bitBufCount += 8; \
+		} \
+		while\
+			(bitBufCount < 24);\
+	} \
+	to = bitBuf >> (bitBufCount-num);\
+}
+
+/*
+ * PEEK_BITS puts the next <num> bits into the low bits of <to>.
+ * when the buffer is empty, it is completely refilled.
+ * This strategy tries to reduce memory access. Note that the high bits
+ * are NOT set to zero!
+ */
+
+#define EAT_BITS(num) { bitBufCount -= num; bits_eaten += num; }
+
+/*
+ * EAT_BITS consumes <num> bits (PEEK_BITS does not consume anything,
+ * it just peeks)
+ */
+
+#define PARSE_PIXEL(val) {\
+	PEEK_BITS(10, bits);\
+	if ((bits&0x200) == 0) {\
+		EAT_BITS(1);\
+	} \
+	else if ((bits&0x380) == 0x280) {\
+		EAT_BITS(3);\
+		val += 3;\
+		if (val > 255)\
+			val = 255;\
+	} \
+	else if ((bits&0x380) == 0x300) {\
+		EAT_BITS(3);\
+		val -= 3;\
+		if (val < 0)\
+			val = 0;\
+	} \
+	else if ((bits&0x3c0) == 0x200) {\
+		EAT_BITS(4);\
+		val += 8;\
+		if (val > 255)\
+			val = 255;\
+	} \
+	else if ((bits&0x3c0) == 0x240) {\
+		EAT_BITS(4);\
+		val -= 8;\
+		if (val < 0)\
+			val = 0;\
+	} \
+	else if ((bits&0x3c0) == 0x3c0) {\
+		EAT_BITS(4);\
+		val -= 20;\
+		if (val < 0)\
+			val = 0;\
+	} \
+	else if ((bits&0x3e0) == 0x380) {\
+		EAT_BITS(5);\
+		val += 20;\
+		if (val > 255)\
+			val = 255;\
+	} \
+	else {\
+		EAT_BITS(10);\
+		val = 8*(bits&0x1f)+0;\
+	} \
+}
+
+
+#define PUT_PIXEL_PAIR {\
+    long pp;\
+    pp = (c1val<<8)+c2val;\
+    *((unsigned short *) (dst+dst_index)) = pp;\
+    dst_index += 2;\
+}
+
+/* Now the decode function itself */
+
+void v4lconvert_decode_sn9c2028(const unsigned char *src, unsigned char *dst,
+  int width, int height)
+{
+	long dst_index = 0;
+	int starting_row = 0;
+	unsigned short bits;
+	short c1val, c2val;
+	int x, y;
+	unsigned long bitBuf = 0;
+	unsigned long bitBufCount = 0;
+	unsigned long bits_eaten = 0;
+
+	src += 12;	/* Remove the header */
+
+	for (y = starting_row; y < height; y++) {
+		PEEK_BITS(8, bits);
+		EAT_BITS(8);
+		c2val = (bits & 0xff);
+		PEEK_BITS(8, bits);
+		EAT_BITS(8);
+		c1val = (bits & 0xff);
+
+		PUT_PIXEL_PAIR;
+
+		for (x = 2; x < width ; x += 2) {
+			/* The compression reversed the even and odd columns.*/
+			PARSE_PIXEL(c2val);
+			PARSE_PIXEL(c1val);
+			PUT_PIXEL_PAIR;
+		}
+	}
+}

Re: [PATCH] to libv4lconvert, to do decompression for sn9c2028 cameras

[Hans de Goede]

Hi,

Thanks for the patch, but I see one big issue with this patch,
the decompression algorithm is GPL, where as libv4l is LGPL.

Any chance you could get this relicensed to LGPL ?

Regards,

Hans


On 05/24/2009 12:12 AM, Theodore Kilgore wrote:
>
> The purpose of the following patch is to do the decompression for the
> Sonix SN9C2028 cameras, which are already supported as still cameras in
> libgphoto2/camlibs/sonix. The decompression code is essentially
> identical to that which is used in the libgphoto2 driver, with minor
> changes to adapt it for libv4lconvert.
>
> The history and antecedents of this algorithm are described in
> libgphoto2/camlibs/sonix/README.sonix, which was Copyright (C) 2005
> Theodore Kilgore <kilgota@auburn.edu>, as follows:
>
> "The decompression algorithm originates, I understand, in the work of
> Bertrik Sikkens for the sn9c102 cameras. In the macam project for
> MacOS-X camera support (webcam-osx project on Sourceforge), the
> decompression algorithm for the sn9c2028 cameras was developed by
> Mattias Krauss and adapted for use with the Vivitar Vivicam 3350B in
> particular by Harald Ruda <hrx at users.sourceforge.net>. Harald brought
> to my attention the work already done in the macam project, pointed out
> that it is GPL code, and invited me to have a look. Thanks, Harald. The
> decompression algorithm used here is similar to what is used in the
> macam driver, but is considerably streamlined and improved."
>
> Signed-off-by Theodore Kilgore <kilgota@auburn.edu>
>
> -----------------------------------------------------------------------
> diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/Makefile
> --- a/v4l2-apps/libv4l/libv4lconvert/Makefile Wed May 20 07:23:00 2009
> +0200
> +++ b/v4l2-apps/libv4l/libv4lconvert/Makefile Wed May 20 13:10:53 2009
> -0500
> @@ -14,7 +14,7 @@
>
> CONVERT_OBJS = libv4lconvert.o tinyjpeg.o sn9c10x.o sn9c20x.o pac207.o \
> mr97310a.o flip.o crop.o jidctflt.o spca561-decompress.o \
> - rgbyuv.o spca501.o sq905c.o bayer.o hm12.o \
> + rgbyuv.o sn9c2028-decomp.o spca501.o sq905c.o bayer.o hm12.o \
> control/libv4lcontrol.o processing/libv4lprocessing.o \
> processing/rgbprocessing.o processing/bayerprocessing.o
> TARGETS = $(CONVERT_LIB) libv4lconvert.pc
> diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
> --- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h Wed May 20
> 07:23:00 2009 +0200
> +++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h Wed May 20
> 13:10:53 2009 -0500
> @@ -51,6 +51,10 @@
> #define V4L2_PIX_FMT_MR97310A v4l2_fourcc('M','3','1','0')
> #endif
>
> +#ifndef V4L2_PIX_FMT_SN9C2028
> +#define V4L2_PIX_FMT_SN9C2028 v4l2_fourcc('S', 'O', 'N', 'X')
> +#endif
> +
> #ifndef V4L2_PIX_FMT_SQ905C
> #define V4L2_PIX_FMT_SQ905C v4l2_fourcc('9', '0', '5', 'C')
> #endif
> @@ -193,6 +197,9 @@
> void v4lconvert_decode_mr97310a(const unsigned char *src, unsigned char
> *dst,
> int width, int height);
>
> +void v4lconvert_decode_sn9c2028(const unsigned char *src, unsigned char
> *dst,
> + int width, int height);
> +
> void v4lconvert_decode_sq905c(const unsigned char *src, unsigned char *dst,
> int width, int height);
>
> diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c
> --- a/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c Wed May 20 07:23:00
> 2009 +0200
> +++ b/v4l2-apps/libv4l/libv4lconvert/libv4lconvert.c Wed May 20 13:10:53
> 2009 -0500
> @@ -60,6 +60,7 @@
> { V4L2_PIX_FMT_JPEG, V4LCONVERT_COMPRESSED },
> { V4L2_PIX_FMT_SPCA561, V4LCONVERT_COMPRESSED },
> { V4L2_PIX_FMT_SN9C10X, V4LCONVERT_COMPRESSED },
> + { V4L2_PIX_FMT_SN9C2028, V4LCONVERT_COMPRESSED },
> { V4L2_PIX_FMT_PAC207, V4LCONVERT_COMPRESSED },
> { V4L2_PIX_FMT_MR97310A, V4LCONVERT_COMPRESSED },
> { V4L2_PIX_FMT_SQ905C, V4LCONVERT_COMPRESSED },
> @@ -460,6 +461,7 @@
> case V4L2_PIX_FMT_SN9C10X:
> case V4L2_PIX_FMT_PAC207:
> case V4L2_PIX_FMT_MR97310A:
> + case V4L2_PIX_FMT_SN9C2028:
> case V4L2_PIX_FMT_SQ905C:
> case V4L2_PIX_FMT_SBGGR8:
> case V4L2_PIX_FMT_SGBRG8:
> @@ -672,6 +674,7 @@
> case V4L2_PIX_FMT_SN9C10X:
> case V4L2_PIX_FMT_PAC207:
> case V4L2_PIX_FMT_MR97310A:
> + case V4L2_PIX_FMT_SN9C2028:
> case V4L2_PIX_FMT_SQ905C:
> {
> unsigned char *tmpbuf;
> @@ -699,6 +702,10 @@
> v4lconvert_decode_mr97310a(src, tmpbuf, width, height);
> tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SBGGR8;
> break;
> + case V4L2_PIX_FMT_SN9C2028:
> + v4lconvert_decode_sn9c2028(src, tmpbuf, width, height);
> + src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
> + break;
> case V4L2_PIX_FMT_SQ905C:
> v4lconvert_decode_sq905c(src, tmpbuf, width, height);
> tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SRGGB8;
> diff -r 276a90c8ac40 v4l2-apps/libv4l/libv4lconvert/sn9c2028-decomp.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/v4l2-apps/libv4l/libv4lconvert/sn9c2028-decomp.c Wed May 20
> 13:10:53 2009 -0500
> @@ -0,0 +1,158 @@
> +/*
> + * sn9c2028-decomp.c
> + *
> + * Decompression function for the Sonix SN9C2028 dual-mode cameras.
> + *
> + * Code adapted from libgphoto2/camlibs/sonix, original version of
> which was
> + * Copyright (c) 2005 Theodore Kilgore <kilgota@auburn.edu>
> + *
> + * History:
> + *
> + * This decoding algorithm originates from the work of Bertrik Sikken
> for the
> + * SN9C102 cameras. This version is an adaptation of work done by Mattias
> + * Krauss for the webcam-osx (macam) project. There, it was further
> adapted
> + * for use with the Vivitar Vivicam 3350B (an SN9C2028 camera) by
> + * Harald Ruda <hrx@users.sourceforge.net>. Harald brought to my
> attention the
> + * work done in the macam project and suggested that I use it. The
> + * macam project is also licensed under the GPL. One improvement of my own
> + * was to notice that the even and odd columns of the image have been
> reversed
> + * by the decompression algorithm, and this needs to be corrected
> during the
> + * decompression.
> + *
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; if not, write to the
> + * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> + * Boston, MA 02111-1307, USA.
> + */
> +
> +#include "libv4lconvert-priv.h"
> +
> +/* Four defines for bitstream operations, used in the decode function */
> +
> +#define PEEK_BITS(num,to) {\
> + if (bitBufCount < num) {\
> + do {\
> + bitBuf = (bitBuf << 8)|(*(src++));\
> + bitBufCount += 8; \
> + } \
> + while\
> + (bitBufCount < 24);\
> + } \
> + to = bitBuf >> (bitBufCount-num);\
> +}
> +
> +/*
> + * PEEK_BITS puts the next <num> bits into the low bits of <to>.
> + * when the buffer is empty, it is completely refilled.
> + * This strategy tries to reduce memory access. Note that the high bits
> + * are NOT set to zero!
> + */
> +
> +#define EAT_BITS(num) { bitBufCount -= num; bits_eaten += num; }
> +
> +/*
> + * EAT_BITS consumes <num> bits (PEEK_BITS does not consume anything,
> + * it just peeks)
> + */
> +
> +#define PARSE_PIXEL(val) {\
> + PEEK_BITS(10, bits);\
> + if ((bits&0x200) == 0) {\
> + EAT_BITS(1);\
> + } \
> + else if ((bits&0x380) == 0x280) {\
> + EAT_BITS(3);\
> + val += 3;\
> + if (val > 255)\
> + val = 255;\
> + } \
> + else if ((bits&0x380) == 0x300) {\
> + EAT_BITS(3);\
> + val -= 3;\
> + if (val < 0)\
> + val = 0;\
> + } \
> + else if ((bits&0x3c0) == 0x200) {\
> + EAT_BITS(4);\
> + val += 8;\
> + if (val > 255)\
> + val = 255;\
> + } \
> + else if ((bits&0x3c0) == 0x240) {\
> + EAT_BITS(4);\
> + val -= 8;\
> + if (val < 0)\
> + val = 0;\
> + } \
> + else if ((bits&0x3c0) == 0x3c0) {\
> + EAT_BITS(4);\
> + val -= 20;\
> + if (val < 0)\
> + val = 0;\
> + } \
> + else if ((bits&0x3e0) == 0x380) {\
> + EAT_BITS(5);\
> + val += 20;\
> + if (val > 255)\
> + val = 255;\
> + } \
> + else {\
> + EAT_BITS(10);\
> + val = 8*(bits&0x1f)+0;\
> + } \
> +}
> +
> +
> +#define PUT_PIXEL_PAIR {\
> + long pp;\
> + pp = (c1val<<8)+c2val;\
> + *((unsigned short *) (dst+dst_index)) = pp;\
> + dst_index += 2;\
> +}
> +
> +/* Now the decode function itself */
> +
> +void v4lconvert_decode_sn9c2028(const unsigned char *src, unsigned char
> *dst,
> + int width, int height)
> +{
> + long dst_index = 0;
> + int starting_row = 0;
> + unsigned short bits;
> + short c1val, c2val;
> + int x, y;
> + unsigned long bitBuf = 0;
> + unsigned long bitBufCount = 0;
> + unsigned long bits_eaten = 0;
> +
> + src += 12; /* Remove the header */
> +
> + for (y = starting_row; y < height; y++) {
> + PEEK_BITS(8, bits);
> + EAT_BITS(8);
> + c2val = (bits & 0xff);
> + PEEK_BITS(8, bits);
> + EAT_BITS(8);
> + c1val = (bits & 0xff);
> +
> + PUT_PIXEL_PAIR;
> +
> + for (x = 2; x < width ; x += 2) {
> + /* The compression reversed the even and odd columns.*/
> + PARSE_PIXEL(c2val);
> + PARSE_PIXEL(c1val);
> + PUT_PIXEL_PAIR;
> + }
> + }
> +}
>

Re: [PATCH] to libv4lconvert, to do decompression for sn9c2028 cameras

[Theodore Kilgore]

On Sun, 24 May 2009, Hans de Goede wrote:

> Hi,
>
> Thanks for the patch, but I see one big issue with this patch,
> the decompression algorithm is GPL, where as libv4l is LGPL.
>
> Any chance you could get this relicensed to LGPL ?

Hmmm. Come to think of it, that _is_ a problem, isn't it? I will see what 
I can do about it, but it might take a while.

Theodore Kilgore

Re: [PATCH] to libv4lconvert, to do decompression for sn9c2028 cameras

[Hans de Goede]

On 05/24/2009 07:22 PM, Theodore Kilgore wrote:
>
>
> On Sun, 24 May 2009, Hans de Goede wrote:
>
>> Hi,
>>
>> Thanks for the patch, but I see one big issue with this patch,
>> the decompression algorithm is GPL, where as libv4l is LGPL.
>>
>> Any chance you could get this relicensed to LGPL ?
>
> Hmmm. Come to think of it, that _is_ a problem, isn't it? I will see
> what I can do about it, but it might take a while.
>

Yes I'm afraid it is :(

Regards,

Hans

Re: [PATCH] to libv4lconvert, to do decompression for sn9c2028 cameras

[Theodore Kilgore]

On Sun, 24 May 2009, Hans de Goede wrote:

>
>
> On 05/24/2009 07:22 PM, Theodore Kilgore wrote:
>> 
>> 
>> On Sun, 24 May 2009, Hans de Goede wrote:
>> 
>>> Hi,
>>> 
>>> Thanks for the patch, but I see one big issue with this patch,
>>> the decompression algorithm is GPL, where as libv4l is LGPL.
>>> 
>>> Any chance you could get this relicensed to LGPL ?
>> 
>> Hmmm. Come to think of it, that _is_ a problem, isn't it? I will see
>> what I can do about it, but it might take a while.
>> 
>
> Yes I'm afraid it is :(
>
> Regards,
>
> Hans
>

I seem to recall that I asked Harald Ruda about this once before, and he 
gave permission. The question arose because libgphoto2 is also LGPL, and I 
was thinking it might be nice if the decomp code for those cameras would 
be LGPL, too. Clearly, I never got around to making the change even though 
I asked him about it and he said yes, go right ahead.

But naturally that is the mail from him that I can not find. I have lots 
of other mails, including the original one in which he said that he had 
read a post of mine to gphoto-devel about the decompression issue for 
these cameras.

Well, I have sent him another mail, hoping that he is still active on the 
macam project, and I also will try to search through backup files and such 
to look for the mail. You can imagine, that was back in 2005 and several 
machine failures and hard drive failures in particular have taken place 
since then. I do try to back up stuff that I think is important, by 
having a copy of it on several machines. Let us hope that either I find 
something, or he answers the mail.

Theodore Kilgore