Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
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.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish. v4l-apps/lib seems to be a good place. Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Regards, Thierry