Bill Dirks wrote: > Gerd Knorr wrote: > > So IMHO it would be useful to either: > > - require driver do support *both* non-blocking I/O and > > partial read()s > > or > > - allow drivers to support only blocking, full-frame read()s. > > I think I remember now why I didn't want to force partial read() > support: > > 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. Basically the same issue as with bttv: You need a extra temporary buffer, making capture less efficient. I like ben's argument: make the read() capture easy to use (and partial reads do help here). People who care about performance can use mmap() with multiple buffers and all bells and whistles. > 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. A single read() call should never ever return data from more than one frame. The last of multiple partial reads will just return the remaining bytes of the current frame. Gerd -- Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
