Hello Bill,
> One of the V4L2 design criteria was to keep it as simple as possible for
> driver writers while still accomplishing the essential goals. Remember
> there were obviously zero V4L2 drivers at the time, and for the effort
> to be useful people must be attracted to and successful at driver
> creation, as much as possible.
[...]
> My perception was that the Linux Way was for drivers to be thin layers
> over the hardware, not with all that abstraction. Ioctls were meant to
> set a few registers and that was that. I think that's too simple for a
> video API. I tried to strike balances among abstraction, function,
> flexibility, implementation, and culture.
[...]
> I never thought of a device that can capture multiple streams from
> different inputs, though.
> Anyway, that's why V4L2 is the way it is. Still want to change it?
Thanks for your good discussion points.
As I already stated in another mail, we perhaps shouldn't overreact
in our discussion.
In my opinion it is sufficient to allow an application to lock the
capture engine via REQBUFS. An ioctl to release the lock should
be added though.
DMA to user space via 'kiobufs' can be added later, when it is
clear that things work the way we want it.
Always remember: v4l2 is still a big step ahead in the moment,
and v4l does not even feature multiple opens per device.
In my eyes you are completly right: writing a v4l2-driver
is already a big task and we should stick to 'kiss'
(keep it simple, stupid) on some topics.
> Bill.
CU,
Michael.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
