Comment 13 for bug 798610

Revision history for this message
pezcurrel (pezcurrel) wrote :

Current IFT installations use udev to trigger ift-load only when there's a device with vendor id = 05ac and product id = 8300; as far as I've understood it's done this way in order to avoid "unnecessary load". Otherwise it is assumed that the correct firmware is already loaded, and that uvcvideo will consequently load right. But this is just not always the case: I think that when one boots into osx, and then reboots into linux, the loaded firmware is apple's firmware, not its "patched ift version" extracted by ift-extract; this often doesn't give problems on my mb 5,2, but sometimes it does (no uvcvideo module loaded, no /dev/video0); moreover, this case...
https://bugs.launchpad.net/isight-firmware-tools/+bug/386812/comments/3
...is always reproducible even on my mb 5,2.
Étienne Bersac, the developer, wrote in
https://bugs.launchpad.net/isight-firmware-tools/+bug/386812/comments/16
"We need ift-load to check whether the firmware loaded is actually patched, if not, load the patched version."
So maybe the best solution would be, as Bersac wrote, to have ift-load check whether the already loaded firmware is actually patched (maybe not only with product_id 8501, but also with 8502 and 8507 --- I see no bug reports in which the product_id with firmware loaded is 8505), and if not, load the patched version (with the actually exposed product_id); and to drop udev using an "init script" instead, since ift-load needs to be run on every boot and the single ift-load run is not a great system load.

For now I'm using 1.6 version patched with my patch and without udev rule, calling ift-load from rc.local, and it has always worked. It would be interesting to know whether this works for Eric B too :)