Hans de Goede a écrit :
Thierry Merle wrote:
Hans de Goede a écrit :
Thierry Merle wrote:
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
Hi,
Work is progressing on this (splitting up the v4l1-compat wrapper as described above). I hope to have a first split release by the end of the week.
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish.
Thanks for the offer! I definitely need a place to put this, I was thinking about a sf.net project, but being part of the dbv-tree would probably be better.
I say probably as I don't know what this means with regards to spinning tarbals for distribution consumption. Atleast in the beginning I would like to see seperate tarbals for v4l-lib, especially as once the split is done I want to get this into Fedora devel asap, as my main reason for working on this is: http://fedoraproject.org/wiki/Features/BetterWebcamSupport
Don't get me wrong Fedora's mantra is upstream upstream upstream, so I want this to be usable as widely as possible and integrated into the current v4l / dvb project both the sources and any docs.
But at the same time I also want to see this become available in F-10 and the first apps in F-10 start using it (Patches for apps will be send to their resp. upstreams).
All is OK, no problem if Fedora users help you debug the code before v4l-dvb inclusion :)
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.
Moving stuff like that to userland sounds like a good plan!
Regards,
Hans
Thanks for all Nevertheless, I will follow your work on F-10 and try to help you if I can.
I think you've misunderstood me, I would love for my v4l lib to be poart of the v4l-dvb tree as soon as the split discussed before is done, but I would like to see a mechanism to create separate tarballs for it for easy testing in the begin fase.
Regards,
Hans
Oops, sorry. You can add a rule in the makefile for that: tar: clean tar cvf /tmp/archive.tar * $(include_files_and_other_stuff_that_makes_an_independent_build)
Cheers, Thierry