incorrect bDeviceClass after firmware loading

sha1sums of the firmwares (same order):

01e291d529e7c18deea2eba252d18114e096276e
b69f49d3fa6858416324c390effe14336a1ddb0b

I could successfully load the iSight firmware using the deprecated ift-load? But it seems that HAL is unable to load it properly. You can see the result of lsusb attached.

But the camera doesn't work yet. It seems that the driver still has problems with it (the probe functions is called but no V4L device is created.

Well, now i get the video !!! (I modified the kernel module, so it couldn't work. But now i reverted to the trunk and it works)

Hi,

Are you sure you don't have old isight_usb.ko ? I will take care of this bug next week. i'm busy right now.

Regards,
Étienne.

I don't think so:

find "/lib/modules/`uname -r`" -name '*isight*' | wc -l
0

I think that's a problem with HAL or ift-callout. But I don't know exactly how it works, so I can't really find a solution for it. But the good newe is that it works with ift-load.

If you need to know, I'm using HAL version 0.5.11 packaged for the ArchLinux distribution.

When I restart HAL, I only get in the system log the following message:

Jun 28 03:47:46 kylae NetworkManager: <debug> [1214617666.839341] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/storage_model_DVD_R___UJ_857D').

But that has nothing to do with ift. I started hal with a verbose flag. Attached the output if it can help you.

Well, I noticed something. in the file 50-isight-firmware.fdi, there is:

<match key="usb.product_id" int="0x8300">

Perhaps, it should be something like:

<match key="usb.product_id" int="0x8501">

But I don't know how I can test it work (except by shutting down the computer). I would need to unload the firmware.

Hi,

0x8300 is the device id of the vanilla device, while 0x8501 is the
device id of the iSight with firmware loaded. The rule match only
unloaded iSight.

I plan to remove ift-callout since HAL is going to replaced by
DeviceKit. So don't worry, ift-load is actually the right way. I just
don't like libusb because i can't avoid looping each busses. Also,
ift-load can be a pain for portability : it depends on env vars that are
not present on all distros. This is where HAL is cool.

Regards,
Étienne.
--
E Ultreïa !

You're right. After shutting down my computer and restarting it I realized it. But I suppose I'll still have a problem if I start Mac OS X (which will load the unpatched firmware) and then restart GNU/Linux. The id will be 8501, and so HAL won't load the firmware. But uvcvideo will not work either.

Perhaps both id should be present.

Hi,

Indeed, this makes a lot of sense. Can you test a patch and send me ?

Regards,
Étienne.
--
E Ultreïa !

... I thought I replied to your message already.

What patch do you want me to test ?

Thanks.

Mildred

Hi,

Can you test latest 1.3.90 (use udev by default) ?

Étienne.