regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	regressions@lists.linux.dev,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	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, 29 Mar 2023 19:20:59 +0200	[thread overview]
Message-ID: <7bcc8593-a98d-6faa-2ec5-3cf59137cbcb@xs4all.nl> (raw)
In-Reply-To: <CANiDSCuiHLw6FBu8GV93Mm2WK5suCnGk8PBUDfn_krtMfPwdaw@mail.gmail.com>

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.

> 
> Regards!
> 
> On Wed, 29 Mar 2023 at 14:39, Hans Verkuil <hverkuil@xs4all.nl> 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];
>> +
>>         unsigned int nframes;
>>         struct uvc_frame *frame;
>>  };
>>
> 
> 
> --
> Ricardo Ribalda


  reply	other threads:[~2023-03-29 17:21 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 [this message]
2023-04-05  6:40     ` Laurent Pinchart
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=7bcc8593-a98d-6faa-2ec5-3cf59137cbcb@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=hdegoede@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --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).