> 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
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
