Bug 248926 - Logitech HD Pro Webcam C920 USB_ERR_TIMEOUT
Summary: Logitech HD Pro Webcam C920 USB_ERR_TIMEOUT
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Hans Petter Selasky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-26 10:05 UTC by Ganael LAPLANCHE
Modified: 2020-12-02 11:29 UTC (History)
2 users (show)

See Also:


Attachments
Kernel messages with hw.usb.debug set (73.48 KB, text/plain)
2020-08-26 19:33 UTC, Ganael LAPLANCHE
no flags Details
usbdump logs while running "usbconfig set_config 0" (53.13 KB, text/plain)
2020-08-26 19:48 UTC, Ganael LAPLANCHE
no flags Details
usbdump logs while running "usbconfig dump_all_desc" (58.92 KB, text/plain)
2020-08-26 20:00 UTC, Ganael LAPLANCHE
no flags Details
usbdump logs while running "usbconfig dump_all_config_desc" (53.13 KB, text/plain)
2020-08-26 20:03 UTC, Ganael LAPLANCHE
no flags Details
usbconfig dump_all_desc output after patch (35.92 KB, text/plain)
2020-08-28 17:49 UTC, Ganael LAPLANCHE
no flags Details
Patch attempt for webcamd (806 bytes, patch)
2020-08-28 18:23 UTC, Ganael LAPLANCHE
no flags Details | Diff
usbcump logs while starting webcamd (9.05 KB, text/plain)
2020-08-30 10:30 UTC, Ganael LAPLANCHE
no flags Details
Working patch for webcamd (3.08 KB, patch)
2020-09-04 15:19 UTC, Ganael LAPLANCHE
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 10:05:32 UTC
Hello,

My Logitech HD Pro Webcam C920 does not work correctly on -CURRENT.

# uname -a
FreeBSD laptop.martymac.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r364057: Mon Aug 10 11:25:36 UTC 2020     root@laptop.martymac.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Here are my kernel logs :

Aug 25 18:52:22 laptop kernel: usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 2, addr 4 (ignored)
Aug 25 18:52:22 laptop kernel: ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1

and usbconfig output :

ugen1.1: <Intel EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.1: <Intel EHCI root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen2.2: <vendor 0x8087 product 0x0024> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <vendor 0x8087 product 0x0024> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.3: <Chicony Electronics Co., Ltd. Integrated Camera> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

Dumping all configuration descriptors seems to timeout :

# usbconfig -d ugen1.4 dump_all_desc
ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x00ef  <Miscellaneous device>
  bDeviceSubClass = 0x0002 
  bDeviceProtocol = 0x0001 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x046d 
  idProduct = 0x0892 
  bcdDevice = 0x0019 
  iManufacturer = 0x0000  <no string>
  iProduct = 0x0002  <HD Pro Webcam C920>
  iSerialNumber = 0x0001  <AF8FC4EF>
  bNumConfigurations = 0x0001 

<waits a bit... and nothing more>

Finally, webcamd-5.7.1.1_1 gives me the following :

Aug 25 18:52:23 laptop webcamd[1422]: webcamd: Cannot find USB device

Note that idProduct (0x0892) is different from usual HD Pro Webcam C920 (0x082d) as found on :

https://wiki.freebsd.org/WebcamCompat

