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 > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list