Thank you Iohannes for pointing out the low-level side-effects and glitches/potentiality eg. hard-disk instead of a webcam. Once again, an experimental system (jaunty with libv4l-dev) against a stable one (hardy) is a hard choice.
Havent grilled any cat yet, but must be tasty! ++ OH
On lun, 2009-06-01 at 17:10 +0200, IOhannes m zmölnig wrote:
abonnements-olivier wrote:
and for the next session echo "export LD_PRELOAD=/usr/local/lib/libv4l1/v4l1compat.so" >> ~/.bashrc
actually i would not recommend this. LD_PRELOAD seriously interferes with how application linking works (and is therefore usually discouraged); the sole purpose of it is to allow library calls be intercepted and provided by a different backend, something useful when doing debugging or swapping a backend for a single application (like chromium does with openGL apps; or libv4l-compat in our case).
otoh, the only thing that libv4l compat can actually intercept is calls to ioctl(), which is deep on the kernel-side. overriding ioctl for each and every application is probably really not what you want. apart from slowing everything down (as it wraps a system call!), you might turn otu seeing your harddisk as a webcam. probably nice pictures, but bad data. (surely libv4l-devs are trying to do everything to not do any harm when wrapping system calls; but they will most likely have bugs in their code as everybody)
thus the way to go, is to compile an application with native libv4l support.
anyhow, i just wanted to point out, that people here are lately suggesting a log of brute force "solutions", which might work fine but nevertheless i think it would be proper to warn anybody that they might just grill their cat.
fgmasdr IOhannes