Different ISIGHT_PRODUCT_ID value in load.h

I also see the same problem on my macbook running Fedora :

$ sudo dmidecode -s system-product-name
MacBook2,1

modifying the system make the webcam work again ( except there is a likely unrelated issue with cheese ).

On macbook 5,2 with ubuntu 10.04 the problem is that when you do a cold boot isight has product id = 8300, after loading the firmware with the standard ift-load it becomes 8501 and it stays this way on reboot, until you cold boot.
Couldn't ift-load dinamically choose the current isight product id instead of having it hardcoded in load.h (it's just an hypothesis from a non-coder ;) ).

So that would mean that the driver work fine if you boot on os x, start the webcam and reboot again on linux ?

There seems to be several occurence of the same bug :
https://bugs.launchpad.net/isight-firmware-tools/+bug/386812/comments/18

I have a rather untested patch for that

There seems to be several occurence of the same bug :
https://bugs.launchpad.net/isight-firmware-tools/+bug/386812/comments/18

I have a rather untested patch for that, i compile and load the firmware for me :
  $ sudo ./src/ift-load -f /lib/firmware/isight.fw
ift-load: USB device 0x05AC:0x8300 not found
ift-load: iSight firmware loaded successfully

> So that would mean that the driver work fine if you boot on os x, start the webcam and reboot again on linux ?

No: after a boot on osx, the product id is 8501, until next cold boot.

It goes this way: on cold boot, before loading the firmware with standard ift-load, the product id is 8300; after loading the firmware with standard ift-load, or booting on osx, the product id becomes 8501, so if I try reloading the firmware with standard ift-load I get

ift-load: USB device 0x05AC:0x8300 not found
ift-load: No iSight found

But if I try reloading it with "Necati Kesec's patched ift-load version", it reloads no problem.
But, "Necati Kesec's patched ift-load version" gives error if run first on cold boot:

ift-load: USB device 0x05AC:0x8501 not found
ift-load: No iSight found

Anyway, sometimes (rarely) the product id will be 8501 even on cold boot (!).

So, In other words, your patch probably would work (I didn't test it), but ISIGHT_PRODUCT_ID_COLDBOOT should be renamed to ISIGHT_PRODUCT_ID_AFTER_LOADING_THE_FIRMWARE_USING_PRODUCT_ID_8300 or maybe just ISIGHT_ALTERNATIVE_PRODUCT_ID
;)

In order to test this, I copied into separate dir and subdirs the "standard" ift-load, "Necati Kesec's patched version", and the firmware file isight.fw; then I uninstalled the isight-firmware-tools package, so everything is to be done manually.

BTW: current linux usb.ids database (http://www.linux-usb.org/usb.ids) states

05ac Apple, Inc.
 8300 Built-in iSight (no firmware loaded)
 8501 Built-in iSight [Micron]

Same problem on ubuntu oneiric alpha, on a desktop imac

only difference is the correct productid is 0x8502 instead of 0x801

why not add a command line option enabling to type the correct address?

I mean: 0x8502 instead of 0x8501

A command line will not make it work out of the box :/

I was suggesting an option like:

/usr/lib/udev/ift-load -a 0x05AC:0x8502 -f /lib/firmware/isight.fw

Currently, the address is defined in a load.h file, so you have to recompile to make it work. I can't recompile because of painful package dependencies I would have to resolve first.

Could you elaborate on why enabling the specification of the address at run time would not work out of the box?

Sorry in advance if I missed some point.

Eric B: I think Michael Scherer wrote that the specification of vendor_id:product_id at run time would not work out of the box because the product_id is different on cold boot and on warm boot: it's 8300 on cold boot, and 8501 (8503 in your case) on warm boot (ie: the product id is 8300 when no firware is loaded, 8501(|8502) when the firmware is loaded --- this means the firmware "stays in memory" on reboot, but it doesn't on shutdown, although sometimes, for some reasons, it does on shutdown too, at least here).

Now I'm using 1.6 with a slightly modified version of Michael's patch, and it works for me.
It also tries 8502, so it may work for you too (it tries every isight product ids found on linux usb.ids database).

Anyway, I think we should follow
https://bugs.launchpad.net/isight-firmware-tools/+bug/386812/
since this bug page is (kind of) a duplicate of that one.

In fact, my point is that allowing to select the id on commandline would be a short term solution and would solve the problem for us, but requires us to look at the usb id. And I feel that we cannot ask to people to fiddle with udev configuration in case of problem. Now, it would maybe be better to push the autodetection outside of the main binary.

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 :)

> Now, it would maybe be better to push the autodetection outside of the main binary.

I tried, see the patch, but beware it's more or less my first time at C ... ;)

@Michael scherer: thanks for the detailed explanations.

@dentament: I don't know whether it works here. I'm comfortable with both udev and rc.local methods, but I'm still stuck at this 0x8502 problem.

Out-of-the-box package doesn't work because it test 0x8501, and I can't change load.h and recompile the driver, so I cannot test.

Well, I suppose I could, recompile, but the problem is, I'm running latest ubuntu oneiric beta on my mac, and the compilation process has a lot of problems with libraries in that context, and at some point I gave up.

That's why a non built-in product id would help here, because I can't recompile. I'm not asking for "something that works out of the box".

OK, I manages to recompile 1.6 version, with a modified load.h with a product_id equal to 0x8502.

Extraction of firware okay, but at loading time it fails:
# ./ift-load -f /lib/firmware/isight.fw
ift-load: Failed to init firmware loading
ift-load: Failed to upload firmware to 0x05AC:0x8502

a strace shows that it locates my iSight camera at the proper place, i.e. /dev/bus/usb/001/003. But then it fails doing an ioctl on this file:

open("/dev/bus/usb/001/003", O_RDWR) = 3
open("/lib/firmware/isight.fw", O_RDONLY) = 4
ioctl(3, USBDEVFS_CONTROL or USBDEVFS_CONTROL32, 0x7ffff090a930) = -1 EPIPE (Broken pipe)

What would be the proper place to debug this? I'll try subscribing to the mailing list.

OK, no mailing list found.

My personal email is "ebischoff !at! nerim !dot! net". I can also join an irc channel, or whatever helps debugging this.

I can open a separate bug report for my problem if needed.

With respect to this bug report:
I still maintain that one should not need to recompile ift_load to be able to change the product id.

Hi,

I'm also affected by this bug. I'm running Ubuntu 12.10 on a MacBookPro2,2. B-)

I'm comfortable to do some patching to help myself and everyone else, but I'd like to know what is the best way forward to do this. Add a udev configuration for "our" webcam, too, and load it with a different USB ID if it's that device?

Thanks,
Dirk.

The attachment "patch to use 2 id" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Status changed to 'Confirmed' because the bug affects multiple users.