maybe a new version of the product (I've just received it) ?

Best regards,

Ganael.
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 10:37:24 UTC
I think I read somewhere in the Linux code that this device is quirked!

Try:

usbconfig -d X.Y set_config 0

Then attach webcamd manually.

X.Y are numbers after ugenX.Y

Search the Linux kernel code for .idVendor and .idProduct values.

--HPS
Comment 2 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 19:23:13 UTC
Hello Hans Petter,

Thanks for your answer.

You may be talking about the following, as seen in drivers/usb/core/quirks.c :
  
        /* Logitech HD Pro Webcams C920, C920-C, C922, C925e and C930e */
        { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
        { USB_DEVICE(0x046d, 0x0841), .driver_info = USB_QUIRK_DELAY_INIT },
        { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT },
        { USB_DEVICE(0x046d, 0x085b), .driver_info = USB_QUIRK_DELAY_INIT },
        { USB_DEVICE(0x046d, 0x085c), .driver_info = USB_QUIRK_DELAY_INIT },

but I could not find any quirk for product 0x0892 (I know the webcam works on Ubuntu 20: I successfully tested it).

Also, "usbconfig -d 1.3 set_config 0" does not seem to produce anything interesting (no new kernel message), and webcamd still fails to find USB device afterwards :/

Best regards,
Ganael.
Comment 3 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 19:26:56 UTC
> You may be talking about the following, as seen in drivers/usb/core/quirks.c

Yes.

What does usbconfig report in the cfg= field after you executed set_config 0 ?

--HPS
Comment 4 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 19:33:36 UTC
Created attachment 217550 [details]
Kernel messages with hw.usb.debug set

Just in case, here are my kernel logs when calling "usbconfig -d 1.3 set_config 0" with hw.usb.debug set.
Comment 5 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 19:35:35 UTC
> What does usbconfig report in the cfg= field after you executed set_config 0 ?

Still 255 (cfg=255)
Comment 6 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 19:37:00 UTC
Could you get USBDUMP logs instead:

usbdump -i usbusX -f Y -vvv -s 65536

--HPS
Comment 7 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 19:38:16 UTC
> Still 255 (cfg=255)

It means the device did not accept the command.

--HPS
Comment 8 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 19:48:38 UTC
Created attachment 217551 [details]
usbdump logs while running "usbconfig set_config 0"

Yes, here they are :)
Comment 9 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 19:51:19 UTC
From the log you attached I see there is a problem reading the configuration descriptor. Can you show the device descriptor using usbconfig ?

--HPS
Comment 10 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 20:00:54 UTC
Created attachment 217552 [details]
usbdump logs while running "usbconfig dump_all_desc"

I can show the device descriptor (dump_device_desc works) but dump_all_desc seems to timeout and only shows device descriptor and no configuration descriptor.
Comment 11 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-26 20:03:21 UTC
Created attachment 217553 [details]
usbdump logs while running "usbconfig dump_all_config_desc"
Comment 12 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-26 20:18:16 UTC
Can you try this patch:

Index: sys/dev/usb/usb_request.c
===================================================================
--- sys/dev/usb/usb_request.c	(revision 364423)
+++ sys/dev/usb/usb_request.c	(working copy)
@@ -1010,7 +1010,7 @@
 		USETW(req.wLength, min_len);
 
 		err = usbd_do_request_flags(udev, mtx, &req,
-		    desc, 0, NULL, 500 /* ms */);
+		    desc, 0, NULL, 1000 /* ms */);
 
 		if (err != 0 && err != USB_ERR_TIMEOUT &&
 		    min_len != max_len) {
@@ -1021,7 +1021,7 @@
 			USETW(req.wLength, max_len);
 
 			err = usbd_do_request_flags(udev, mtx, &req,
-			    desc, USB_SHORT_XFER_OK, NULL, 500 /* ms */);
+			    desc, USB_SHORT_XFER_OK, NULL, 1000 /* ms */);
 
 			if (err == 0) {
 				/* verify length */


I think the problem is the device is responding a bit too slow!

--HPS
Comment 13 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-27 05:41:37 UTC
Hello,

Thanks for your patch! I'll try it and get back to you ASAP :)
Comment 14 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-28 15:14:19 UTC
Ping.
Comment 15 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-28 17:47:52 UTC
Hello,

Sorry for the delay, it took more time than expected to rebuild the kernel on my laptop.

Good catch! Now the webcam is properly initialized (and I can successfully dump all descriptors), I also get an uaudio0 device!

Unfortunately webcamd still cannot find USB device. It probably needs a patch to attach to product ID 0x0892. I'll see if I can make the webcam recognized.

Thanks!
Comment 16 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-28 17:49:13 UTC
Created attachment 217597 [details]
usbconfig dump_all_desc output after patch
Comment 17 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-28 18:23:46 UTC
Created attachment 217599 [details]
Patch attempt for webcamd

No luck, I tried the simple patch attached, but it did not work. Am I missing something ?
Comment 18 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-28 19:19:41 UTC
Comment on attachment 217599 [details]
Patch attempt for webcamd

+	  .bInterfaceClass	= USB_CLASS_VIDEO,
+	  .bInterfaceSubClass	= 1,
+	  .bInterfaceProtocol	= 0,

Check that these values also match!

--HPS
Comment 19 commit-hook freebsd_committer freebsd_triage 2020-08-28 19:22:10 UTC
A commit references this bug:

Author: hselasky
Date: Fri Aug 28 19:21:11 UTC 2020
New revision: 364932
URL: https://svnweb.freebsd.org/changeset/base/364932

Log:
  Allow slow USB devices to be given more time to return their USB descriptors,
  like Logitech HD Pro Webcam C920.

  PR:		248926
  MFC after:	1 week
  Sponsored by:	Mellanox Technologies

Changes:
  head/sys/dev/usb/usb_request.c
Comment 20 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-28 21:34:07 UTC
> Check that these values also match!

They seem so.

I have just found that vendor 0x046d / product 0x0892 should be handled by the gspca/vc032x driver, not uvc as I originally thought. The uvc driver only handles another kind of C920, with product ID 0x082d.

So Logitech seems to sell two versions of the C920 and my webcam appears as Orbicam in the driver's code.

Anyway, this is weird as gspca/vc032x is enabled and should detect the webcam...

Best regards,

Ganael.
Comment 21 Hans Petter Selasky freebsd_committer freebsd_triage 2020-08-29 08:53:45 UTC
Try to run usbdump -i usbusX -f Y while attaching webcamd, to see if there are any more USB errors.

--HPS
Comment 22 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-29 13:52:39 UTC
OK, thanks for the hint. I'll try that ASAP.

Best regards,

Ganael.
Comment 23 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-08-30 10:30:20 UTC
Created attachment 217643 [details]
usbcump logs while starting webcamd

Hello,

Find attached usbdump logs when running webcamd. It seems the last request has stalled ?
Comment 24 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-09-04 15:19:58 UTC
Created attachment 217748 [details]
Working patch for webcamd

Hello,

Finally I got the webcam working with webcamd. It seems that the gspca/vc032x driver catches the webcamd before uvc and fails to handle the device properly.

The attached patch disables detection of product ID 0x0892 within vc032x and adds appropriate product ID to uvc.

With that patch, I am able to use the device with vlc.

Best regards,

Ganael.
Comment 25 Hans Petter Selasky freebsd_committer freebsd_triage 2020-09-04 16:05:57 UTC
This patch should go upstream Linux first:

linux-media@vger.kernel.org

--HPS
Comment 26 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-09-08 10:26:17 UTC
Hello,

Thanks, but there is something I don't understand.

My patch here forces uvc driver to handle the device, but that may not be the best fix (because I have to disable original orbicams support).

On Linux (Debian 10), both drivers are loaded and my webcam works natively. I don't think that Debian has local patches to add support for product ID 0x0892 within uvc so, in some way, both drivers (gspca/vc032x and uvc) manage to handle the device.

I don't know how they relate to each other, though. I am thinking to something as gspca/vc032x acting as a "frontend" driver and delegating USB video class management to the uvc driver afterwards. Is that possible ? Is there a possibility webcamd misses something in that area ?

(also, as a side note, Logitech support has just confirmed that my device is not a fake)
Comment 27 Hans Petter Selasky freebsd_committer freebsd_triage 2020-09-08 10:53:15 UTC
It may be a race that UVC wins over the other driver, or they have some kind of priority.

Can you check if both drivers are attached to the device in Linux? How many V4L devices are produced?

--HPS
Comment 28 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-09-08 16:19:22 UTC
Hello,

Reading kernel logs, we can see that gspca_vc032x tries to attach to the webcam but fails. Finally, uvcvideo handles the device :

Sep  8 17:32:23 usbkey kernel: [   36.871243] gspca_main: v2.14.0 registered
Sep  8 17:32:23 usbkey kernel: [   36.886648] gspca_main: vc032x-2.14.0 probing 046d:0892
Sep  8 17:32:23 usbkey kernel: [   36.887121] gspca_vc032x: reg_r err -32
Sep  8 17:32:23 usbkey kernel: [   36.898532] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:0892)
Sep  8 17:32:23 usbkey kernel: [   36.900605] uvcvideo 3-2:1.0: Entity type for entity Processing 3 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900608] uvcvideo 3-2:1.0: Entity type for entity Extension 6 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900609] uvcvideo 3-2:1.0: Entity type for entity Extension 8 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900611] uvcvideo 3-2:1.0: Entity type for entity Extension 9 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900612] uvcvideo 3-2:1.0: Entity type for entity Extension 10 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900613] uvcvideo 3-2:1.0: Entity type for entity Extension 11 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900614] uvcvideo 3-2:1.0: Entity type for entity Extension 13 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.900616] uvcvideo 3-2:1.0: Entity type for entity Camera 1 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.901788] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b2eb)
Sep  8 17:32:23 usbkey kernel: [   36.913210] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.913213] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.913215] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.913216] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not initialized!
Sep  8 17:32:23 usbkey kernel: [   36.913358] usbcore: registered new interface driver uvcvideo

