MacBook iSight (isight_usb) reports 640x480, but fails to work at that resolution

Btw, this is on Feisty, up-to-date.

I can confirm this. This was perfectly fine but now is no longer detected in ekiga...

Just upgraded and got linux-image-2.6.20-14-generic, version 2.6.20-14.23. It's not working there either...

Still not working with linux-image-2.6.20-15-generic (v2.6.20-15.27).

uvc was updated on -13 by Ben to solve issues with other devices, but it broke iSight, or something else was changed:

* uvcvideo: Update to latest SVN version.
    - GIT-SHA 7ca4b455c60b38ad53d03834fe03799ace81166d
    - Bug #86754

The module loads but the camera isn't detected.

Aha!

http://i-nz.net/projects/linux-kernel/

I've tested it with the current kernel and it works. Can uvc be updated with this? :)

I mean't I tested the patch on the current kernel source and it applies, builds and works with the iSight. One big bonus is the firmware loader built in the module, there's only need to copy the firmware to /lib/firmware :)

This patch works perfectly for me with linux-source-2.6.20, version 2.6.20-15.27. Thanx.

Don't thank me, thank the wonderful work of

Ronald S. Bultje
Johannes Berg
Ivan N. Zlatev

Lets hope it can get added on an later update. :)

On Mon, 2007-04-23 at 13:26 +0000, Turbo Fredriksson wrote:
> This patch works perfectly for me with linux-source-2.6.20, version
> 2.6.20-15.27. Thanx.
>

Fair enough, but you found it. I've been working all weekend to try to 'forward port' the working stuff from -12 to -15. And didn't succeed in getting it to work, only to be detected :)

Yup, I was around the same thing, and utterly came to the same
conclusion. This patch is deeper than the one we tried to port. Knowing
some C wasn't enough without really understanding the driver structure.
I'm glad someone with more knowledge than us was kind enough to port the
patch to the newer linux-uvc. :)

Now there's only the need to see if this doesn't break the other
cameras. :P

Someone from the Kernel team (Ben?), how can we help to get this on an
update? Is it too early? :(

still unfixed in 2.6.20-16 :/

Bruno,

Thanks for piecing this together.

By the context of the discussion, I am assuming that you are going down the path of fixing the kernel module that is provided with ubuntu. A little digging shows that in my case it is located in /lib/modules/2.6.20-16-generic/kernel/ubuntu/media/usbvideo/uvcvideo.ko

The guides I've been following up til now ( including http://i-nz.net/projects/linux-kernel/ ) act upon the linux-uvc source from http://linux-uvc.berlios.de/. They then create a kernel module that is installed in a different location, /lib/modules/2.6.20-16-generic/kernel/drivers/usb/media, if I recall.

Could you be kind enough to provide clear directions, starting with isight.patch above and ending with a working kernel module. No need to repeat the directions on providing the isight firmware to the module ( unless you want to of course ).

Mostly I am unclear of what to apply the patch against, then the compilation/install path.

Hopefully we can get this added soon so that patching is not required.

Hi Hector, I'll not be close to my box until wednesday, so I can't give you the whole steps to patch the ubuntu kernel source. Nevertheless you can use the package available in that blog entry: http://files.i-nz.net/projects/linux-kernel/isight/uvcvideo-isight.tar.gz

You just need to unpackage it, have linux-headers installed, do a make and sudo make install

I think this will substitute the other driver (may come first in the list while loading), but you can also delete the one you listed and issue a depmod -a to rebuild the list.

The patch no longer holds to the latest linux-uvc svn version, but the package has the right version (100).

Tell us if it works ok.

It would be nice if this landed on feisty before release, since it builds perfectly with the uvc version Ben added, but there must've been too low interest or something to have a working iSight on default install, guess the goal to have good MacBook support wasn't really important. At least this bug report was ignored.

Is this fixed in gutsy?

I have not upgraded to Gutsy (still running an up-to-date Feisty), but I took the linux-image-2.6.22-7-386 package from gutsy... It is still not recognized...

Looking closer, the 'uvcvideo' module doesn't even EXIST in the linux-image-2.6.22-7-386 package.

... and naturaly that module is in the linux-ubuntu-modules-2.6.22-7-386 package...

Still doesn't recognize the iSight though:

----- s n i p -----
Jun 28 16:03:48 turbo-laptop2 kernel: [10459.680000] usbcore: registered new interface driver uvcvideo
Jun 28 16:03:48 turbo-laptop2 kernel: [10459.680000] USB Video Class driver (v0.1.0)
----- s n i p -----

----- s n i p -----
[turbo-laptop2.pts/3]$ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /pipeline0/v4l2src0: Cannot identify device '/dev/video0'.
Additional debug info:
v4l2_calls.c(404): gst_v4l2_open (): /pipeline0/v4l2src0:
system error: No such file or directory
Setting pipeline to NULL ...
FREEING pipeline ...
----- s n i p -----

Adding the patch mentioned above and rebuild the modules package work though...

We'll review this patch, but it looks pretty extensive, and probably wont make it into feisty.

I suggest testing gutsy tribe-2 and make sure things work there.

I have tested with gutsy 64-bit and this does not work, however I am unsure if this is a firmware issue, or if nobody applied the patch. I will check the dmesg later.

I am now 100% sure this patch has not been applied. firmware is in the proper place, yet no device is created, and uvcvideo shows no sign of recognizing anything.

I see the same problem as Turbo, also on a fully up to date Gutsy install. This is on an intel iMac.

Tribe 3 is out, and as far as I can see, the problem is still there. Thanks already to the people who will solve this bug ;-)

