# Kernel driver doesn't work with webcam

## TimeManx

I just got this webcam Genius iSlim 1300AF V2. Every application displays a black screen for the device except for mplayer which displays a green screen. Upon a little googling, I found this thread where the user seems to have the exact same problem with probably an almost same webcam.

The user has identified the kernel versions between which the regression occurs. But I don't understand the instructions that have been given to him to troubleshoot the problem. I understand I need to revert the patches between those versions but have no idea how to.

Would help if someone could explain what I need to do.

Here's the output of lsusb -vvv -d 0458:7067 (link)

and mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 30 (link)

----------

## khayyam

TimeManx ...

I have/had the exact same issue with the builtin iSight (macbook 1,1), which also uses the uvcvideo driver. Its currently the only piece of hardware that doesn't work, and prior to giving up on it I'd spent some time trying to figure out why, as I'd read in various places (including the Gentoo and Arch macbook wiki's) that it "works out of the box ... without the need of apple firmware" with recent uvcvideo releases. I'd assumed at the time that the reason I couldn't get it working was due to my booting EFI natively, but as I don't really need the thing, and was primarily fiddling with it for the sake of being able to say "everything works", I didn't look into it further.

In my case, the device seems to be recognised, the driver loads without error, and /dev/video0 is created. I didn't test with anything other than mplayer (actually, mplayer2) but likewise am provided with a "green screen".

As for the "instructions", the developer is requesting that the reporter do a "git bisect", build and boot each revision based on commits made up-to, and subsequent to, the "regression" (or breakage). This is done so that the code that introduced the problem can be isolated, reported upstream, and hopefully fixed. So, in short, there is no fix provided, unless you wanted to revert to a kernel prior to the issue being introduced (2.6.38), just a means of tracking down the issue.

Assuming this were fixed I don't think it'd work in my case regardless, if the firmware (which is now supposedly not needed) isn't loaded no device nodes are created, this suggests to me that there would be issues other than those introduced by the regression, and I'm simply not prepared to spend any more time on the issue. I also noticed in the uvcvideo_isight code that the particular device string its looking for is hardcoded for a later hardware revision, so obvious, this is likely to cause my particular chipset to not be recognised. This may be the reason the firmware loading method gets somewhere, and the "out of the box" method does nothing ... but I digress.

So, there probably isn't a fix other than going back to a 2.6.38 kernel, at least in the short term. It does seem that we have a similar problem though, and so I think its probably correct to assume that something was inroduced arround 2.6.39 that broke it.

best ... khay

----------

## BillWho

TimeManx,

I have a Logitech Quickcam Fusion and it suffers from a firmware bug that makes the camera unstable in linux. It works fine in windows.

The suggested workarounds I found at various sites were very unpredictable and inconsistent to the degree that it rendered them useless    :Sad: 

I found this site  to be a decent reference, though a little outdated. It lists a Genius iSlim 1300 V2,which is supposed to be good-to-go with linux, but maybe it's not the exact model that you have.

Unfortunately, these webcam problems have been plaguing linux for quite a long time with no discernible planned resolutions. 

Good luck   :Wink: 

----------

## TimeManx

Thanks for the input guys. Really appreciated.

 *BillWho wrote:*   

> I found this site to be a decent reference, though a little outdated. It lists a Genius iSlim 1300 V2,which is supposed to be good-to-go with linux, but maybe it's not the exact model that you have.

 

It works actually but only uptil kernel 2.6.38.  I had found the website too while trying to find a fix but it is quite outdated.

I actually did a git bisect and found the bad commit. I'm gonna report it upstream and hope it gets somewhere.

----------

## TimeManx

 *khayyam wrote:*   

> I have/had the exact same issue with the builtin iSight (macbook 1,1), which also uses the uvcvideo driver

 

It seems my webcam works on disabling CONFIG_USB_SUSPEND in the kernel. Maybe you could try compiling the kernel without CONFIG_USB_SUSPEND. That would help confirm if both our issues occur because of the same commit.

----------

## khayyam

 *TimeManx wrote:*   

> It seems my webcam works on disabling CONFIG_USB_SUSPEND in the kernel. Maybe you could try compiling the kernel without CONFIG_USB_SUSPEND. That would help confirm if both our issues occur because of the same commit.

 

OK, I tryed that but I think my particular problem has additional factors. Firstly, the uvcvideo_driver.c has the following:

```
    /* Apple Built-In iSight */

    { .match_flags      = USB_DEVICE_ID_MATCH_DEVICE

                | USB_DEVICE_ID_MATCH_INT_INFO,

      .idVendor     = 0x05ac,

      .idProduct        = 0x8501,

      .bInterfaceClass  = USB_CLASS_VIDEO,

      .bInterfaceSubClass   = 1,

      .bInterfaceProtocol   = 0,

      .driver_info      = UVC_QUIRK_PROBE_MINMAX

                | UVC_QUIRK_BUILTIN_ISIGHT },
```

However my (macbook 1,1) idProduct is 0x8300

```
% lsusb | grep -Po '(?<=:)(\d+)(?=.*iSight)'

8300
```

Editing uvcvideo_driver.c to reflect this idProduct changes nothing, the uvcvideo loads but no devices are created, and lsusb reports that "no firmware is loaded" ..

```
% modprobe uvcvideo

% ls /dev/video*

ls: cannot access /dev/video*: No such file or directory

% lsusb |grep iSight

Bus 001 Device 003: ID 05ac:8300 Apple, Inc. Built-in iSight (no firmware loaded)
```

From all reports uvcvideo works "out of the box" without Apple's firmware, but this may be the case for idProduct 8501 only.

The next option might be to use USB_ISIGHTFW and the userland tools to load the extracted Apple firmware, but my kernel sources are de-blobbed, and so this won't work without my re-installing the sources with blobs intact.

In all other regards I'm completely Apple free, and until recently (3.4.2) the only possible reason for having an OSX boot disk is so that I can 'bless' the efi bootloader in case I should have to re-install, I no longer need this as with emibootmgr I can set efi envars. So, if the firmware is required its just another dependency resulting from Apple's ongoing lockout strategy and I'm not sure I need the cam enough to bother.

Also, the specific firmware I have is known to have issues, and an older version is generally recommended, so it still may not work after jumping through so many hoops ... and I'm not really cut out to be a circus pony :)

Anyhow, thanks for the ongoing feedback, I'd like to be able to say "yes .. disabling USB_SUSPEND resolves the issue", but without going the extra mile (or ^10), I can't, and can only see further issues down the line, and more time wasted.

best ... khay

----------

