Ronald Bultje wrote: > Hi all, > > another question about v4l2/drivers. v4l2 is supposed to allow multiple > apps to open the same device, which is a good thing(tm). It isn't *required* for v4l2 drivers. But it certainly a good thing. > The docs > (either the ones at thedirks.org/v4l2 or Gerd's docs - I forgot) say > that you should lock the capturing to one open() session per device > (logical - you can only capture once, normally). See http://beta.bytesex.org/v4l/v4l2.html > VIDIOC_REQBUFS time, however, there's no call to end the buffer use - so > when should I free this memory in the driver? during munmap() > (videobuf.c seems to free something at munmap time)? munmap() will release stuff, yes. > Then, when should I place the lock on the capturing process so other > open() session on the same device can't interfere with this capturing > process? During STREAM_ON? bttv / saa7134 do (un)lock on STREAMON/OFF. > STREAM_ON/STREAM_OFF, how would I deal with this in v4l1, which doesn't > have the STREAM_ON/STREAM_OFF ioctl calls? saa7134 uses the v4l1-compat wrapper, which effects in first MCAPTURE call doing the locking. Not sure about unlocking, I think it stays locked until close(). bttv 0.8.x doesn't lock v4l1 captures (i.e. you can't get exclusive capture access using the v4l1 API, with multiple applications capturing at the same time both will receive frames with lower frame rate). > The problem is that the driver currently simply creates the buffers on > device open() time and frees them at close(). The first one to close() > the driver kills the buffers, so closing xawtv while capturing would > probably crash the machine. *yikes*. I'm looking for a somewhat more > acceptable solution. ;-). block (uninterruptible) in file_ops->release() until any DMA xfer in flight is done, then free the buffers. Gerd -- You can't please everybody. And usually if you _try_ to please everybody, the end result is one big mess. -- Linus Torvalds, 2002-04-20