Problem persists in Gutsy/amd64. I've tried the i-nz.net all-in-one driver, and it doesn't work either:

[ 8018.148622] uvcvideo: iSight: firmware already loaded.
[ 8018.148653] uvcvideo: Found UVC 1.00 device Built-in iSight (05ac:8501)
[ 8018.148859] uvcvideo: Failed to query (135) UVC control 1 (unit 0) : -32 (exp. 26).
[ 8018.150800] usbcore: registered new interface driver uvcvideo
[ 8018.150807] USB Video Class driver (v0.1.0)

I compiled the driver as stated above and the test in gstreamer-properties fails with:

gstreamer-properties-Message: Error running pipeline 'Video for Linux 2 (v4l2)': Could not negotiate format [gstbasesrc.c(2062): gst_base_src_start (): /pipeline0/v4l2src3:
Check your filtered caps, if any]

but ekiga works ok.

new work is being done on the patch. see:
https://lists.berlios.de/pipermail/linux-uvc-devel/2007-August/002027.html

I just upgraded to Gutsy tribe 5, and it's still broken.

I installed the i-nz.net all-in-one driver and it now works in Ekiga, but not in gstreamer-properties.

On Fri, 2007-08-24 at 16:17 +0000, Michael Moore wrote:
> I just upgraded to Gutsy tribe 5, and it's still broken.
>
> I installed the i-nz.net all-in-one driver and it now works in Ekiga,
> but not in gstreamer-properties.
>

Even with v4l2? It only supports v2.

Yes, I can get the i-z.net driver working, too. It works with ekiga, but I can't get anything else to work with it.

gstreamer-properties says this if I try to test:
$ gstreamer-properties
gstreamer-properties-Message: Error running pipeline 'Video for Linux 2 (v4l2)': Could not negotiate format [gstbasesrc.c(2062): gst_base_src_start (): /pipeline0/v4l2src3: Check your filtered caps, if any]

cheese also segfaults:
$ cheese --gst-plugin-spew
** Message: Probing the webcam, please ignore the following, not applicabable tries

