public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Michael Grzeschik <mgr@pengutronix.de>
Cc: Daniel Scally <dan.scally@ideasonboard.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Avichal Rakesh <arakesh@google.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 07/10] usb: gadget: uvc: add g_parm and s_parm for frame interval
Date: Tue, 13 Aug 2024 13:34:55 +0300	[thread overview]
Message-ID: <20240813103455.GC24634@pendragon.ideasonboard.com> (raw)
In-Reply-To: <Zrs1HhLLkun6_0jD@pengutronix.de>

On Tue, Aug 13, 2024 at 12:27:42PM +0200, Michael Grzeschik wrote:
> On Tue, Aug 13, 2024 at 12:28:20PM +0300, Laurent Pinchart wrote:
> >On Tue, Aug 13, 2024 at 12:22:55PM +0300, Laurent Pinchart wrote:
> >> On Tue, Aug 13, 2024 at 11:09:31AM +0200, Michael Grzeschik wrote:
> >> > The uvc gadget driver is lacking the information which frame interval
> >> > was set by the host. We add this information by implementing the g_parm
> >> > and s_parm callbacks.
> >>
> >> As I've said countless times, this kind of hack is not the right way to
> >> pass information that the kernel has no use for between two userspace
> >> components. Please stop butchering this driver.
> >
> > Reading further patches in the series I see that you would like to get
> > more precise bandwidth information from userspace. That is fine, but I
> > don't think s_parm is the right option. This is not a regular V4L2
> > driver, pass it the exat information it needs instead, through a
> > dedicated API that will provide all the needed data.
> 
> We have an API, where we can handover the framerate. Why invent
> something new. All we need to fix is also patch you uvc-gadget
> implementation.
> 
> What other API do you suggest then? Come up with something super new and
> special, only dedicated for UVC then?

Yes, and that's what should have been done instead of adding support for
the V4L2 format-related ioctls.

We can't change the past, but I'm tired and sad to see the driver
evolving in a direction I don't think is right. I however don't have
much time to maintain it these days, and it's obviously not fair to
block progress, even if I believe that good progress would have taken an
entirely different direction.

I will submit a patch to remove myself from MAINTAINERS for this driver.
Come what may.