Afterwartds, I get the following :

# lsmod | grep -e uvc -e vc032x
gspca_vc032x           36864  0
gspca_main             28672  1 gspca_vc032x
uvcvideo              118784  0
videobuf2_vmalloc      16384  2 gspca_main,uvcvideo
videobuf2_v4l2         28672  2 gspca_main,uvcvideo
videobuf2_common       53248  3 gspca_main,videobuf2_v4l2,uvcvideo
videodev              212992  5 gspca_main,videobuf2_v4l2,uvcvideo,videobuf2_common,gspca_vc032x
media                  45056  2 videodev,uvcvideo
usbcore               294912  11 gspca_main,xhci_hcd,ehci_pci,snd_usb_audio,snd_usbmidi_lib,usb_storage,uvcvideo,ehci_hcd,xhci_pci,uas,gspca_vc032x

So gspca_vc032x does *not* use uvcvideo, they act as two separate drivers.

I finally get 4 video devices :

# ls -al /dev/video*
crw-rw----+ 1 root 81, 0 Sep  8 17:05 /dev/video0
crw-rw----+ 1 root 81, 1 Sep  8 17:05 /dev/video1
crw-rw----+ 1 root 81, 2 Sep  8 17:06 /dev/video2
crw-rw----+ 1 root 81, 3 Sep  8 17:06 /dev/video3