(cheese:8893): GStreamer-CRITICAL **: gst_value_list_get_value: assertion `index < gst_value_list_get_size (value)' failed
Segmentation fault (core dumped)

Closing Feisty task.

Will it be fixed in Gutsy?

Cool, a module for the iSight is available with firmware loading capability. Will the firmware be distributed or will need to be copied manually?

I can get gst-properties to access the camera but freezes afterwards after I close the error window for pipeline construction problems. Cheese also turns on the camera (green led lits) but freezes while initiating it.

Anyone else had success with the new driver?

I get the same behaviour. From the commandline:

$ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink
Impostazione della pipeline a PAUSED ...
La pipeline è viva e non necessita il PREROLL ...
Impostazione della pipeline a PLAYING ...
New clock: GstSystemClock

[First freeze, green light on, hit Ctrl-C]

Caught interrupt -- handling interrupt.
Interrotto: impostazione della pipeline a PAUSED ...
Execution ended after 31987538000 ns.
Impostazione della pipeline a PAUSED ...
Impostazione della pipeline a READY ...

[Second freeze, green light on, hit Ctrl-C again]

$

I confirm what Stefano writes.

This is on:

michael@desktop:~$ uname -a
Linux desktop 2.6.22-11-generic #1 SMP Mon Sep 17 03:45:58 GMT 2007 i686 GNU/Linux

I am getting the same as stated above. Camera is activated, but no video is produced. I tried putting the Apple firmware in different locations with no help.

It seems that gutsy beta now supports the iSight out of the box.

iSight is working with ekiga, still not working through gstreamer.

Same here, iSight is working with ekiga, still not working through gstreamer.
 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux

gstreamer-properties doesn't keep custom v4l2 pipelines (and reverts whatever you change in gconf), I got it to work with:

v4l2src ! video/x-raw-yuv,format=(fourcc)UYVY,width=352,height=288
v4l2src ! video/x-raw-yuv,format=(fourcc)UYVY,width=320,height=240

It seems 640x480 has issues (these could be kernelwise, but I can't say)

It seems to me that the camera works great with the module, but gstreamer has issues with the maximum resolution.

A test command that uses lower resolution:

gst-launch-0.10 v4l2src ! video/x-raw-yuv,format=\(fourcc\)UYVY,width=352,height=288 ! ffmpegcolorspace ! ximagesink

Cheese seems to check the camera capabilities and fails, since the camera is reporting to support 640x480 but for some reason it doesn't work well with that resolution...

If cheese permitted custom pipelines we could bypass these issues for now, other gstreamer apps that check on gconf for pipeline info, you can change to the custom pipelines I posted above, but if gstreamer-properties is run they are reverted to the original v4l2src.

The gconf path is /system/gstreamer/0.10/default

The keys
<videosrc>
v4l2src ! video/x-raw-yuv,format=(fourcc)UYVY,width=352,height=288
<videosink>
ffmpegcolorspace ! ximagesink

Should this bug be moved to gstreamer or are the resolution issues related to the module?

As far as I can tell, it's a kernel issue. Other people seem to claim that it works with 640x480, but I haven't been able to track down the difference - I suspect the firmware version may have some influence.

It seems to work with the lower resolution, but it used to work with the higher resolution in 2.6.20 (patching the uvcvideo module), so I know the higher res is possible.

I just heard from the developer of Cheese (Photobooth-like application) that fixes are implemented in gsteamer cvs. I have not yet tried them.

So it is a gst issue? Ekiga is working @ 640x480? I only get the lower resolution 352x288 if I use "Zoom In"... is Ekiga smarter and notices 640x480 has issues? Or is it limited by design?

Hi Bruno (2007.10.21_17:50:11_+0200)
> So it is a gst issue? Ekiga is working @ 640x480? I only get the lower
> resolution 352x288 if I use "Zoom In"... is Ekiga smarter and notices
> 640x480 has issues? Or is it limited by design?

This is how I got 640x480:
gconftool-2 --type integer --set /apps/ekiga/devices/video/size 1

Yup, works perfectly, 640x480@30fps. I'd move this bug to gst, since kernel support seems to be perfect (at least if the application is talking native v4l2).

Anyone knows what are the fixes to gst in cvs? Are the fixes to resolution detection and robust degradation or for 640x480 support?

Well, this is interesting.

I just tried the 640x480 test command in 32bit Ubuntu Gutsy in VMWare Fusion, and it worked fine (after modprobing uvcvideo). Nothing else was needed.

Maybe this is a result of being the VM, but it was my understanding that the USB devices are seen natively by the VM.

new iSight patch for uvcvideo fixes resolution problem:
http://i-nz.net/2007/11/04/isight-patch-update-640x480-suspendresume-support/

Hi,

This patch seems broken for 2.6.24 kernels. Needs to be updated to r148. However, i still have the "No valid chain found" for iSight 0x8300 (first built-in iSight on iMac G5 iSight ppc64).

Regards,
Étienne.

Hi,

Updated patch and tools for cleaner support of iSight on both powerpc and mactel boxes are available at http://bersace03.free.fr/ift . This patch builds on 2.6.24. Note the use of userspace tools to extract and load the firmware rather that loading AppleUSBVideoSupport driver into the kernel !

Regards,
Étienne.

Where does isight_usb come from ? isight is a UVC device and must be supported by UVC driver !

the isight_usb module is just a patched version of uvcvideo.

This bug is fixed in Hardy uvcvideo

cyberdork33, thanks for testing and the update. Am marking this 'Fix Released' against Hardy. Thanks.

This bug has appeared again in Ubuntu 8.04. I have kernel 2.6.24-19 with uvcvideo built from svn checked out tonight (9/27/2008) and my iSight (first gen Macbook) works fine at lowered resolutions but freezes the display at 640x480. I also have to unload and reload uvcvideo at startup. Relevant information:

dmesg:
[ 158.041941] Linux video capture interface: v2.00
[ 158.049687] uvcvideo: Found UVC 1.00 device Built-in iSight (05ac:8501)
[ 158.052028] uvcvideo: Failed to query (135) UVC control 1 (unit 0) : -32 (exp. 26).
[ 158.054037] input: Built-in iSight as /devices/pci0000:00/0000:00:1d.7/usb5/5-4/5-4:1.0/input/input16
[ 158.085543] usbcore: registered new interface driver uvcvideo
[ 158.085551] USB Video Class driver (SVN r252)

Ignore my last comment. While Ubuntu 8.04 does not work out of the box, after compiling the latest SVN, it seems to have started working.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.