Re: [PATCH/RFC v1 0/7] Videobuf2 framework

[Andy Walls <awalls@md.metrocast.net>]

On Fri, 2010-09-10 at 10:22 +0200, Hans Verkuil wrote:
> On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote:
> > Hello,
> > 
> > On 2010-09-10 13:27, Mauro Carvalho Chehab wrote:
> > 
> > >>> 1) it lacks implementation of read() method. This means that vivi driver
> > >>> has a regression, as it currently supports it.
> > >>
> > >> Yes, read() is not yet implemented. I guess it is not a feature that would
> > >> be deprecated, right?
> > >
> > > Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv
> > > allows receiving simultaneous streams, one via mmap, and another via read().
> > > This is used by some applications to allow recording video via ffmpeg/mencoder
> > > using read(), while the main application is displaying video using mmap.
> > 
> > Well, in my opinion such devices should provide two separate /dev/videoX 
> > nodes rather than hacking with mmap and read access types.
> 
> 1) It is in use so you can't just drop it.
> 2) The read() API is actually very useful for video devices that deal with
>    compressed video streams. E.g. you can do things like 'cat /dev/video0 >foo.mpg'
> 
> It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf,
> but it's always been too complex. With a new vb2 implementation it may become
> actually possible.

Steven has mmap() mostly done for the cx18 YUV stream:

http://www.kernellabs.com/hg/~stoth/cx18-videobuf/

I provided him a slew of comments on the patchset,  The comments were
mostly just grunt work to move things around and clean it up than any
major flaws.  I only saw one problem that must be fixed before it is
usable for the masses, IIRC.

Maybe if there's a test case for trying out videobuf2, it's the cx18
driver where we want to use mmap() for YUV and read() for MPEG.  Note
Steven's changes allow one to tell the CX23418 to send YUV data in YUYV
format vs. HM12.

Regards,
Andy