From patchwork Sun Feb 2 13:04:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Philipp Zabel X-Patchwork-Id: 3566841 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1A280C02DC for ; Sun, 2 Feb 2014 13:05:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0DC6820200 for ; Sun, 2 Feb 2014 13:05:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DA41B201FE for ; Sun, 2 Feb 2014 13:05:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751317AbaBBNEh (ORCPT ); Sun, 2 Feb 2014 08:04:37 -0500 Received: from metis.ext.pengutronix.de ([92.198.50.35]:53967 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbaBBNEg (ORCPT ); Sun, 2 Feb 2014 08:04:36 -0500 Received: from dude.hi.pengutronix.de ([2001:6f8:1178:2:21e:67ff:fe11:9c5c]) by metis.ext.pengutronix.de with esmtp (Exim 4.72) (envelope-from ) id 1W9wiv-0001Ti-Ea; Sun, 02 Feb 2014 14:04:33 +0100 Received: from pza by dude.hi.pengutronix.de with local (Exim 4.82) (envelope-from ) id 1W9wis-0004Uh-Fq; Sun, 02 Feb 2014 14:04:30 +0100 Date: Sun, 2 Feb 2014 14:04:30 +0100 From: Philipp Zabel To: Laurent Pinchart Cc: Hans Verkuil , Philipp Zabel , linux-media@vger.kernel.org, Mauro Carvalho Chehab , kernel@pengutronix.de Subject: Re: [PATCH] [media] uvcvideo: Enable VIDIOC_CREATE_BUFS Message-ID: <20140202130430.GA15734@pengutronix.de> References: <1391012032-19600-1-git-send-email-p.zabel@pengutronix.de> <1474634.xnVfC2yuQa@avalon> <52EB6214.9030806@xs4all.nl> <3803281.g9jSrV8SES@avalon> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3803281.g9jSrV8SES@avalon> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 14:00:50 up 12 days, 1:29, 20 users, load average: 0,32, 0,35, 0,29 User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:6f8:1178:2:21e:67ff:fe11:9c5c X-SA-Exim-Mail-From: pza@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-media@vger.kernel.org Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Sun, Feb 02, 2014 at 11:21:13AM +0100, Laurent Pinchart wrote: > Hi Hans, > > On Friday 31 January 2014 09:43:00 Hans Verkuil wrote: > > I think you might want to add a check in uvc_queue_setup to verify the > > fmt that create_bufs passes. The spec says that: "Unsupported formats > > will result in an error". In this case I guess that the format basically > > should match the current selected format. > > > > I'm unhappy with the current implementations of create_bufs (see also this > > patch: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg70796.html). > > > > Nobody is actually checking the format today, which isn't good. > > > > The fact that the spec says that the fmt field isn't changed by the driver > > isn't helping as it invalidated my patch from above, although that can be > > fixed. > > > > I need to think about this some more, but for this particular case you can > > just do a memcmp of the v4l2_pix_format against the currently selected > > format and return an error if they differ. Unless you want to support > > different buffer sizes as well? > > Isn't the whole point of VIDIOC_CREATE_BUFS being able to create buffers of > different resolutions than the current active resolution ? For that to work the driver in question would need to keep track of per-buffer format and resolution, and not only of per-queue format and resolution. For now, would something like the following be enough? Unfortunately the uvc driver doesn't keep a v4l2_format around that we could just memcmp against: regards Philipp --- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index fa58131..7fa469b 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -1003,10 +1003,26 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg) case VIDIOC_CREATE_BUFS: { struct v4l2_create_buffers *cb = arg; + struct v4l2_pix_format *pix; + struct uvc_format *format; + struct uvc_frame *frame; if (!uvc_has_privileges(handle)) return -EBUSY; + format = stream->cur_format; + frame = stream->cur_frame; + pix = &cb->format.fmt.pix; + + if (pix->pixelformat != format->fcc || + pix->width != frame->wWidth || + pix->height != frame->wHeight || + pix->field != V4L2_FIELD_NONE || + pix->bytesperline != format->bpp * frame->wWidth / 8 || + pix->sizeimage != stream->ctrl.dwMaxVideoFrameSize || + pix->colorspace != format->colorspace) + return -EINVAL; + return uvc_create_buffers(&stream->queue, cb); }