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.
