From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 1/1] smiapp: Add driver-specific control class, test pattern controls
Date: Wed, 28 May 2014 14:27:44 +0200 [thread overview]
Message-ID: <2473281.SF9iootaVQ@avalon> (raw)
In-Reply-To: <5385D5B3.7040004@linux.intel.com>
On Wednesday 28 May 2014 15:25:23 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Wednesday 28 May 2014 15:16:58 Sakari Ailus wrote:
> >> Laurent Pinchart wrote:
> >>> On Wednesday 28 May 2014 12:00:38 Sakari Ailus wrote:
> >>>> Add smiapp driver specific control sub-class for test pattern controls.
> >>>> More controls are expected since a fair amount of the standard
> >>>> functionality is still unsupported. There are sensor model specific
> >>>> functionality as well and expectedly thus also sensor specific
> >>>> controls. So reserve 128 controls for this driver.
> >>>>
> >>>> This patch also adds test pattern controls for the four colour
> >>>> components.
> >>>>
> >>>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >>>> ---
> >>>> This patch comes before the previous patch I sent to the thread. I
> >>>> missed this when sending it.
> >>>>
> >>>> include/uapi/linux/smiapp.h | 34 +++++++++++++++++++++++++++++
> >>>> include/uapi/linux/v4l2-controls.h | 4 ++++
> >>>> 2 files changed, 38 insertions(+)
> >>>> create mode 100644 include/uapi/linux/smiapp.h
> >>>>
> >>>> diff --git a/include/uapi/linux/smiapp.h b/include/uapi/linux/smiapp.h
> >>>> new file mode 100644
> >>>> index 0000000..116fc69
> >>>> --- /dev/null
> >>>> +++ b/include/uapi/linux/smiapp.h
> >>>> @@ -0,0 +1,34 @@
> >>>> +/*
> >>>> + * include/media/smiapp.h
> >>>> + *
> >>>> + * Generic driver for SMIA/SMIA++ compliant camera modules
> >>>> + *
> >>>> + * Copyright (C) 2014 Intel Corporation
> >>>> + * Contact: Sakari Ailus <sakari.ailus@iki.fi>
> >>>> + *
> >>>> + * This program is free software; you can redistribute it and/or
> >>>> + * modify it under the terms of the GNU General Public License
> >>>> + * version 2 as published by the Free Software Foundation.
> >>>> + *
> >>>> + * This program is distributed in the hope that it will be useful, but
> >>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> >>>> + * General Public License for more details.
> >>>> + *
> >>>> + */
> >>>> +
> >>>> +#ifndef __UAPI_LINUX_SMIAPP_H_
> >>>> +#define __UAPI_LINUX_SMIAPP_H_
> >>>> +
> >>>> +#define V4L2_SMIAPP_TEST_PATTERN_MODE_DISABLED 0
> >>>> +#define V4L2_SMIAPP_TEST_PATTERN_MODE_SOLID_COLOUR 1
> >>>> +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS 2
> >>>> +#define V4L2_SMIAPP_TEST_PATTERN_MODE_COLOUR_BARS_GREY 3
> >>>> +#define V4L2_SMIAPP_TEST_PATTERN_MODE_PN9 4
> >>>> +
> >>>> +#define V4L2_CID_SMIAPP_TEST_PATTERN_RED
> >>>> (V4L2_CID_USER_SMIAPP_BASE | 0x01)
> >>>> +#define V4L2_CID_SMIAPP_TEST_PATTERN_GREENR
> >>>> (V4L2_CID_USER_SMIAPP_BASE | 0x02)
> >>>> +#define V4L2_CID_SMIAPP_TEST_PATTERN_BLUE
> >>>> (V4L2_CID_USER_SMIAPP_BASE | 0x03)
> >>>> +#define V4L2_CID_SMIAPP_TEST_PATTERN_GREENB
> >>>> (V4L2_CID_USER_SMIAPP_BASE | 0x04)
> >>>
> >>> Wouldn't it make sense to create a standard test pattern color control
> >>> instead ? Several sensors can control the test pattern color in a way or
> >>> another. Some of them might need more than one color though, so I'm not
> >>> sure how much standardization would be possible.
> >>
> >> Now that you mention it, I'd guess many raw bayer sensors can set
> >> colours for the test pattern (or image). The menu control has no
> >> standardised values so I didn't think of standardising controls that
> >> depend on it.
> >>
> >> I'll update the patches (and add a new one for the standard controls).
> >
> > The color format might differ between devices though, some might not be
> > able to differentiate between Gr and Gb for the test pattern. A standard
> > test pattern color control should thus be flexible in the color format I
> > suppose.
>
> I think we should simply create a separate control for each component.
> There aren't that many components after all.
Given that components can be more than 8 bits wide that's probably a good
idea.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-05-28 12:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 12:43 [PATCH 1/1] smiapp: Implement the test pattern control Sakari Ailus
2014-05-28 9:00 ` [PATCH 1/1] smiapp: Add driver-specific control class, test pattern controls Sakari Ailus
2014-05-28 9:09 ` Hans Verkuil
2014-05-28 10:49 ` Laurent Pinchart
2014-05-28 12:16 ` Sakari Ailus
2014-05-28 12:20 ` Laurent Pinchart
2014-05-28 12:25 ` Sakari Ailus
2014-05-28 12:27 ` Laurent Pinchart [this message]
2014-05-28 9:08 ` [PATCH 1/1] smiapp: Implement the test pattern control Hans Verkuil
2014-05-28 10:06 ` [PATCH v2 2/2] " Sakari Ailus
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=2473281.SF9iootaVQ@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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