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
next prev parent 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).