drivers/media/usb/uvc/uvc_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
This message is much longer than others and doesn't fit even in a 160
column window when printed, despite providing little real information.
Also replace 'transmission' with 'transfer' because that's the actual
name and 'max packet' with 'limit' because it isn't same thing with
isochronus endpoints. Remove cryptic abbreviations like 'ep'.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---
By the way, this hack doesn't help much in the opposite case:
dwMaxPayloadTransferSize is right, but EP descriptors are a mess.
But no harm in trying, I guess.
I can live with it either way.
drivers/media/usb/uvc/uvc_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 82d9d8ae059d..baf4ace41dbe 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -266,7 +266,7 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
if (stream->intf->num_altsetting > 1 &&
ctrl->dwMaxPayloadTransferSize > stream->maxpsize) {
dev_warn_ratelimited(&stream->intf->dev,
- "UVC non compliance: the max payload transmission size (%u) exceeds the size of the ep max packet (%u). Using the max size.\n",
+ "UVC non compliance: Reducing max payload transfer size (%u) to fit endpoint limit (%u).\n",
ctrl->dwMaxPayloadTransferSize,
stream->maxpsize);
ctrl->dwMaxPayloadTransferSize = stream->maxpsize;
--
2.48.1
On Thu, Sep 04, 2025 at 08:14:29AM +0200, Michal Pecio wrote: > This message is much longer than others and doesn't fit even in a 160 > column window when printed, despite providing little real information. > > Also replace 'transmission' with 'transfer' because that's the actual > name and 'max packet' with 'limit' because it isn't same thing with > isochronus endpoints. Remove cryptic abbreviations like 'ep'. > > Signed-off-by: Michal Pecio <michal.pecio@gmail.com> > --- > > By the way, this hack doesn't help much in the opposite case: > dwMaxPayloadTransferSize is right, but EP descriptors are a mess. Have you encountered such devices ? > But no harm in trying, I guess. > I can live with it either way. > > drivers/media/usb/uvc/uvc_video.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index 82d9d8ae059d..baf4ace41dbe 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -266,7 +266,7 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, > if (stream->intf->num_altsetting > 1 && > ctrl->dwMaxPayloadTransferSize > stream->maxpsize) { > dev_warn_ratelimited(&stream->intf->dev, > - "UVC non compliance: the max payload transmission size (%u) exceeds the size of the ep max packet (%u). Using the max size.\n", > + "UVC non compliance: Reducing max payload transfer size (%u) to fit endpoint limit (%u).\n", > ctrl->dwMaxPayloadTransferSize, > stream->maxpsize); > ctrl->dwMaxPayloadTransferSize = stream->maxpsize; -- Regards, Laurent Pinchart
On Mon, 8 Sep 2025 10:36:55 +0200, Laurent Pinchart wrote: > On Thu, Sep 04, 2025 at 08:14:29AM +0200, Michal Pecio wrote: > > This message is much longer than others and doesn't fit even in a 160 > > column window when printed, despite providing little real information. > > > > Also replace 'transmission' with 'transfer' because that's the actual > > name and 'max packet' with 'limit' because it isn't same thing with > > isochronus endpoints. Remove cryptic abbreviations like 'ep'. > > > > Signed-off-by: Michal Pecio <michal.pecio@gmail.com> > > --- > > > > By the way, this hack doesn't help much in the opposite case: > > dwMaxPayloadTransferSize is right, but EP descriptors are a mess. > > Have you encountered such devices ? Yes, it sometimes reports bad 'mult' in EP descriptors, which leaves them with insufficient BW for some video modes. Can be fixed with the usual "turn it off, turn it on again". I frankly haven't bothered trying what would happen if I override mult in USB core and I think it would be crazy to send that upstream anyway. Before that patch, it would simply fail with "no fast enough alt setting" and -EIO or some such seen by userspace. Now it produces truncated frames. But also nothing worse than that, so it's fine. Regards, Michal
Hi Michal I like the new writing :) On Thu, 4 Sept 2025 at 08:14, Michal Pecio <michal.pecio@gmail.com> wrote: > > This message is much longer than others and doesn't fit even in a 160 > column window when printed, despite providing little real information. > > Also replace 'transmission' with 'transfer' because that's the actual > name and 'max packet' with 'limit' because it isn't same thing with > isochronus endpoints. Remove cryptic abbreviations like 'ep'. > Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> > Signed-off-by: Michal Pecio <michal.pecio@gmail.com> > --- > > By the way, this hack doesn't help much in the opposite case: > dwMaxPayloadTransferSize is right, but EP descriptors are a mess. > > But no harm in trying, I guess. > I can live with it either way. > > > drivers/media/usb/uvc/uvc_video.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index 82d9d8ae059d..baf4ace41dbe 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -266,7 +266,7 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, > if (stream->intf->num_altsetting > 1 && > ctrl->dwMaxPayloadTransferSize > stream->maxpsize) { > dev_warn_ratelimited(&stream->intf->dev, > - "UVC non compliance: the max payload transmission size (%u) exceeds the size of the ep max packet (%u). Using the max size.\n", > + "UVC non compliance: Reducing max payload transfer size (%u) to fit endpoint limit (%u).\n", > ctrl->dwMaxPayloadTransferSize, > stream->maxpsize); > ctrl->dwMaxPayloadTransferSize = stream->maxpsize; > -- > 2.48.1 > -- Ricardo Ribalda
On Thu, 4 Sep 2025 09:20:31 +0200, Ricardo Ribalda wrote: > Hi Michal > > I like the new writing :) > > On Thu, 4 Sept 2025 at 08:14, Michal Pecio <michal.pecio@gmail.com> wrote: > > > > This message is much longer than others and doesn't fit even in a 160 > > column window when printed, despite providing little real information. > > > > Also replace 'transmission' with 'transfer' because that's the actual > > name and 'max packet' with 'limit' because it isn't same thing with > > isochronus endpoints. Remove cryptic abbreviations like 'ep'. > > > Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Thank you. On second thought, I'm not sure if those brackets look good here: [ 2410.688715] uvcvideo 11-1:1.1: UVC non compliance: Reducing max payload transfer size (32764) to fit endpoint limit (20480). but I sent the patch already. If you think it would be better without them, please feel free to tweak the patch or ask for v2. If not, meh. Regards, Michal
On Thu, Sep 04, 2025 at 10:24:05AM +0200, Michal Pecio wrote: > On Thu, 4 Sep 2025 09:20:31 +0200, Ricardo Ribalda wrote: > > Hi Michal > > > > I like the new writing :) > > > > On Thu, 4 Sept 2025 at 08:14, Michal Pecio <michal.pecio@gmail.com> wrote: > > > > > > This message is much longer than others and doesn't fit even in a 160 > > > column window when printed, despite providing little real information. > > > > > > Also replace 'transmission' with 'transfer' because that's the actual > > > name and 'max packet' with 'limit' because it isn't same thing with > > > isochronus endpoints. Remove cryptic abbreviations like 'ep'. > > > > > Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> > > Thank you. > > On second thought, I'm not sure if those brackets look good here: > > [ 2410.688715] uvcvideo 11-1:1.1: UVC non compliance: Reducing max payload transfer size (32764) to fit endpoint limit (20480). > > but I sent the patch already. If you think it would be better without > them, please feel free to tweak the patch or ask for v2. If not, meh. I like th enew message. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> -- Regards, Laurent Pinchart
© 2016 - 2025 Red Hat, Inc.