linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Ricardo Ribalda <ribalda@chromium.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	regressions@lists.linux.dev, Hans de Goede <hdegoede@redhat.com>,
	"Linux regression tracking (Thorsten Leemhuis)" 
	<regressions@leemhuis.info>
Subject: Re: [PATCH] media: usb: uvc: fill in description for unknown pixelformats
Date: Wed, 5 Apr 2023 09:40:20 +0300	[thread overview]
Message-ID: <20230405064020.GZ9915@pendragon.ideasonboard.com> (raw)
In-Reply-To: <7bcc8593-a98d-6faa-2ec5-3cf59137cbcb@xs4all.nl>

Hello,

On Wed, Mar 29, 2023 at 07:20:59PM +0200, Hans Verkuil wrote:
> On 29/03/2023 18:05, Ricardo Ribalda wrote:
> > Hi Hans
> > 
> > Thanks for the patch.
> > 
> > I believe the user can fetch this info from lsusb, so this is kind of
> > duplicated info, and this is why it was removed.
> 
> You got to set some description, so using the GUID this seems best.
> 
> > Is there an app that uses this unknown format code ? Or the only
> > complaint is that WARN() is too loud for the user?
> 
> Normally drivers do not pass on unknown formats, but if a driver does,
> then I want a WARN. If a driver does this legitimately (and I understand
> that's the case for UVC), then the driver should fill in the description
> to avoid this WARN.

In hindsight we shouldn't have added a text description to formats :-)

> > On Wed, 29 Mar 2023 at 14:39, Hans Verkuil wrote:
> >>
> >> If the fcc is 0 (indicating an unknown GUID format), then fill in the
> >> description field in ENUM_FMT. Otherwise the V4L2 core will WARN.
> >>
> >> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> >> Fixes: 50459f103edf ("media: uvcvideo: Remove format descriptions")
> >> ---
> >> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> >> index 7aefa76a42b3..2f1ced1212cd 100644
> >> --- a/drivers/media/usb/uvc/uvc_driver.c
> >> +++ b/drivers/media/usb/uvc/uvc_driver.c
> >> @@ -256,6 +256,9 @@ static int uvc_parse_format(struct uvc_device *dev,
> >>                 } else {
> >>                         dev_info(&streaming->intf->dev,
> >>                                  "Unknown video format %pUl\n", &buffer[5]);
> >> +                       snprintf(format->name, sizeof(format->name), "%pUl\n",
> >> +                                &buffer[5]);
> > Don't we need at least 38 chars for this?
> 
> Yes. But all we have is 31 chars, so we take what we can :-)
> 
> This is what uvc did before this was removed.
> 
> Regards,
> 
> 	Hans
> 
> > https://docs.kernel.org/core-api/printk-formats.html#uuid-guid-addresses
> > 
> >> +
> >>                         format->fcc = 0;
> >>                 }
> >>
> >> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> >> index 35453f81c1d9..fc6f9e7d8506 100644
> >> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> >> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> >> @@ -713,6 +713,10 @@ static int uvc_ioctl_enum_fmt(struct uvc_streaming *stream,
> >>         if (format->flags & UVC_FMT_FLAG_COMPRESSED)
> >>                 fmt->flags |= V4L2_FMT_FLAG_COMPRESSED;
> >>         fmt->pixelformat = format->fcc;
> >> +       if (format->name[0])
> >> +               strscpy(fmt->description, format->name,
> >> +                       sizeof(fmt->description));
> >> +
> >>         return 0;
> >>  }
> >>
> >> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> >> index 9a596c8d894a..22656755a801 100644
> >> --- a/drivers/media/usb/uvc/uvcvideo.h
> >> +++ b/drivers/media/usb/uvc/uvcvideo.h
> >> @@ -264,6 +264,8 @@ struct uvc_format {
> >>         u32 fcc;
> >>         u32 flags;
> >>
> >> +       char name[32];
> >> +

I'd not really nice to have to store the name for every format, when we
know it will very rarely be used.

One alternative option would be to store the GUID, which would halve the
amount of memory. Another option would be to stop reporting those
formats to userspace in uvc_ioctl_enum_fmt(). They can't be selected
anyway, they have no unique 4CC.

> >>         unsigned int nframes;
> >>         struct uvc_frame *frame;
> >>  };

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-04-05  6:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 12:28 [PATCH] media: usb: uvc: fill in description for unknown pixelformats Hans Verkuil
2023-03-29 16:05 ` Ricardo Ribalda
2023-03-29 17:20   ` Hans Verkuil
2023-04-05  6:40     ` Laurent Pinchart [this message]
2023-04-19  6:23       ` Laurent Pinchart
2023-04-19  6:48         ` Hans Verkuil
2023-03-29 18:36 ` Hans de Goede
2023-04-11 11:49 ` Thorsten Leemhuis
2023-04-11 12:06   ` Laurent Pinchart
2023-04-11 12:26     ` Linux regression tracking (Thorsten Leemhuis)
2023-04-11 12:17   ` Ricardo Ribalda
2023-05-31 11:48 ` Linux regression tracking (Thorsten Leemhuis)
2023-05-31 12:44   ` Laurent Pinchart
2023-05-31 12:54     ` Linux regression tracking (Thorsten Leemhuis)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230405064020.GZ9915@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=ribalda@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).