Created attachment 399867 [details]
lsusb -vvv

Anything else I can help with? I can provide additional information if needed. And I don't mind to test something, if there's anything to test...

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Is this still failing on Fedora 14 Alpha and/or F13 with the 2.6.34 kernel installed?

Up! Good Sunday everybody.

Yes, here this is still failing on Fedora 14 released with the 2.6.35 kernel (latest stable, as updated via official repositories).

Laptop: Asus V1S-AS004E (Spanish keyboard)
Distro: Fedora 14 x86_64 (KDE)

# uname -a
Linux venus.xapaho.com 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

# lsusb | grep Syntek
Bus 001 Device 003: ID 174f:6a31 Syntek Web Cam - Asus A8J, F3S, F5R, VX2S, V1S

# dmesg | grep "usb 1-3"
[    3.578482] usb 1-3: new high speed USB device using ehci_hcd and address 3
[    3.942533] usb 1-3: New USB device found, idVendor=174f, idProduct=6a31
[    3.942537] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=10
[    3.942540] usb 1-3: Product: USB2.0
[    3.942542] usb 1-3: Manufacturer: Syntek

Created attachment 477300 [details]
lsusb -vvv (webcam section)

Here is a long post, which I wish I found here yesterday :)

*Workaround*

  For my specific system and kernel versions, cf. my previous comment, just above.

  There is a syntek kernel module out there (on sourceforge), which now works for me
  (just like it had worked on the same hardware, with Ubuntu, a couple of years ago).
  Googling, one can find many users who have based their solution on this code.

  Below were my steps (exhaustive list, rather simple). It will be required to repeat them,
    after each kernel update, or until the current svn code gets packaged with the kernel ?
    The sooner, the better (for me, anyway ^^)

  For reference :

    http://www.stk.com.tw/product-01.asp?Product_Type=32
      The constructor does proudly "announce" Linux kernel support for the product family,
      but in facts, stable kernels would include support only for one of their models
      (as supported by the open source project when it got inserted, I guess)

    http://syntekdriver.sourceforge.net/
      the latest *release* (2.1.0) did not compile on my system.
      the latest *svn* trunck (rev 99), *did* compile and work correctly.

    http://doc.ubuntu-fr.org/syntek
      the Ubuntu folks refer to some 3rd party Makefile which may not be recommended here
      (and this tutorial may be outdated already)

  Please note :
   $ = command I did run as normal user
   # = command I did run as root

  1) Get the latest syntek driver code from svn repository on sourceforge
     $ mkdir syntek-svn
     $ cd syntek-svn
     $ svn co https://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/trunk/driver

     This checked out rev 99 of the trunk, creating a new "driver" subfolder.
     Accepted permanently sourceforge SVN's current fingerprint
       94:74:b3:a9:54:ce:dc:e5:0d:d6:cf:86:b1:40:5a:48:b9:ea:15:de
     which can be verified here using any modern browser (look at the certificate)
       https://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/

  2) As stated in the README file, compiling does require
     - kernel development resources (package "kernel-devel" & co. were already installed here)
       http://fedoraproject.org/wiki/Docs/CustomKernel#Building_Only_Kernel_Modules_.28Out_Of_Tree_Modules.29
     - Doxygen, to compile the documentation (optional)
     # yum install doxygen

  3) Compile the kernel module
     $ cd driver
     $ make -f Makefile.standalone driver

  4) If ctags were not available on the system (package "ctags"),
       then the following error came up, which should be safe to ignore (didn't try)
     make: ctags: Command not found
     make: *** [driver] Error 127

     Retrying with ctags installed, did compile without any error
     $ make -f Makefile.standalone clean
     # yum install ctags
     $ make -f Makefile.standalone driver

  5) Compile the documentation (optional)
    - despite a large number of warnings, a "doxygen" subfolder appeared in "syntek-svn"
    - starting point is "syntek-svn/doxygen/html/index.html"... which looks a little outdated :)
     $ make -f Makefile.standalone doc

  6) Install the new kernel module on the system

     Place it in a new "extra" subfolder, ensuring it won't get mixed up with official modules
     # mkdir /lib/modules/`uname -r`/kernel/drivers/extra
     # cp stk11xx.ko /lib/modules/`uname -r`/kernel/drivers/extra

     Load it
     # depmod -a
     # modprobe stk11xx

     This webcam has a small activity led : it did just blink during modprobe
     Now check system messages (quoting only the relevant part here)

     # dmesg
     [ 6695.284811] Linux video capture interface: v2.00
     [ 6695.294104] stk11xx: Syntek USB2.0 webcam driver startup
     [ 6695.294107] stk11xx: Copyright(c) 2006-2009 Nicolas VIVIEN
     [ 6695.294135] stk11xx: Syntek USB2.0 - STK-1135 based webcam found.
     [ 6695.294137] stk11xx: Syntek AVStream USB2.0 1.3M WebCam - Product ID 0x6A31.
     [ 6695.294140] stk11xx: Release: 0005
     [ 6695.294142] stk11xx: Number of interfaces : 1
     [ 6695.294759] stk11xx: Initialize USB2.0 Syntek Camera
     [ 6695.402091] stk11xx: Check device return error (0x0201 = 0C) !
     [ 6695.477962] stk11xx: Syntek USB2.0 Camera is ready
     [ 6695.479181] stk11xx: Syntek USB2.0 Camera is now controlling video device /dev/video0
     [ 6695.479264] usbcore: registered new interface driver usb_stk11xx_driver
     [ 6695.479270] stk11xx: v2.2.0 : Syntek USB Video Camera

  7) Test it

     Start Kopete, menu Settings/Configure: takes a few seconds to open, light's on..
       Go to the Video tab and smile to yourself, it's a start :)

     vlc captures the video stream fine, using device "/dev/video0" here.
     Google Talk plugin just works, so does Skype videoconference.
       On my system however, neither of Skype's "test box", nor its local video, are drawn.
       This is most probably off-topic, related to a issue I have with the "nouveau" driver.

     Test after reboot: the led blinks twice before the login screen, all still works.

     Save the generated documentation and keep the whole "syntek-svn" folder for future use.
     Repeat all steps (update svn, next time) after each kernel update if still required.

