From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from perceval.irobotique.be ([92.243.18.41]:57223 "EHLO perceval.irobotique.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754287Ab0C3I5h convert rfc822-to-8bit (ORCPT ); Tue, 30 Mar 2010 04:57:37 -0400 From: Laurent Pinchart To: Hans Verkuil Subject: Re: [PATCH/RFC 0/1] v4l: Add support for binary controls Date: Tue, 30 Mar 2010 10:57:54 +0200 Cc: Kamil Debski , linux-media@vger.kernel.org, p.osciak@samsung.com, kyungmin.park@samsung.com References: <1269856386-29557-1-git-send-email-k.debski@samsung.com> <201003300841.47978.hverkuil@xs4all.nl> In-Reply-To: <201003300841.47978.hverkuil@xs4all.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Message-Id: <201003301057.56034.laurent.pinchart@ideasonboard.com> Sender: linux-media-owner@vger.kernel.org List-ID: Hi Hans, On Tuesday 30 March 2010 08:41:47 Hans Verkuil wrote: > On Monday 29 March 2010 11:53:05 Kamil Debski wrote: > > Hello, > > > > This patch introduces new type of v4l2 control - the binary control. It > > will be useful for exchanging raw binary data between the user space and > > the driver/hardware. > > > > The patch is pretty small – basically it adds a new control type. > > > > 1. Reasons to include this new type > > - Some devices require data which are not part of the stream, but there > > are necessary for the device to work e.g. coefficients for transformation > > matrices. > > - String control is not suitable as it suggests that the data is a null > > terminated string. This might be important when printing debug > > information - one might output strings as they are and binary data in > > hex. > > > > 2. How does the binary control work > > The binary control has been based on the string control. The principle of > > use is the same. It uses v4l2_ext_control structure to pass the pointer > > and size of the data. It is left for the driver to call the > > copy_from_user/ copy_to_user function to copy the data. > > > > 3. About the patch > > The patch is pretty small – it basically adds a new control type. > > > > Best wishes, > > I don't think this is a good idea. Controls are not really meant to be used > as an ioctl replacement. > > Controls can be used to control the hardware via a GUI (e.g. qv4l2). > Obviously, this will fail for binary controls. Controls can also be used > in cases where it is not known up front which controls are needed. This > typically happens for bridge drivers that can use numerous combinations of > i2c sub-devices. Each subdev can have its own controls. > > There is a grey area where you want to give the application access to > low-level parameters but without showing them to the end-user. This is > currently not possible, but it will be once the control framework is > finished and once we have the possibility to create device nodes for > subdevs. > > But what you want is to basically pass whole structs as a control. That's > something that ioctls where invented for. Especially once we have subdev > nodes this shouldn't be a problem. > > Just the fact that it is easy to implement doesn't mean it should be done > :-) > > Do you have specific use-cases for your proposed binary control? As discussed yesterday, here are a few use cases for the OMAP3 ISP driver. - white balance matrix - gamma correction tables In both cases, the driver needs an array (possible 2 dimensional) of values to configure the hardware. This can obviously be done using private ioctls, but what makes the red&blue white balance gains different from the white balance matrix ? Why should the first be controls and the later not ? -- Regards, Laurent Pinchart