On Thu, Apr 26, 2001 at 01:19:09PM -0700, Bill Dirks wrote: > > I'm thinking of devices that don't DMA, or need to process the data in > the driver. I assume the driver can write to the memory using the > userspace address. You can use the functions in uaccess.h (copy_to_user, put_user, ...) to access the userspace memory. Or you can vmalloc() a chunk of memory and then remap that to userspace (like most drivers do today). I'd expect remapping is faster. The uaccess.h functions have some overhead (need to catch page faults in case the userspace pointer is not valid). > > How do I setup a second, independent stream? > > Same way you set up the first stream-- REQBUFS, QUERYBUF, mmap(). The > second stream has be a different V4L2_BUF_TYPE. QUERYBUF tells you the > offset to pass to mmap() to get the right buffer. Another type. That will work, ok. /me was thinking about two capture streams... > > I think you can't do that without a second file > > handle. In which case > > there is no problem -- you can have one mapping per file handle. > > Yeah, I thought of that after I sent the email. We want to have > independent buffers anyway for buffers passed from the app to the driver > (assuming we come up with simple extension of the API for this). What is > the big advantage to the application of one mmap() per file handle? Idea was to make it easier to handle v4l1 backward compatibility. I'm still thinking about how to do handle the backward compatibility best. One way to handle it is to make v4l1 and v4l2 handle buffer mapping the same way. That way we can handle anything with the compatibility layer, without driver's help. If we keep the current v4l2 buffer mapping scheme we can't do that. The driver has to take care about the two differerent ways to map the buffers in v4l1 and v4l2. Gerd