Good Sunday,

New kernel is out, installed, tested : still no support for this webcam.
(2.6.35.11-83.fc14.x86_64)

Unfortunately, here I could not compile the module against this kernel.
This goes beyond my linux knowledge, will report to the module authors.
Here were my steps, any help or comments, very welcome !

  8) Recompiling the module against a new kernel 

     Double-checked that kernel-headers and kernel-devel,
     were updated for this kernel
     a. $ yum list installed kernel-*
        Installed Packages
        kernel.x86_64          2.6.35.10-74.fc14  @updates
        kernel.x86_64          2.6.35.11-83.fc14  @updates
        kernel-devel.x86_64    2.6.35.10-74.fc14  @updates
        kernel-devel.x86_64    2.6.35.11-83.fc14  @updates
        kernel-headers.x86_64  2.6.35.11-83.fc14  @updates
     Previous kernel's headers were not added, but replaced (?)

     Checking the module's source repository for updates
     b. $ cd syntek-svn/driver
     c. $ svn up
         (No update is available, latest is still rev. 99)

     If the doc had been updated (which is not the case)
     d. $ make -f Makefile.standalone cleandoc
     e. $ make -f Makefile.standalone doc

     Recompiling the kernel module
     f. $ make -f Makefile.standalone clean
     g. $ make -f Makefile.standalone driver

     If the module was compiled successfully: repeat steps 6 and 7.