The good one is /dev/video2 (usable in vlc), /dev/video0 is for my integrated webcam. I don't know for the others.

# ls -l /sys/dev/char/81:*/device/driver
lrwxrwxrwx 1 root 0 Sep  8 17:10 /sys/dev/char/81:0/device/driver -> ../../../../../../../bus/usb/drivers/uvcvideo
lrwxrwxrwx 1 root 0 Sep  8 17:10 /sys/dev/char/81:1/device/driver -> ../../../../../../../bus/usb/drivers/uvcvideo
lrwxrwxrwx 1 root 0 Sep  8 17:10 /sys/dev/char/81:2/device/driver -> ../../../../../../bus/usb/drivers/uvcvideo
lrwxrwxrwx 1 root 0 Sep  8 17:10 /sys/dev/char/81:3/device/driver -> ../../../../../../bus/usb/drivers/uvcvideo

We can see that all video* devices are handled through uvcvideo.

That leads to two questions :
- does Webcamd try other drivers if a previous one (with a matching vendorId:productId couple) fails to attach ?
- how does uvcvideo attach to the device as I cannot find productId 0x0892 anywhere in its code ?

For that second question, it seems that uvc_driver.c, function uvc_probe() is able to probe non-declared (generic) UVC devices, so we might be in a "fallback" case here. Remains the first question, then.

