Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Thomas I've been looking through the frame headers sent by the MR97310A (the Aiptek PenCam VGA+, 08ca:0111). Here are my observations. FF FF 00 FF 96 6x x0 xx xx xx xx xx In binary that looks something like this: 10010110 011001aa a101 All of the values look to be MSbit first. A looks like a 3-bit frame sequence number that seems to start with 1 and increments for each frame. B, C, and D might be brightness and contrast; minimum and maximum values for these vary with the image size. For 640x480, 320x240, and 160x120: dark scene (all black): B: near 0 C: 0x000 D: 0xC60 bright scene (all white): B: usually 0xC15C C: 0xC60 D: 0x000 For 352x288 and 176x144: dark scene (all black): B: near 0 C: 0x000 D: 0xB5B bright scene (all white): B: usually 0xB0FE C: 0xB53 D: 0x007 B increases with increasing brightness. C increases with more white pixels and D increases with more black pixels. A gray image has C and D near zero, while a high-contrast image (half black, half white) has C and D around 0x600 or so. The sum of C and D is not a constant. I don't know how brightness and contrast are handled in V4L. Hopefully someone can put this to use. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the compression algorithm there are
some more bytes, and these almost definitely contain information which
could be valuable while doing image processing on the output. If they
are already kept and passed out of the module over to libv4lconvert,
then it would be very easy to do something with those bytes if it is
ever figured out precisely what they mean. But if it is not done now it
would have to be done then and would cause even more trouble.
I sent it already in private mail to you. Here is the observation I made
for the PAC207 SOF some years ago:
From usb snoop.
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
1. xx: looks like random value
2. xx: changed from 0x03 to 0x0b
3. xx: changed from 0x06 to 0x49
4. xx: changed from 0x07 to 0x55
5. xx: static 0x96
6. xx: static 0x80
7. xx: static 0xa0
And I did play in Linux and could identify some fields :-) .
In Linux the header looks like this:
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00
1. xx: don't know but value is changing between 0x00 to 0x07
2. xx: this is the actual pixel clock
3. xx: this is changing according light conditions from 0x03 (dark) to
0xfc (bright) (center)
4. xx: this is changing according light conditions from 0x03 (dark) to
0xfc (bright) (edge)
5. xx: set value Digital Gain of Red
6. xx: set value Digital Gain of Green
7. xx: set value Digital Gain of Blue
Thomas
I've been looking through the frame headers sent by the MR97310A (the
Aiptek PenCam VGA+, 08ca:0111). Here are my observations.
FF FF 00 FF 96 6x x0 xx xx xx xx xx
In binary that looks something like this:
10010110 011001aa a101
All of the values look to be MSbit first. A looks like a 3-bit frame
sequence number that seems to start with 1 and increments for each frame.
Hmmm. This I never noticed. What you are saying is that the two bytes 6x
and x0 are variable? You are sure about that? What I have previously
experienced is that the first is always 64 with these cameras, and the
second one indicates the absence of compression (in which case it is 0,
which of course only arises for still cameras), or if there is data
compression then it is not zero. I have never seen this byte to change
during a session with a camera. Here is a little table of what I have
previously witnessed, and perhaps you can suggest what to do in order to
see this is not happening:
Camerathat byte compression solved, or not
streaming
Aiptek00 no N/A no
Aiptek50 yes yes both
the Sakar cam 00 no N/A no
ditto 50 yes yes both
Argus QuikClix20 yes no doesn't work
Argus DC1620 50 yes yes doesn't work
CIF cameras 00 no N/A no
ditto 50 yes yes no
ditto d0 yes no yes
Other strange facts are
-- that the Sakar camera, the Argus QuikClix, and the
DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of them
will stream with the existing driver. The other two go through the
motions, but the isoc packets do not actually get sent, so there is no
image coming out. I do not understand the reason for this; I have been
trying to figure it out and it is rather weird. I should add that, yes,
those two cameras were said to be capable of streaming when I bought them.
Could it be a problem of age? I don't expect that, but maybe.
-- the CIF cameras all share the USB id of 0x93a:0x010e (I bought several
of them) and they all are using a different compression algorithm while
streaming from what they use if running as still cameras in compressed
mode. This leads to the question whether it is possible to set the
compression algorithm during the initialization sequence, so that the
camera also uses the 0x50 mode while streaming, because we already know
how to use that mode.
But I have never seen the 0x64 0xX0 bytes used to count the frames. Could
you tell me how to repeat that? It certainly would knock down the validity
of the above table wouldn't it?
I've modified libv4l to print out the 12-byte header before it skips over it.
Then when I fire up mplayer it prints out each header as each frame is
received. The framerate is only about 5 fps so there isn't a ton of data to
parse through. When I point the camera into a light I
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
I've been looking through the frame headers sent by the MR97310A (the
Aiptek PenCam VGA+, 08ca:0111). Here are my observations.
FF FF 00 FF 96 6x x0 xx xx xx xx xx
In binary that looks something like this:
10010110 011001aa a101
All of the values look to be MSbit first. A looks like a 3-bit frame
sequence number that seems to start with 1 and increments for each
frame.
Hmmm. This I never noticed. What you are saying is that the two bytes 6x
and x0 are variable? You are sure about that? What I have previously
experienced is that the first is always 64 with these cameras, and the
second one indicates the absence of compression (in which case it is 0,
which of course only arises for still cameras), or if there is data
compression then it is not zero. I have never seen this byte to change
during a session with a camera. Here is a little table of what I have
previously witnessed, and perhaps you can suggest what to do in order to
see this is not happening:
Camera that byte compression solved, or not
streaming
Aiptek 00 no N/A no
Aiptek 50 yes yes both
the Sakar cam 00 no N/A no
ditto 50 yes yes both
Argus QuikClix 20 yes no doesn't work
Argus DC1620 50 yes yes doesn't work
CIF cameras00 no N/A no
ditto 50 yes yes no
ditto d0 yes no yes
Other strange facts are
-- that the Sakar camera, the Argus QuikClix, and the
DC1620 all share the same USB ID of 0x93a:0x010f and yet only one of
them will stream with the existing driver. The other two go through the
motions, but the isoc packets do not actually get sent, so there is no
image coming out. I do not understand the reason for this; I have been
trying to figure it out and it is rather weird. I should add that, yes,
those two cameras were said to be capable of streaming when I bought
them. Could it be a problem of age? I don't expect that, but maybe.
-- the CIF cameras all share the USB id of 0x93a:0x010e (I bought
several of them) and they all are using a different compression
algorithm while streaming from what they use if running as still cameras
in compressed mode. This leads to the question whether it is possible to
set the compression algorithm during the initialization sequence, so
that the camera also uses the 0x50 mode while streaming, because we
already know how to use that mode.
But I have never seen the 0x64 0xX0 bytes used to count the frames.
Could you tell me how to repeat that? It certainly would knock down the
validity of the above table wouldn't it?
I've modified libv4l to print out the 12-byte header before it skips over
it.
Good idea, and an obvious one. Why did I not think of that?
Then when I fire up mplayer it prints out each header as each frame is
received. The framerate is only about 5 fps so there isn't a ton of data
to parse through. When I point the camera into a light I get this (at
640x480):
...
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
ff ff 00 ff 96 65 d0 c1 5c c6 00 00
ff ff 00 ff 96 66 50 c1 5c c6 00 00
ff ff 00 ff 96 66 d0 c1 5c c6 00 00
ff ff 00 ff 96 67 50 c1 5c c6 00 00
ff ff 00 ff 96 67 d0 c1 5c c6 00 00
ff ff 00 ff 96 64 50 c1 5c c6 00 00
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65 50 c1 5c c6 00 00
...
Which camera is this? Is it the Aiptek Pencam VGA+? If so, then I can try
it, too, because I also have one of them.
Yes, that's the one. Try your others if you can and let me know what happens.
Only those 3 bits change, and it looks like a counter to me. Take a look
at the gspca-mars (MR97113A?) subdriver. I think it tries to accommodate
the frame sequence number when looking for the SOF.
No, I don't see that, sorry. What I see is that it looks for the SOF,
which is declared in pac_common.h to be the well-known FF FF 00 FF 96 and
no more bytes after that.
I'm talking about this code from gspca/mars.c. Look in sd_pkt_scan().
if (data[0 + p] == 0xff
data[1 + p] == 0xff
data[2 + p] == 0x00
data[3 + p] == 0xff
data[4 + p] == 0x96) {
if (data[5 + p] == 0x64
|| data[5 + p] == 0x65
|| data[5 + p] == 0x66
|| data[5 + p] == 0x67) {
-Kyle
--
To unsubscribe from
Re: [PATCH 1/2] Add Mars-Semi MR97310A format
On Thursday 15 January 2009 05:49:46 Jean-Francois Moine wrote: On Wed, 14 Jan 2009 20:59:34 -0600 Kyle Guinn ely...@gmail.com wrote: Add a pixel format for the Mars-Semi MR97310A webcam controller. The MR97310A is a dual-mode webcam controller that provides compressed BGGR Bayer frames. The decompression algorithm for still images is the same as for video, and is currently implemented in libgphoto2. Hi Kyle, What is the difference of this pixel format from the other Bayer ones? This is a standard BGGR Bayer format which is compressed using a vendor-specific compression algorithm, much like V4L2_PIX_FMT_PAC207. I don't believe the compression algorithm matches any of the other pixel formats. The first two pixels in the first two rows are stored as raw 8-bit values (the top-left BGGR square), but the rest is Huffman compressed. Take a look at precalc_table() and mars_decompress() in libgphoto2/camlibs/mars/mars.c for all of the details. If you recognize this as an existing pixel format, please let me know. Also, did you ask Hans de Goede to add the decoding to the v4l library? That is next on my TODO list. I have a patch ready to send, but I first want to make sure there are no problems with adding this pixel format. Regards, -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] gspca: Add MR97310A driver
On Friday 16 January 2009 02:47:31 Jean-Francois Moine wrote: On Thu, 15 Jan 2009 22:36:49 -0600 Kyle Guinn ely...@gmail.com wrote: This patch adds support for USB webcams based on the MR97310A chip. It was tested with an Aiptek PenCam VGA+ webcam. Hi Kyle, I added your driver to my repository. I just found a little bug. At line 250/251 data[8] = 0x01; err_code = reg_w(gspca_dev, 10); you set 9 values and you output 10 values. Good catch. Yes, that should be 9. Also that data[8] should be set to 0x00. I must have been asleep at the keyboard :) I'll send a patch. BTW, as many of these USB control messages are constant, you should better use static data or a table format (byte count, values)*. I'll look into this. Those may not all be costants, I believe the camera supports gamma adjustment and autoexposure and maybe some other controls. I plan on gathering some traces to figure that out next week. Regards, -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MR97310A and other image formats
On Tuesday 17 February 2009 13:09:28 Jean-Francois Moine wrote: Hi Kyle, Looking at the v4l library from Hans de Goede, I did not find the decoding of the MR97310A images. May you send him a patch for that? Yes, I sent this to him some time ago. Take a look here: http://linuxtv.org/hg/~hgoede/v4l-dvb/rev/a647c2dfa989 -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: Hans, Jean-Francois, and Kyle, The proposed patches are not very long, so I will give each of them, with my comments after each, to explain why I believe that these changes are a good idea. First, the patch to libv4lconvert is short and sweet: contents of file mr97310av4l.patch follow -- --- mr97310a.c.old2009-03-01 15:37:38.0 -0600 +++ mr97310a.c.new2009-02-18 22:39:48.0 -0600 @@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un if (!decoder_initialized) init_mr97310a_decoder(); + /* remove the header */ + inp += 12; + bitpos = 0; /* main decoding loop */ - here ends the v4lconvert patch -- The reason I want to do this should be obvious. It is to preserve the entire header of each frame over in the gspca driver, and to throw it away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason why all of this should be kept is that it makes it possible to look at a raw output and to know if it is exactly aligned or not. Furthermore, the next byte after the 96 is a code for the compression algorithm used, and the bytes after that in the header might be useful in the future for better image processing. In other words, these headers contain information which might be useful in the future and they should not be jettisoned in the kernel module. No complaints here. I copied off of the pac207 driver, thinking that one compression format == one pixel format and that all mr97310a cameras use the same compression. I was hesitant to say that the mr97310a pixel format can correspond to multiple compression formats, especially since I only have one such camera and I don't know if it's preferred to use multiple pixel formats for this reason. From what I understand, sending the frame header to userspace solves at least two problems (if indeed the compression is specified in the header): * One frame may be compressed and the next frame isn't, or the next frame uses a different compression. * Two cameras with the same vendor/product ID use different compression formats. Distinguishing the two cameras in the kernel driver could be messy. Just a random thought, but maybe the pac207 driver can benefit from such a change as well? -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote: Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. I don't believe the driver has made it to any kernel yet. Even if it has, the user would need to have an unreleased version of libv4l. I think this change would inconvenience me and Theodore at most. Let's change it now. -Kyle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
--- mr97310a.c.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-03-03 17:19:06.0 -0600
@@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
data, n);
sd-header_read = 0;
gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
- data = sof;
- }
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
+ /* keep the header, including sof marker, for coming frame */
+ len -= n;
+ data = sof - sizeof pac_sof_marker;;
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
A few notes:
1. There is an extra semicolon on that last added line.
Oops. My bifocals.
2. sd-header_read no longer seems necessary.
This is very likely true.
3. If the SOF marker is split over two transfers then everything falls
apart.
Are you sure about that?
Simple example: One transfer ends with FF FF 00 and the next begins with FF
96 64. pac_find_sof() returns a pointer to 64, n is set to 0, len stays the
same, data now points at 3 bytes _before_ the transfer buffer, and we will
most likely get undefined behavior when trying to copy the data out of the
transfer buffer. Not only that, but the FF FF 00 portion of the SOF won't
get copied to the frame buffer.
Since we know what the SOF looks like, we don't need to worry about losing the
FF FF 00 portion -- just copy sd-sof_read bytes from pac_sof_marker.
Unfortunately my brain is fried right now and I can't come up with a working
example.
I don't know if the camera will allow that to happen, but it's better to
be safe.
Agreed.
Note that this was a RFC. So if it is agreed that something needs to be
done, probably things should be put into a more formal patch structure.
Also I have a question of my own while thinking about this. It relates not
to the module but to the decompression code. What do we have over there?
Well,
void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char
*outp,
int width, int height)
and then in my patch it does
/* remove the header */
inp += 12;
Perhaps this is not good, and what ought to be done instead is to pass
off the inp to an internal variable, and then increase it, instead.
Possibly an even better alternative exists. The easiest way, I think,
would be to take the two previous lines back out again, but
instead go back to the function
static inline unsigned char get_byte(const unsigned char *inp,
unsigned int bitpos)
{
const unsigned char *addr;
addr = inp + (bitpos 3);
return (addr[0] (bitpos 7)) | (addr[1] (8 - (bitpos
7)));
}
and put the 12-byte shift into the line which computes addr, like this:
addr = inp + 12 + (bitpos 3);
Let's not overcomplicate things. I think inp += 12 with a comment is fine for
now since we haven't completely reverse engineered the header yet. Use one
function to parse through the header, then use a different one to handle the
frame decompression. The header parser will call the correct decompressor
function with the correct offset into the frame buffer.
or if one really wants to get fancy about it then give a
#define MR97310a_HEADERSIZE 12
at the top of the file and then one could say
addr = inp + (bitpos 3) + MR97310a_HEADERSIZE;
I don't think we know this for sure yet. Maybe the header length is variable
and is specified along with the compression code?
As I said, if doing any of these then one would leave strictly alone the
decoding function and any of its contents. I am not sure if messing with
the start of the inp variable is a good idea. Frankly, I do not know
enough details to be certain. But on second look my instincts are against
screwing with something like that. The thing that worries me is that what
exactly happens to those 12 bytes. Do they disappear down a black hole, or
what? For, in the end they will have to be deallocated somewhere. And
what then? The alternative which I give above would do what is needed and
also does not mess with the start location of inp.
inp is a local variable, so changing it inside the decompressor function will
have no affect
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote:
Well, here is the code in the function. I don't see. So can you explain?
Perhaps I am dense.
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
if (m[i] == pac_sof_marker[sd-sof_read]) {
sd-sof_read++;
if (sd-sof_read == sizeof(pac_sof_marker)) {
PDEBUG(D_FRAM,
SOF found, bytes to analyze: %u.
Frame starts at byte #%u,
len, i + 1);
sd-sof_read = 0;
return m + i + 1;
}
} else {
sd-sof_read = 0;
}
}
return NULL;
}
We send a chunk of data to this function, as pointed to by m. It could be the
entire transfer buffer or only a part of it, but that doesn't matter. If the
chunk of data ends with FF FF 00 then sd-sof_read will be set to 3 when the
function exits. On the next call it picks up where it left off and looks for
byte 4 of the SOF.
Way back when, I said to copy sd-sof_read bytes from pac_sof_marker if you
want the portion of the SOF that was in the previous transfer. There's no
need to buffer 4 bytes from the previous transfer because the SOF is
_constant_.
So, if it's constant, why do we need to copy it to userspace at all? If we
do, then every frame buffer begins with a constant, useless FF FF 00 FF 96.
The reassurance doesn't matter because the frame _must_ have started with
FF FF 00 FF 96 to get there in the first place. I agree with Hans that it
isn't necessary, and by not sending it to userspace we simplify the kernel
driver.
But what if it's not constant? Maybe the SOF is 4 bytes and the 5th byte is
some useful data that, 99.9% of the time, is set to 96? This is the only
reason I see for keeping the SOF.
-Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] for the file gspca/mr97310a.c
On Thursday 05 March 2009 20:34:27 kilg...@banach.math.auburn.edu wrote:
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
--
--- mr97310a.c.old2009-02-23 23:59:07.0 -0600
+++ mr97310a.c2009-03-05 19:14:13.0 -0600
@@ -29,9 +29,7 @@ MODULE_LICENSE(GPL);
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
-
u8 sof_read;
- u8 header_read;
};
/* V4L2 controls supported by the driver */
@@ -100,12 +98,9 @@ static int sd_init(struct gspca_dev *gsp
static int sd_start(struct gspca_dev *gspca_dev)
{
- struct sd *sd = (struct sd *) gspca_dev;
__u8 *data = gspca_dev-usb_buf;
int err_code;
- sd-sof_read = 0;
-
Good catch, I didn't realize this was kzalloc'd.
/* Note: register descriptions guessed from MR97113A driver */
data[0] = 0x01;
@@ -285,40 +280,29 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data, /* isoc packet */
int len) /* iso packet length */
{
- struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;
sof = pac_find_sof(gspca_dev, data, len);
if (sof) {
int n;
-
+ int marker_len = sizeof pac_sof_marker;
The value doesn't change; there's no need to use a variable for this.
/* finish decoding current frame */
n = sof - data;
- if (n sizeof pac_sof_marker)
- n -= sizeof pac_sof_marker;
+ if (n marker_len)
+ n -= marker_len;
else
n = 0;
frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame,
data, n);
- sd-header_read = 0;
- gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
+ /* Start next frame. */
+ gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+ pac_sof_marker, marker_len);
+ len -= n;
+ len -= marker_len;
+ if (len 0)
+ len = 0;
len -= sof - data; is a shorter way to find the remaining length.
data = sof;
}
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
- }
-
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
}
@@ -337,6 +321,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
This change is unrelated; maybe it should be in a different patch? Don't
forget to update Documentation/video4linux/gspca.txt with the new camera.
-Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
