Bill Dirks wrote: > 1. A device may not be able to capture in the format required by the > application, so the driver is converting when it is copying to the user > buffer. A partial read() may not end at a boundary compatible with the > conversion routine, e.g. at a partial pixel. That can be worked around > by having another buffer to hold the converted data, and then doing the > partial read()s from that buffer. > > 2. There is no guaranteed way for the read()ing thread to know where the > frame boundaries are from the read() call alone, especially if the data > is compressed by a variable length compression. > > Bill. I definitely agree with this. IMHO the best (and most meaningfull) solution, is to define read to return data from successive frames on succesive calls. read()ing will have to be done through a v4l(2) specific application anyway to avoid the format confusion (unless you want "set default format" ioctls, or such like. Why add so much overhead for an interface of such limmited use? Justin