At point g. all I get is a long list of declaration errors such as:

  make[1]: Entering directory `/usr/src/kernels/2.6.35.11-83.fc14.x86_64'
  CC [M]  .../syntek-svn/driver/stk11xx-usb.o
  CC [M]  .../syntek-svn/driver/stk11xx-v4l.o
  .../syntek-svn/driver/stk11xx-v4l.c: In function ‘v4l_stk11xx_do_ioctl’:
  .../syntek-svn/driver/stk11xx-v4l.c:668:8: error: ‘VIDIOCGCAP’ undeclared
  (first use in this function)
  ...
  .../syntek-svn/driver/stk11xx-v4l.c:674:27: error: dereferencing pointer to
  incomplete type
  ...
  make: *** [driver] Error 2

Booting under the previous kernel, everything still works just fine.
(2.6.35.10-74.fc14.x86_64)
For completion, I tried again to compile the module: still does.

In the last kernel's release notes, are many entries related to V4L.
Could the video symbols have changed, with no backward compatibility ?
http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.35/ChangeLog-2.6.35.11

Xavier

Good Saturday,

Workaround update

Webcam still work like a charm here ...BUT

* using before-last stable kernel, not the latest stable
  (sticking to 2.6.35.10-74.fc14.x86_64)

* using a specific revision of the stk11xx module, not the HEAD
  (sticking to rev. 99 since latest 100:101 won't build here)

  Erratum cf. step 1) and 8) c. here above (respectively):
  $ svn co -r 99 https://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/trunk/driver
  $ svn up -r 99

* with some extra precaution, or the kernel will crash !!
  first time I saw F14 crashing here, you've been warned ^^
  just let each webcam-aware application complete webcam init
  (light blinks on then off)
  before launching another one (eg. two concurrent skype ids)

Detailed info and bug reports I filled today
  https://sourceforge.net/projects/syntekdriver/forums/forum/616183/topic/3353497
  https://sourceforge.net/tracker/?func=detail&aid=3187002&group_id=178178&atid=884191
  https://sourceforge.net/tracker/?func=detail&aid=3187013&group_id=178178&atid=884191
  https://sourceforge.net/tracker/?func=detail&aid=3187003&group_id=178178&atid=884191

I could reproduce the kernel crash "on-demand" and reported it first via ABRT (first crash wasn't detected, system log just aborted), but I can't find its URL right now (is kerneloops.org front end in troubles ?), nor can I find anything related to 2.6.35 (?).
  https://sourceforge.net/tracker/?func=detail&aid=3187007&group_id=178178&atid=884191

With hope this will helps others already, happy workaround ^^
Any further info needed ?

Xavier

Good Saturday,

Today I could reproduce the kernel oops once again (see "extra precaution here before"), and finally also use ABRT BZ plugin to report it here

https://bugzilla.redhat.com/show_bug.cgi?id=682459

Any further info needed ?
Best regards,
Xavier

Good Friday,

There is a patch available, which prevents the kernel crash mentioned earlier.

From my daily use over the past few weeks, I can confirm this provides me with a stable usage for this webcam on Fedora (still using module source rev.99 and kernel 2.6.35.10-74.fc14.x86_64)

patch:
(to be applied after step 1) and 8) c. here above)
http://sourceforge.net/tracker/download.php?group_id=178178&atid=884191&file_id=403550&aid=3187007

thread:
http://sourceforge.net/tracker/?func=detail&aid=3187007&group_id=178178&atid=884191

Xavier

This isn't going to be fixed in f14.  The best chance you have is to work with the driver authors to get the driver into the staging tree and into mainline from there.

Hi, this bug still applies to Fedora 16 (kernel 3.2.6-3.fc16.x86_64).

Current HowTo for Fedora 16 (long overdue !) is here.
There were great improvement in sourceforge module in the mean time.

https://sourceforge.net/projects/syntekdriver/forums/forum/616183/topic/5055644

Hope it helps others.


(In reply to comment #12)
> This isn't going to be fixed in f14.  The best chance you have is to work with
> the driver authors to get the driver into the staging tree and into mainline
> from there.

Indeed, thanks Josh. Another module from the same author *is* included upstream for a while (but does not support this webcam model) :

$ modinfo stkwebcam
filename:       /lib/modules/3.2.6-3.fc16.x86_64/kernel/drivers/media/video/stkwebcam.ko
description:    Syntek DC1125 webcam driver
author:         Jaime Velasco Juan <jsagarribay> and Nicolas VIVIEN

Thanks,

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Is this still a problem with 3.9 based F19 kernels?

Justin, this month I'm hoping to test Fedora 19 pre-releases on this hardware...

So far it (still..) greatly runs Fedora 16, latest stock kernel, with syntekdriver module built locally (from rev-107 at sourceforge, plus a few remaining patches, now very minor. And I've scripted it all for so long that I almost forgot about it \o/). Beyond this, I only tested stock kernels from Live releases (up to F18 final, no respins yet).

F16 up to 3.6.11-4 : unsupported but syntekdriver works flawlessly.
F18 up to 3.6.10-4 : unsupported, syntekdriver not yet tested
any later 3.7+ : not yet tested

This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks.  If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.