A last precision: uvcvideo.ko comes from linux-image-4.19.0-10-amd64 (Debian 10) and I could not find local (Debian) patches to add productId 0x0892.
Comment 29 Hans Petter Selasky freebsd_committer freebsd_triage 2020-09-08 17:37:08 UTC
I see.

Try this patch for webcamd:
https://github.com/hselasky/webcamd/commit/9ddac5ff8ef5009bd6ad4e048a391268ceb1d186


--HPS
Comment 30 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-09-08 19:09:18 UTC
Yes! It works like a charm :)

Thanks a lot HPS !
Comment 31 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-09-10 16:49:46 UTC
I think that PR can be close by now, thanks again :)
Comment 32 commit-hook freebsd_committer freebsd_triage 2020-09-21 18:28:45 UTC
A commit references this bug:

Author: hselasky
Date: Mon Sep 21 18:27:44 UTC 2020
New revision: 365964
URL: https://svnweb.freebsd.org/changeset/base/365964

Log:
  MFC r364932:
  Allow slow USB devices to be given more time to return their USB descriptors,
  like Logitech HD Pro Webcam C920.

  PR:		248926
  Sponsored by:	Mellanox Technologies

Changes:
_U  stable/12/
  stable/12/sys/dev/usb/usb_request.c
Comment 33 commit-hook freebsd_committer freebsd_triage 2020-09-21 18:28:46 UTC
A commit references this bug:

Author: hselasky
Date: Mon Sep 21 18:28:23 UTC 2020
New revision: 365965
URL: https://svnweb.freebsd.org/changeset/base/365965

Log:
  MFC r364932:
  Allow slow USB devices to be given more time to return their USB descriptors,
  like Logitech HD Pro Webcam C920.

  PR:		248926
  Sponsored by:	Mellanox Technologies

Changes:
_U  stable/11/
  stable/11/sys/dev/usb/usb_request.c
Comment 34 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-10-07 19:22:19 UTC
Hello Hans Petter,

Any chance to get r364932 merged back to 12.2 branch ?

Thanks in advance,
Best regards,

Ganael.
Comment 35 Hans Petter Selasky freebsd_committer freebsd_triage 2020-10-07 20:25:00 UTC
Try sending a message to re@ about that.
Comment 36 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-10-09 20:13:45 UTC
Hello,

A quick followup: it's too late to get the patch merged to 12.2. It may be merged later as an errata notice.

Stay tuned!

Best regards,

Ganael.
Comment 37 commit-hook freebsd_committer freebsd_triage 2020-10-14 06:26:37 UTC
A commit references this bug:

Author: martymac
Date: Wed Oct 14 06:25:55 UTC 2020
New revision: 366693
URL: https://svnweb.freebsd.org/changeset/base/366693

Log:
  MFS r365964:
  Allow slow USB devices to be given more time to return their USB descriptors,
  like Logitech HD Pro Webcam C920.

  PR:		248926
  Approved by:	re (gjb), hselasky

Changes:
_U  releng/12.2/
  releng/12.2/sys/dev/usb/usb_request.c
Comment 38 Ganael LAPLANCHE freebsd_committer freebsd_triage 2020-10-14 06:31:31 UTC
As a third RC will finally be built, the patch has been merged and will be present in 12.2-RC3. Let's close that PR for real now :)
Comment 39 commit-hook freebsd_committer freebsd_triage 2020-12-02 11:29:40 UTC
A commit references this bug:

Author: hselasky
Date: Wed Dec  2 11:29:10 UTC 2020
New revision: 556814
URL: https://svnweb.freebsd.org/changeset/ports/556814

Log:
  Update webcamd to 5.7.1.2

  List of changes:
  - Try probing more drivers, when probe fails (PR 248926)
  - While at it, use GitHub to provide the required tarball archives

  PR:		248926
  Submitted by:	martymac@FreeBSD.org
  Approved by:	pi (implicit)

Changes:
  head/multimedia/webcamd/Makefile
  head/multimedia/webcamd/distinfo
  head/multimedia/webcamd/pkg-descr