Re: RFC on proposed patches to mr97310a.c for gspca and v4l

[Kyle Guinn <elyk03@gmail.com>]

On Thursday 05 March 2009 14:58:54 kilgota@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