Ben Bridgwater wrote:
> Gerd Knorr wrote:
>
> > The current v4l2 specs says drivers should support non-blocking reads but
> > may refuse partial reads if it is "inefficient to implement". This
> > combination simply doesn't make sense to me. IMHO we should pick one
> > of the more useful combinations: make partial reads mandatory or drop
> > non-blocking I/O support for read().
>
> If this is the choice, I'd much rather have the non-blocking read() with
> select support, as this seems much more useful (for IO integration). I
> can't see the use for partial reads.
Ahem, no. Looks like a misunderstanding. I'll try again:
With bttv I can let the bt848/878 dma the video data directly to
userspace. To do this I need (a) a destination address in userspace
and (b) enouth space to store the whole frame there.
Because of (a) this doesn't work with non-blocking I/O (I don't have
the destination address yet at the time I start DMA). Because of (b)
partial reads do not work.
I can also put the whole frame into a bounce buffer in kernel memory.
If I handle read() syscalls this way I have no problems to deal with
non-blocking I/O (because the dma will go to the bounce buffer and I
don't need the destination address yet when I start the DMA). And
partial reads are no problem too, because it makes no difference for
me whenever I copy the bounce buffer in one big or many small chunks
to userspace.
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.
Gerd
--
Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Au�enstelle Berlin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
