Hi again,
On Tue, Nov 22, 2022 at 04:48:33PM +0800, Ai Chao wrote:
> For Alcor Corp. Slave camera(1b17:6684/2017:0011), it support to output
> compressed video data, and it return a wrong dwMaxPayloadTransferSize
> fields. This is a fireware issue, but the manufacturer cannot provide
> a const return fieldsby the fireware. For some device, it requested
> 2752512 B/frame bandwidth. For normally device, it requested 3072 or 1024
> B/frame bandwidth. so we check the dwMaxPayloadTransferSize fields,if it
> large than 0x1000, reset dwMaxPayloadTransferSize to 1024, and the camera
> preview normally.
>
> Signed-off-by: Ai Chao <aichao@xxxxxxxxxx>
>
> ---
> change for v4
> - Change usb_match_one_id to usb_match_id
> - Modify the discription
>
> change for v3
> - Add VID/PID 2017:0011
>
> change for v2
> - Used usb_match_one_id to check VID and PID
> ---
> ---
> drivers/media/usb/uvc/uvc_video.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index d2eb9066e4dc..75bdd71d0e5a 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -135,6 +135,11 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
> static const struct usb_device_id elgato_cam_link_4k = {
> USB_DEVICE(0x0fd9, 0x0066)
> };
> + static const struct usb_device_id alcor_corp_slave_cam[] = {
> + { USB_DEVICE(0x2017, 0x0011) },
> + { USB_DEVICE(0x1b17, 0x6684) },
> + { }
> + };
> struct uvc_format *format = NULL;
> struct uvc_frame *frame = NULL;
> unsigned int i;
> @@ -234,6 +239,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
>
> ctrl->dwMaxPayloadTransferSize = bandwidth;
> }
> +
> + /* Alcor Corp. Slave camera return wrong dwMaxPayloadTransferSize */
Let's add a bit more documentation:
/*
* Another issue is with devices that report a transfer size that
* greatly exceeds the maximum supported by any existing USB version.
* For instance, the "Slave camera" devices from Alcor Corp. (2017:0011
* and 1b17:66B8) request 2752512 bytes per interval.
*/
I would also take this as an opportunity to document the previous fixup,
just above the UVC_QUIRK_FIX_BANDWIDTH check, with
/*
* Many devices report an incorrect dwMaxPayloadTransferSize value. The
* most common issue is devices requesting the maximum possible USB
* bandwidth (3072 bytes per interval for high-speed, high-bandwidth
* isochronous endpoints) while they actually require less, preventing
* multiple cameras from being used at the same time due to bandwidth
* overallocation.
*
* For those devices, replace the dwMaxPayloadTransferSize value based
* on an estimation calculated from the frame format and size. This is
* only possible for uncompressed formats, as not enough information is
* available to reliably estimate the bandwidth requirements for
* compressed formats.
*/
> + if ((format->flags & UVC_FMT_FLAG_COMPRESSED) &&
> + (ctrl->dwMaxPayloadTransferSize > 0x1000) &&
Given that the highest bandwidth supported by high-speed, high bandwidth
devices is 3072 bytes per interval, I would check
(ctrl->dwMaxPayloadTransferSize > 3072) &&
here.
> + usb_match_id(stream->dev->intf, alcor_corp_slave_cam)) {
I'm also wondering if we could enable this fixup for all devices using
isochronous endpoints (as for bulk endpoints the transfer size can be
higher), without checking the VID:PID. No isochronous high-speed,
high-bandwidth device should have a swMaxPayloadTransferSize value
higher than 3072. For super-speed devices I'm not entirely sure if the
maximum transfer size covers multiple transfers in a burst. Ricardo, do
you know anything about that ?
I can send a v5 that does all this.
> + ctrl->dwMaxPayloadTransferSize = 1024;
> + }
> }
>
> static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
--
Regards,
Laurent Pinchart
