-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 18.12.2011 20:37, schrieb Laurent Pinchart: > Hi Alexey, > > Thanks for the patch, and sorry for the late reply. > > On Monday 21 November 2011 15:51:47 Alexey Fisher wrote: >> Hi Laurent, >> >> here is my version of bug_report file for debugfs. It include >> usb.id, dmi.system.product (for upsidedown report). And stream >> specific information. I think it is good size for initial patch. >> I near future i would like to add control call count and control >> error rate to stats. And probably firs urb error number to report >> file. I think it will be enough to provide needed info for >> troubleshooting. > > I got a couple of comments regarding both the purpose of the patch > and its implementation. I'd like to discuss the purpose first. > > My understanding is that this new debugfs entry is meant to help > diagnosing and debugging issues. This is a nice thing, but most of > the debugging information (such as the USB VID:PID and the DMI > information) can already be obtained using lsusb and dmidecode. > Duplicating in debugfs information that is already available > through other means isn't something I'm very fond of. Sure, > dmidecode needs to be run as root, but if the user can't figure > that out I don't think getting him to moutn debugfs will be a great > success either :-)
Ok, i agree. The i suggest to add two updates for FAQ. 1) sudo echo 0xffff > /sys/module/uvcvideo/parameters/trace and sudo echo 0 > /sys/module/uvcvideo/parameters/trace should be probably corrected to: sudo sh -c "echo 0xffff > /sys/module/uvcvideo/parameters/trace" sudo sh -c "echo 0 > /sys/module/uvcvideo/parameters/trace" at least on ubuntu it is imposable to execute the previous version. 2) add in case of upside down webcam. sudo dmidecode -t system -t baseboard after some more time in this list i got some reasonable amount of skepticism. so i can agree to remove many of my previous suggestions :D Here i my current thoughts: - - Looks like bandwidth keeps to be a major problem. Last month there was cases with: lowspeed cam; high speed on low speed bus(?); advanced cases with more then one cam using jpeg compression (usually buggy cams)... i also noticed that people (including me) wont to know video format currently used by cam. So probably packet size, and frame format should be included in to debugfs report. - - other problem i noticed is: looks like uvcvideo collides some time with snd-usb-audio. For example if audio use lots of ctrl messages and get time out because of video stream, it resets usb device and kill both audio and video. Other example from one of last mails: ================================================= uvcvideo: uvc_set_video_ctrl: PROBE; bmHint: 1; bFormatIndex: 1; bFrameIndex: 8; dwFrameInterval: 333333; wKeyFrameRate: 0; wCompQuality: 0; wCompWindowSize: 0; wDelay: 0; dwMaxVideoFrameSize 0; dwMaxPayloadTransferSize: 0 5:3:1: cannot get freq at ep 0x82 uvcvideo: Failed to set UVC probe control : -32 (exp. 26). ================================================= if i interpret it correctly: video and audio send ctrl at same time and fail. -32 mean wrong pipe. am i correct? stand alone each works fine. for this case i have no idea for debugfs report. probably dmesg is the best way to do it. - -- Regards, Alexey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ucGMACgkQw8E0jNwoJm/SGgCcCeorwiDQCaWQ+x4gV1S3wfS2 XjsAoKwFbcuHaggi3dL2wdlAcwrQ647m =3sIb -----END PGP SIGNATURE----- _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
