incorrect bDeviceClass after firmware loading

[Mildred]

Hi,

I have a MacBook2,1 and i'm using iSight Firmware Tools version 1.2, HAL version 0.5.11 and uvcvideo driver from trunk. The problem is that the iSight camera is not even recognized by uvcvideo.

I asked on the mailing list and it seems there is a problem when I load the firmware. It seems that bDeviceClass is not correct (I have 255 (Vendor Specific) instead of 14 (Video)) except for one interface. But it seems that all interface should have bDeviceClass=14. See lsusb.txt attachment for more details.

I have two different firmwares (AppleUSBVideoSupport) which md5sums are:

8b78709d02d3584f40cc041db9eecfe8 An old version
28da1ad8c1e468d8533eca68853f0d40 My current Mac OS X version

When I extract them using ift-extract -a, I get two different messages:

** Message: Found Mac OS X.4 intel driver
** Message: Firmware extracted successfully in /lib/firmware/isight.fw
** Message: Apply patch 0 : Fix video control interface descriptor
** Message: Apply patch 1 : Fix video streaming interface descriptor
** Message: Apply patch 2 : Fix video streaming device qualifier
** Message: Firmware patched successfully

and

** Message: Found Mac OS X.5.1 driver
** Message: Firmware extracted successfully in /lib/firmware/isight.fw
** Message: Apply patch 0 : Fix video control interface descriptor
** Message: Apply patch 1 : Fix video streaming interface descriptor
** Message: Apply patch 2 : Fix video streaming device qualifier
** Message: Firmware patched successfully

None of them seems to work.

Last thing, I'm not absolutely sure that hal does the work correctly (nothing in system log, neither success not failure reported). Is there a command line involving ift-callout that loads manually the firmware ?

Thanks.

Mildred

[Mildred (mildred)]

sha1sums of the firmwares (same order):

01e291d529e7c18deea2eba252d18114e096276e
b69f49d3fa6858416324c390effe14336a1ddb0b

[Mildred (mildred)]

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.

[Mildred (mildred)]

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)

[Étienne BERSAC (bersace)]

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.

[Mildred (mildred)]

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.

[Mildred (mildred)]

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.

[Étienne BERSAC (bersace)]

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 !

[Mildred (mildred)]

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.

[Étienne BERSAC (bersace)]

Hi,

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

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

[Mildred (mildred)]

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

What patch do you want me to test ?

Thanks.

Mildred

[Étienne BERSAC (bersace)]

Hi,

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

Étienne.