> Are you still planning to support non-capturing opens explicitly? E.g., > the app clears the V4L2_CAP_VIDEO_CAPTURE flag via some ioctl()? No. Instead any attempt to capture something might result in -EBUSY in case the driver can't capture right now and isn't willing to queue the request for some reason. > Right now it's easy to write a driver that can support unlimited > non-capturing opens, but only one capturing open at a time. All you need > is "if (flags | O_NONCAP) return -EINVAL;" at the appropriate points and > a small check in open(). > > With the new API, it looks like the driver will need checks all over the > place in ioctl() read(), etc... to make sure that two apps don't try to > capture at the same time. That is the quick+dirty approach: just move the busy-check from open()+close() down one level into the read() handler and some places in ioctl(). Basically the same places where the "if (flags | O_NONCAP) return -EINVAL;" checks are today. No big deal IMHO. > IMHO if a driver doesn't support multiple simultaneous captures it > should let the app know at open() time by returning -EBUSY. Another (and IMHO better) approach is to allow multiple applications queue up capture requests. If a second application asks for a video frame while the driver is busy capturing the frame for the first application, it can simply put the request into a queue instead of returning -EBUSY. This might need some more changes through (depending on the current driver design). 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
