On Thu, 12 Jun 2008 10:03:11 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
Seems an interesting plan.
libv4l1:
This offers functions like v4l1_open, v4l1_ioctl, etc. These functions work exactly like the normal open/close/etc, except that the lib will do v4l1 emulation on v4l2 drivers. This can by used to quickly make v4l1 applications work with v4l2 devices, this will contain most of the current wrapper code. This will do full emulation of the v4l1 api on top of v4l2 drivers (*), in case of v4l1 drivers it will just pass things through.
Then the to be preloaded v4l1_compat.so just becomes a number of shims calling the v4l1_foo functions in libv4l1, and a v4l2_convert.so can be made which will be just a number of shims calling the v4l2_foo functions in libv4l2, which can be used to add support for more v4l2-source formats to existing apps without changes and recompiling.
I have some doubts if libv4l1 is something interesting and, in the case, we can depreciate v4l1_compat, or if it would be better to fix v4l1_compat. Both strategies have advantages. AFAIK, the major issue at v4l1_compat is the lack of support for applications that starts stream then decides to send a command that changes video format (like vlc v4l1 support). Also, since it doesn't keep an history of a request, if you set certain video formats (MJPEG, if my memories aren't failing), a get can return a different format (since there are namespace duplication on V4L1 api).
It is not that hard to fix the first issue. It is just a matter of allocating memory for the max resolution, for the streaming compat ioctl. This way, you may dynamically change the size. Extra care should be taken, since this might not be supported by a few devices.
The second issue is more complex, since the compat should be capable of keeping some context. Resolving this issue at the library would be easier.
Cheers, Mauro