> >> > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> >> > ---
> >> > v3 -> v4: -
> >> > v2 -> v3: -
> >> > v1 -> v2: -
> >> > ---
> >> >  drivers/usb/gadget/function/uvc.h      |  1 +
> >> >  drivers/usb/gadget/function/uvc_v4l2.c | 52 ++++++++++++++++++++++++++++++++++
> >> >  2 files changed, 53 insertions(+)
> >> >
> >> > diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
> >> > index b3a5165ac70ec..f6bc58fb02b84 100644
> >> > --- a/drivers/usb/gadget/function/uvc.h
> >> > +++ b/drivers/usb/gadget/function/uvc.h
> >> > @@ -100,6 +100,7 @@ struct uvc_video {
> >> >  	unsigned int width;
> >> >  	unsigned int height;
> >> >  	unsigned int imagesize;
> >> > +	unsigned int interval;
> >> >  	struct mutex mutex;	/* protects frame parameters */
> >> >
> >> >  	unsigned int uvc_num_requests;
> >> > diff --git a/drivers/usb/gadget/function/uvc_v4l2.c b/drivers/usb/gadget/function/uvc_v4l2.c
> >> > index de41519ce9aa0..392fb400aad14 100644
> >> > --- a/drivers/usb/gadget/function/uvc_v4l2.c
> >> > +++ b/drivers/usb/gadget/function/uvc_v4l2.c
> >> > @@ -307,6 +307,56 @@ uvc_v4l2_set_format(struct file *file, void *fh, struct v4l2_format *fmt)
> >> >  	return ret;
> >> >  }
> >> >
> >> > +static int uvc_v4l2_g_parm(struct file *file, void *fh,
> >> > +			    struct v4l2_streamparm *parm)
> >> > +{
> >> > +	struct video_device *vdev = video_devdata(file);
> >> > +	struct uvc_device *uvc = video_get_drvdata(vdev);
> >> > +	struct uvc_video *video = &uvc->video;
> >> > +	struct v4l2_fract timeperframe;
> >> > +
> >> > +	if (parm->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> >> > +		return -EINVAL;
> >> > +
> >> > +	/* Return the actual frame period. */
> >> > +	timeperframe.numerator = video->interval;
> >> > +	timeperframe.denominator = 10000000;
> >> > +	v4l2_simplify_fraction(&timeperframe.numerator,
> >> > +		&timeperframe.denominator, 8, 333);
> >> > +
> >> > +	uvcg_dbg(&uvc->func, "Getting frame interval of %u/%u (%u)\n",
> >> > +		timeperframe.numerator, timeperframe.denominator,
> >> > +		video->interval);
> >> > +
> >> > +	parm->parm.output.timeperframe = timeperframe;
> >> > +	parm->parm.output.capability = V4L2_CAP_TIMEPERFRAME;
> >> > +
> >> > +	return 0;
> >> > +}
> >> > +
> >> > +static int uvc_v4l2_s_parm(struct file *file, void *fh,
> >> > +			    struct v4l2_streamparm *parm)
> >> > +{
> >> > +	struct video_device *vdev = video_devdata(file);
> >> > +	struct uvc_device *uvc = video_get_drvdata(vdev);
> >> > +	struct uvc_video *video = &uvc->video;
> >> > +	struct v4l2_fract timeperframe;
> >> > +
> >> > +	if (parm->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> >> > +		return -EINVAL;
> >> > +
> >> > +	timeperframe = parm->parm.output.timeperframe;
> >> > +
> >> > +	video->interval = v4l2_fraction_to_interval(timeperframe.numerator,
> >> > +		timeperframe.denominator);
> >> > +
> >> > +	uvcg_dbg(&uvc->func, "Setting frame interval to %u/%u (%u)\n",
> >> > +		timeperframe.numerator, timeperframe.denominator,
> >> > +		video->interval);
> >> > +
> >> > +	return 0;
> >> > +}
> >> > +
> >> >  static int
> >> >  uvc_v4l2_enum_frameintervals(struct file *file, void *fh,
> >> >  		struct v4l2_frmivalenum *fival)
> >> > @@ -577,6 +627,8 @@ const struct v4l2_ioctl_ops uvc_v4l2_ioctl_ops = {
> >> >  	.vidioc_dqbuf = uvc_v4l2_dqbuf,
> >> >  	.vidioc_streamon = uvc_v4l2_streamon,
> >> >  	.vidioc_streamoff = uvc_v4l2_streamoff,
> >> > +	.vidioc_s_parm = uvc_v4l2_s_parm,
> >> > +	.vidioc_g_parm = uvc_v4l2_g_parm,
> >> >  	.vidioc_subscribe_event = uvc_v4l2_subscribe_event,
> >> >  	.vidioc_unsubscribe_event = uvc_v4l2_unsubscribe_event,
> >> >  	.vidioc_default = uvc_v4l2_ioctl_default,

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2024-08-13 10:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13  9:09 [PATCH v4 00/10] usb: gadget: uvc: effectively fill the udc isoc pipeline with available video buffers Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 01/10] usb: gadget: uvc: always set interrupt on zero length requests Michael Grzeschik
2024-08-13  9:17   ` Laurent Pinchart
2024-08-13  9:09 ` [PATCH v4 02/10] usb: gadget: uvc: only enqueue zero length requests in potential underrun Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 03/10] usb: gadget: uvc: remove pump worker and enqueue all buffers per frame in qbuf Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 04/10] usb: gadget: uvc: rework to enqueue in pump worker from encoded queue Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 05/10] usb: gadget: uvc: remove uvc_video_ep_queue_initial_requests Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 06/10] usb: gadget: uvc: set req_size once when the vb2 queue is calculated Michael Grzeschik
2024-08-13  9:41   ` Laurent Pinchart
2024-08-27 21:58     ` Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 07/10] usb: gadget: uvc: add g_parm and s_parm for frame interval Michael Grzeschik
2024-08-13  9:22   ` Laurent Pinchart
2024-08-13  9:28     ` Laurent Pinchart
2024-08-13 10:27       ` Michael Grzeschik
2024-08-13 10:34         ` Laurent Pinchart [this message]
2024-08-13  9:09 ` [PATCH v4 08/10] usb: gadget: uvc: set req_size and n_requests based on the " Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 09/10] usb: gadget: uvc: set req_length based on payload by nreqs instead of req_size Michael Grzeschik
2024-08-13  9:09 ` [PATCH v4 10/10] usb: gadget: uvc: add min g_ctrl vidioc and set min buffs to 4 Michael Grzeschik
2024-08-13  9:35   ` Laurent Pinchart
2024-08-13  9:56 ` [PATCH v4 00/10] usb: gadget: uvc: effectively fill the udc isoc pipeline with available video buffers Greg Kroah-Hartman
2024-08-13 10:01   ` Greg Kroah-Hartman

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=20240813103455.GC24634@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=arakesh@google.com \
    --cc=dan.scally@ideasonboard.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mgr@pengutronix.de \
    /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