On Sat, Nov 26, 2011 at 11:56:25AM +0200, Sakari Ailus wrote:
> Hi Andrzej and others,
>
> On Fri, Nov 25, 2011 at 10:38:13AM +0100, Andrzej Pietrasiewicz wrote:
> ...
> > +static int s5p_jpeg_s_jpegcomp(struct file *file, void *priv,
> > + struct v4l2_jpegcompression *compr)
> > +{
> > + struct s5p_jpeg_ctx *ctx = priv;
> > +
> > + if (ctx->mode == S5P_JPEG_DECODE)
> > + return -ENOTTY;
> > +
> > + compr->quality = clamp(compr->quality, S5P_JPEG_COMPR_QUAL_BEST,
> > + S5P_JPEG_COMPR_QUAL_WORST);
> > +
> > + ctx->compr_quality = S5P_JPEG_COMPR_QUAL_WORST - compr->quality;
> > +
> > + return 0;
>
> The quality paramaeter of VIDIOC_S_JPEGCOMP is badly documented and its
> value range is unspecified. To make the matter worse, VIDIOC_S_JPEGCOMP is a
> write-only IOCTL, so the user won't be able to know the value the driver
> uses. This forces the user space to know the value range for quality. I
> think we have a good change to resolve the matter properly now.
>
> I can think of two alternatives, both of which are very simple.
>
> 1) Define the value range for v4l2_jpegcompression. The driver implements
> four, so they essentially would be 0, 33, 66 and 100, if 0--100 is chosen as
> the standard range. This is what I have seen is often used by jpeg
> compression programs.
>
> 2) Define a new control for jpeg quality. Its value range can be what the
> hardware supports and the user space gets much better information on the
> capabilities of the hardware and the granularity of the quality setting.
>
> I might even favour the second one. I also wonder how many user space
> applications use this IOCTL, so if we're breaking anything by not supporting
> it.
>
> Or we could decide to do option 1 right now and implement 2) later on. I can
> write a patch to change the documentation.
Hi,
I later on figured out one _can_ get this information using
VIDIOC_G_JPEGCOMP. It's not a very good interface, but works. What do you
think?
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
