Hello Justin,
> 1) Retain only 1 registration method (Gerd's fops method).
> 2) Remove all v4l1 compatibility into a separate module.
> 3) Have the compatibility module register distinct devices for v4l1
> compatibily.
Ok.
> 2) v4l2 drivers must do their own userspace copying (probably a single
> helper function in videodev that v4l2 modules must call).
No problem.
> 3) applications will see two devices for every v4l2 device - one the
> native v4l2 device, and the other a completely separate device
> registered by the compatibility layer.
I like that.
I strongly discourage users from using my driver
with old v4l-applications at the moment anyway. For nearly all
things there are real v4l2 applications out there, which can
be used instead. (Ok, "realproducer" seems to be an
exception, although I did not try it out.)
If someone is going to use a v4l2 driver with an old v4l
application, he should load the compatibility layer module
separately to notice that there is something wrong.
> The only disadvantage of this is that we now get two devices (and the
> consequent user confusion) for every v4l2 device). The main advantage
> is that it is minimally intrusive, and completely modularises the
> compatibility layer.
As I stated above, it's only a confusion if the user really wants
to use a v4l1 / v4l2 mixup. And in that case he should know what he is
doing.
If he sticks to new v4l2 applications, everything is fine.
No double devices -- no confusion.
> -justin
CU
Michael.
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
