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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
