Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
On 2011년 12월 30일 19:30, Sylwester Nawrocki wrote:
Hi HeungJun,
On 12/29/2011 06:08 AM, HeungJun, Kim wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, December 28, 2011 10:52 PM
To: Sylwester Nawrocki
Cc: HeungJun, Kim; linux-media@vger.kernel.org; mche...@redhat.com;
hverk...@xs4all.nl; sakari.ai...@iki.fi; kyungmin.p...@samsung.com; Hans de
Goede
Subject: Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu
control
Hi,
On Wednesday 28 December 2011 14:35:00 Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is
provided as menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently and
noticed they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
"Indoor (Incandescant Lighting) Mode",
"Outdoor (Sunlight) Mode",
"Indoor (Fluorescent Lighting) Mode",
"Manual Mode",
"Auto Mode",
NULL
};
static const struct v4l2_ctrl_config pwc_auto_white_balance_cfg = {
.ops=&pwc_ctrl_ops,
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type = V4L2_CTRL_TYPE_MENU,
.max= awb_auto,
.qmenu = pwc_auto_whitebal_qmenu,
};
...
cfg = pwc_auto_white_balance_cfg;
cfg.name = v4l2_ctrl_get_name(cfg.id);
cfg.def = def;
pdev->auto_white_balance = v4l2_ctrl_new_custom(hdl,&cfg, NULL);
So this driver re-defines V4L2_CID_AUTO_WHITE_BALANCE as a menu control
with custom entries. That's interesting... However it works in practice
and applications have access to what's provided by hardware.
Perhaps V4L2_CID_AUTO_WHITE_BALANCE_TEMPERATURE would be a better fit for
that :)
Nevertheless, redefining standard controls in particular drivers sounds
a little dubious. I wonder if this is a generally agreed approach ?
No agreed with me at least :-)
I guess the WBP menu controls of pwc driver is probably defined in the other
headers, for users being well known the PWC hardware. So it should be managed
separately to videodev2.h. Is it right? Even if the way might be slightly
different, it can't avoid to be "managed separately".
It means the users being not well known the specific hardware like PWC,
have difficulty to use that driver well.
And, at least, It doesn't looks generic API for me.
In this case, the unfamiliar user with such unique hardware, can use
whatever he wants to use finally, after finding& looking around the headers.
Applications can query drivers for supported controls and populate user control
panels dynamically, based on information from VIDIOC_QUERYCTRL and
VIDIOC_QUERYMENU
ioctls. Not needing to rely on menu items definition in videodev2.h.
I had a feeling you weren't considering such case. :)
You're right in that meaning. And it might be a good point.
But, I think these 2 ioctl can not handle about this issue.
Before using VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU, the user should know
which CID name
is used in the videodev2.h, and anyway it can not be avoidable the user
find out this name in it. :)
At least I've seen nobody makes the application just to open(),
queryctrl(), querymenu(), and close(),
only for scanning the specific control is existed or not.
Until now, I have known these 2 ioctl is generally used for formating
the UI componets like button,
menu, and etc, on the screen.
So, it's safe to say that the user who knows that specific control is
also know the CID name,
the user knows such specific controls don't need even VIDIOC_QUERYCTRL
and VIDIOC_QUERYMENU.
And IMHO, this is not related about pulling out the hidden(?) controls
generally used in the camera,
on the videodev2.h. I think it's only generic defined in videodev2.h.
I really had wondered why the controls I thought very general for camera
is in hidden(?) the specific driver,
not in the videodev2.h. It was just start to consider this issues.
Regards,
Heungjun Kim
Perhaps it's uncommon in embedded systems though.
--
Regards,
Sylwester
--
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
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi,
On 2011년 12월 30일 08:58, Laurent Pinchart wrote:
Hi,
On Thursday 29 December 2011 06:08:07 HeungJun, Kim wrote:
On Wednesday, December 28, 2011 10:52 PM Laurent Pinchart wrote:
On Wednesday 28 December 2011 14:35:00 Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is
provided as menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently and
noticed they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
"Indoor (Incandescant Lighting) Mode",
"Outdoor (Sunlight) Mode",
"Indoor (Fluorescent Lighting) Mode",
"Manual Mode",
"Auto Mode",
NULL
};
static const struct v4l2_ctrl_config pwc_auto_white_balance_cfg = {
.ops=&pwc_ctrl_ops,
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type = V4L2_CTRL_TYPE_MENU,
.max= awb_auto,
.qmenu = pwc_auto_whitebal_qmenu,
};
...
cfg = pwc_auto_white_balance_cfg;
cfg.name = v4l2_ctrl_get_name(cfg.id);
cfg.def = def;
pdev->auto_white_balance = v4l2_ctrl_new_custom(hdl,&cfg, NULL);
So this driver re-defines V4L2_CID_AUTO_WHITE_BALANCE as a menu control
with custom entries. That's interesting... However it works in practice
and applications have access to what's provided by hardware.
Perhaps V4L2_CID_AUTO_WHITE_BALANCE_TEMPERATURE would be a better fit
for that :)
Nevertheless, redefining standard controls in particular drivers sounds
a little dubious. I wonder if this is a generally agreed approach ?
No agreed with me at least :-)
I guess the WBP menu controls of pwc driver is probably defined in the
other headers, for users being well known the PWC hardware. So it should
be managed separately to videodev2.h. Is it right? Even if the way might
be slightly different, it can't avoid to be "managed separately".
It means the users being not well known the specific hardware like PWC,
have difficulty to use that driver well.
And, at least, It doesn't looks generic API for me.
In this case, the unfamiliar user with such unique hardware, can use
whatever he wants to use finally, after finding& looking around the
headers.
I think Sylwester was just pointing the pwc driver out as implementing a
custom white balance preset control to make sure we're aware of it, not to
advocate such an approach. We need to make sure that the generic white balance
preset control can handle the pwc driver's needs.
Ok, I understand what I miss on your point.
On the other hand, if the definition is defined in the videodev2.h, or at
least the videodev2.h also include separated API's headers(I'm not sure
this way, but my real meaning is needed to be consolidated only one way to
control hardware, like videodev2.h), it looks more be better.
As such meaning, I agreed to Sylwester's word "dubious".
But, here's the thing.
If the any control suggested does not look general function on camera,
and it is used "only at the specific hardware", we should avoid this.
As you know, the White Balance Preset is very general camera's feature,
and the term's name is also very normal to the digital camera users.
Almost digital camera have this function.
Probably, Laurent might be concern about such "generality". Am I right?
I agree that a generic white balance preset control is needed. I think the
documentation should be improved though, to clearly define how the control
works.
So, your point is the documentation which is described how these
controls interact previous controls,
e.g, like WHITE_BALANCE_PRESET as I suggested and previous remained
DO/TEMPRATURE, etc.
Then, how does your V4L2_CID_PRESET_WHITE_BALANCE control interact with
V4L2_CID_AUTO_WHITE_BALANCE control ? Does V4L2_CID_AUTO_WHITE_BALANCE
need to be set to false for V4L2_CID_PRESET_WHITE_BALANCE to be
effective ?
Is the preset a fixed white balance setting, or is it an auto white
balance with the algorithm tuned for a particular configuration ? In the
first case, does it correspond to a fixed white balance temperature
value ?
[snip]
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml index c0422c6..350c138
100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2841,6 +2841,44 @@ it one step further. This is a write-only
control.
+
+ V4L2_CID_PRESET_WHITE_BALANCE
;
Wouldn't V4L2_CID_WHITE_BALANCE_PRESET be better ?
That's what I was about to say.
I saw the controls related with White Balance and most cid's name
is V4L2_CID__WHITE_BALANCE. So, I just used that n
Re: [RFCv2 PATCH 08/11] v4l2-ctrls: simplify event subscription.
2011-06-06 오후 7:05, Sakari Ailus 쓴 글:
> On Sat, Jun 04, 2011 at 12:28:04PM +0200, Hans Verkuil wrote:
>> On Friday, June 03, 2011 21:55:10 Laurent Pinchart wrote:
> [clip]
+{
+ int ret = 0;
+
+ if (!fh->events)
+ ret = v4l2_event_init(fh);
+ if (!ret)
+ ret = v4l2_event_alloc(fh, n);
+ if (!ret)
+ ret = v4l2_event_subscribe(fh, sub);
>>>
>>> I tend to return errors when they occur instead of continuing to the end of
>>> the function. Handling errors on the spot makes code easier to read in my
>>> opinion, as I expect the main code flow to be the error-free path.
>>
>> Hmmm, I rather like the way the code looks in this particular case. But it;s
>> no big deal and I can change it.
>
> The M5MOLS driver uses this pattern extensively in I2C access error
> handling. I agree with Laurent in principle, but on the other hand I think
> using this pattern makes sense. The error handling takes much less code and
> the test for continuing always is "if (!ret)" it is relatively readable as
> well.
>
> I'm fine with either resolution.
Actually, this pattern was advice from Hans for the M-5MOLS reviews at past,
and it's very helpful and I satisfied mostly.
Also, I was testing or using both this usage and the other one for a while,
and as a result, I figured out which is good choice between continueing to the
end
of the function and return imediately, depends on various situation.
Consequently, IMHO, both usgaes are fine, but if the checking factor like
(!ret),
changes the other one like (!flag) not ret, then it looks better to return
immediately, or the other handling methods, not using continueing to check error
at the end.
Regards,
Heungjun Kim
--
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
Re: [PATCH v2 3/4] m5mols: remove union in the m5mols_get_version(), and VERSION_SIZE
2011. 6. 5., 오후 9:11, Sakari Ailus 작성: > On Sun, Jun 05, 2011 at 03:03:47PM +0300, Sakari Ailus wrote: > [clip] >>> - /* store version information swapped for being readable */ >>> - info->ver = version.ver; >>> info->ver.fw= be16_to_cpu(info->ver.fw); >>> info->ver.hw= be16_to_cpu(info->ver.hw); >>> info->ver.param = be16_to_cpu(info->ver.param); >> >> As you have a local variable ver pointing to info->ver, you should also use >> it here. > > With this change, Ok, I missed that. I'll fix this and resend another version. Thanks! > > Acked-by: Sakari Ailus > > -- > Sakari Ailus > sakari dot ailus at iki dot fi > -- > 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 -- 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
Re: [PATCH v9] Add support for M-5MOLS 8 Mega Pixel camera ISP
Hi Sakari,
2011. 6. 5., 오후 8:55, Sakari Ailus 작성:
> On Thu, May 26, 2011 at 04:12:47PM +0900, Kim, HeungJun wrote:
>> Hi Sakari,
>
> Hi HeungJun,
>
>> 2011-05-25 ?? 10:54, Sakari Ailus ??? ???:
>>> Hi HeungJun,
>>>
>>> Thanks for the patch!
>> Also, thanks for the interests of this driver!
[snip]
>>
>>> shouldn't the underlying low level controls be exposed to user space as
>>> such?
>>>
>>> There definitely are different approaches to this; providing higher level
>>> interface is restricting but on the other hand it may be better depending on
>>> an application.
>>>
>>> Some of these parameters would already have a V4L2 control for them.
>> Actually, I have a plan to prepare RFC to expose some controls and
>> things related with control timing. :)
>
> I'm looking forward to this. Control timing is also something I'm interested
> in.
Yeah, we're still thinking of this, but it's true we still don't have clean
solution about that
in the linux side. Especially, the timing of camera(the more Higher-performance
sensor
the more tricky to control timing) is sensitive, but anyway it's also true the
camera device
not using linux is available to handle well now.
My point of thinking is that going in/out the kernel-space/user-space occurs
the latency,
and this latency occurs imbalance of image. For example, before the capturing,
the flash
or adequate exposure value should be maintained constantly, but if any other
process
interrupts between flash-ctrl and exposure-ctrl or something occurs the delay,
we can
not get the prefect image configured by our purpose.
But, I'm still considering how to handle this now.
If my thought will somewhat concrete, it's taking not much longer, and I'll
soon make
another threads or RFC about this subject. Let's talk in this thread later. :)
[snip]
>>>> +
>>>> +/* The regulator consumer names for external voltage regulators */
>>>> +static struct regulator_bulk_data supplies[] = {
>>>> + {
>>>> + .supply = "core", /* ARM core power, 1.2V */
>>>> + }, {
>>>> + .supply = "dig_18", /* digital power 1, 1.8V */
>>>> + }, {
>>>> + .supply = "d_sensor", /* sensor power 1, 1.8V */
>>>> + }, {
>>>> + .supply = "dig_28", /* digital power 2, 2.8V */
>>>> + }, {
>>>> + .supply = "a_sensor", /* analog power */
>>>> + }, {
>>>> + .supply = "dig_12", /* digital power 3, 1.2V */
>>>> + },
>>>> +};
>>>
>>> This looks like something that belongs to board code, or perhaps in the near
>>> future, to the device tree. The power supplies that are required by a device
>>> is highly board dependent.
>> If the regulator name is not common all M-5MOLS, You're right.
>> But the regulator name of M-5MOLS is fixed.
>
> As far as I understand, M-5MOLS is a sensor which you can, in principle,
> attach to more or less random hardware. The regulators are not part of the
> sensor. If someone adds a board which has regulators names or otherwise
> arranged differently, this change must be done at that time.
Sylwester already explained about this, and I agree with Sylwester.
And I want to add more comments.
The point is the regulator consumer names and the sensor's power names do not
depend on(or are irrelevant) each other, and we can not define or explain about
the platform or board only having the regulator's names in the drivers.
Namely, it means these names in the driver is not a platform side, and if the
regulator
framework is available in any other drivers, we can use regulator name for
convenient.
So then, if the name is clear and been not changed until now, I think this
usage of
regulator framework's is fine.
[snip]
>>>
>>> #define I2C_SIZE_U8 1
>> I already try to do like this, using width as definition.
>> But it makes many lines over 80 characters. Moreover, using just number
>> is more simple in this case.
>
> Wrapping lines is also possible but sometimes it's just better not to.
I didn't know that before. I'll keep that in mind. Thanks :)
[snip]
>>>>
>>>> +
>>>> + usleep_range(200, 200);
>>>
>>> Why to sleep always? Does the sensor require a delay between each I2C
>>> access?
>> It's experimental values. The M-5MOLS I2C communication is a litte sensitive,
>> and I expect that this sensor is integrated
Re: v4l2 device property framework in userspace
Hi Martin, I'm not an expert of V4L2 and this camera sensor, too. But, if you don't mind, I want to leave some comments about the registers, and I hope that it helps you. 2011-05-30 오후 9:07, Martin Strubel 쓴 글: > Hi Hans, > >> >> Can you give examples of the sort of things that are in those registers? >> Is that XML file available somewhere? Are there public datasheets? >> > > If you mean the sensor datasheets, many of them are buried behind NDAs, > but people are writing opensourced headers too...let's leave this to the > lawyers. > > Here's an example: http://section5.ch/downloads/mt9d111.xml > The XSLT sheets to generate code from it are found in the netpp > distribution, see http://www.section5.ch/netpp. You might have to read > some of the documentation to get to the actual clues. As you said, obviously this camera has a lot of registers. But, IMHO, even it can be expressed by one subdev driver like any other ones. Almost registers can be absorbed and adapted at the start(or booting) time. And the most others also can be defined at the current V4L2 APIs. (like controls, croppings, buffers, powers, etc) The matter is to find which factor can vary, when the camera setting is varied by the board as you said. And in just my short thinking, this is not much to catch. If there are such things, not expressed using current V4L2 APIs, but needed for your works or your board, you can submit this APIs to ML. The best thing is, you collect such things(it can be express current V4L2 APIs), and submit new V4L2 APIs, because there are many other people handling camera driver like you, and they can think similary like you. For sure, they can welcome to birth new APIs. Cheers, Heungjun Kim -- 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
Re: I just wondering how to set shutter or aperture value in uvc driver.
Hi Laurent, 2011-05-25 오후 8:17, Laurent Pinchart 쓴 글: > Hi Heungjun, > > On Wednesday 25 May 2011 08:49:31 Kim, HeungJun wrote: >> Hi Laurent, >> >> I try to add the more exposure methods of the M-5MOLS driver. Currently, >> the only 2 exposure type are available in the M-5MOLS driver - >> V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to shutter, >> aperture exposure value, of course auto exposure. >> So, I found the only UVC driver looks like using extra enumerations >> V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. >> But, I don't know how to set the each value in the each mode. >> >> The way pointed the specific value is only one - >> V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the >> each mode? > > You can control the aperture using the V4L2_CID_IRIS_ABSOLUTE control. See > http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#camera- > controls for more information regarding the exposure and iris controls. > Thanks for response, and I could understand this! Sorry for pre-checking documents. :) Regards, Heungjun Kim -- 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
Re: I just wondering how to set shutter or aperture value in uvc driver.
missing. sorry :) 2011-05-25 오후 3:49, Kim, HeungJun 쓴 글: > Hi Laurent, > > I try to add the more exposure methods of the M-5MOLS driver. Currently, > the only 2 exposure type are available in the M-5MOLS driver - > V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to the HW is capable to shutter, aperture exposure value, of course auto exposure. > > So, I found the only UVC driver looks like using extra enumerations > V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. > But, I don't know how to set the each value in the each mode. > > The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. > So, how can I set the specific value at the each mode? > > > Regards, > Heungjun Kim -- 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
I just wondering how to set shutter or aperture value in uvc driver.
Hi Laurent, I try to add the more exposure methods of the M-5MOLS driver. Currently, the only 2 exposure type are available in the M-5MOLS driver - V4L2_EXPOSURE_AUTO, V4L2_EXPOSURE_MANUAL. But, the HW is capable to So, I found the only UVC driver looks like using extra enumerations V4L2_EXPOSURE_SHUTTER_PRIORITY, V4L2_EXPOSURE_APERTURE_PRIORITY. But, I don't know how to set the each value in the each mode. The way pointed the specific value is only one - V4L2_CID_EXPOSURE_ABSOLUTE. So, how can I set the specific value at the each mode? Regards, Heungjun Kim -- 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
Re: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
2011-04-05 오후 2:36, Kim, HeungJun 쓴 글:
> Hi Sungchun,
>
> The below comments and issues looks the firmware issues.
> I add another comments, so you can check this out.
>
> The first plan of this driver I have, is to merge the basic driver code
> of M-5MOLS. Because, the M-5MOLS has many variation of versions. It makes
Missig "hard". :)
> to send the driver to ML or be merged, also respond when the problem issued.
>
> The version considered with version, probably will be the next version.
>
>
> 2011-04-04 오후 9:20, Sungchun Kang 쓴 글:
>> Hi heungjun,
>> I have tested this version for a few days.
>>
>> On 03/16/2011 10:30 PM, Kim, Heungjun wrote:
>>> -Original Message-
>>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>>> ow...@vger.kernel.org] On Behalf Of Kim, Heungjun
>>> Sent: Wednesday, March 16, 2011 10:39 PM
>>> To: linux-media@vger.kernel.org
>>> Cc: hverk...@xs4all.nl; laurent.pinch...@ideasonboard.com; Kim,
>>> Heungjun; Sylwester Nawrocki; Kyungmin Park
>>> Subject: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
>>>
>>> Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated
>>> image signal processor.
>>>
>>> Signed-off-by: Heungjun Kim
>>> Signed-off-by: Sylwester Nawrocki
>>> Signed-off-by: Kyungmin Park
>>> ---
>>>
>>> Hi Hans and everyone,
>>>
>>> This is sixth version of M-5MOLS 8 Mega Pixel camera sensor. And, if
>>> you see
>>> previous version, you can find at:
>>> http://www.spinics.net/lists/linux-media/msg29350.html
>>>
>>> This driver patch is fixed several times, and the important issues is
>>> almost
>>> corrected. And, I hope that this is the last version one merged for
>>> 2.6.39.
>>> I look forward to be reviewed one more time.
>>>
>>> The summary of this version's feature is belows:
>>>
>>> 1. Add focus control
>>> : I've suggest menu type focus control, but I agreed this
>>> version is
>>> not yet the level accepted. So, I did not use focus control
>>> which
>>> I suggest.
>>> The M-5MOLS focus routine takes some time to execute. But, the
>>> user
>>> application calling v4l2 control, should not hanged while
>>> streaming
>>> using q/dqbuf. So, I use workqueue. I want to discuss the focus
>>> subject on mailnglist next time.
>>>
>>
>> I wonder this feature is dependent on this firmware version?
>>
>> .snip
> The value can be changable by the firmware, but the usage of focus is not.
> The specific mode can be added too. But, it also maintains same usage.
>
> It's scheduled at the next time to consider the version. But, it's hard to
> consider all cases.
>
>>
>>> +static int m5mols_start_monitor(struct v4l2_subdev *sd)
>>> +{
>>> + struct m5mols_info *info = to_m5mols(sd);
>>> + int ret;
>>> +
>>> + ret = m5mols_set_mode(sd, MODE_PARAM);
>>> + if (!ret)
>>> + ret = i2c_w8_param(sd, CAT1_MONITOR_SIZE, info-
>>>> res_preset);
>>> + if (!ret)
>>> + ret = i2c_w8_param(sd, CAT1_MONITOR_FPS, info->fps_preset);
>>> + if (!ret)
>>> + ret = m5mols_set_mode(sd, MODE_MONITOR);
>>> + if (!ret && info->do_once) {
>>> + /* After probing the driver, this should be callde once.
>>> */
>>> + v4l2_ctrl_handler_setup(&info->handle);
>> As test result, When sensor is set monitor mode, if this API is called,
>> Preview data(get from sensor) is craked. Surely, it is good working if this
>> API is called in paramset mode.
>> That waw no problem in Version 5. Because it is returned before
>> v4l2_ctrl_handler_init()
>> In m5mols_init_controls(version 5) :
>> ret = i2c_r16_ae(sd, CAT3_MAX_GAIN_MON, (u32 *)&max_ex_mon);
>> if (ret)
>> return ret; // if success, return.
>>
>> My test case is :
>> S_power->s_fmt->s_stream.
> It's a little tricky to control parameter & monitor mode in the M-5MOLS
> sensor.
> Any commands or control is specified that it's available in Docunemt, but
> it's just literaly "available", doesn't mean "working well". Especially,
> the version difference between firmware is the biggest source of this
> problems.
>
> Probably, the sensor you have is a different firmware I think.
> So If there is any other problem, I recommend to use previous version plz.
>
> If you show me the all version strings, I might help you.
>
>>
>> .
>> BRs Sungchun.
>>
>>
>
> Thanks for comments, and any other issues or opinions, let me know.
>
> Regards,
> Heungjun Kim
> --
> 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
>
--
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
Re: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
Hi Sungchun,
The below comments and issues looks the firmware issues.
I add another comments, so you can check this out.
The first plan of this driver I have, is to merge the basic driver code
of M-5MOLS. Because, the M-5MOLS has many variation of versions. It makes
to send the driver to ML or be merged, also respond when the problem issued.
The version considered with version, probably will be the next version.
2011-04-04 오후 9:20, Sungchun Kang 쓴 글:
> Hi heungjun,
> I have tested this version for a few days.
>
> On 03/16/2011 10:30 PM, Kim, Heungjun wrote:
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> ow...@vger.kernel.org] On Behalf Of Kim, Heungjun
>> Sent: Wednesday, March 16, 2011 10:39 PM
>> To: linux-media@vger.kernel.org
>> Cc: hverk...@xs4all.nl; laurent.pinch...@ideasonboard.com; Kim,
>> Heungjun; Sylwester Nawrocki; Kyungmin Park
>> Subject: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
>>
>> Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated
>> image signal processor.
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Sylwester Nawrocki
>> Signed-off-by: Kyungmin Park
>> ---
>>
>> Hi Hans and everyone,
>>
>> This is sixth version of M-5MOLS 8 Mega Pixel camera sensor. And, if
>> you see
>> previous version, you can find at:
>> http://www.spinics.net/lists/linux-media/msg29350.html
>>
>> This driver patch is fixed several times, and the important issues is
>> almost
>> corrected. And, I hope that this is the last version one merged for
>> 2.6.39.
>> I look forward to be reviewed one more time.
>>
>> The summary of this version's feature is belows:
>>
>> 1. Add focus control
>> : I've suggest menu type focus control, but I agreed this
>> version is
>> not yet the level accepted. So, I did not use focus control
>> which
>> I suggest.
>> The M-5MOLS focus routine takes some time to execute. But, the
>> user
>> application calling v4l2 control, should not hanged while
>> streaming
>> using q/dqbuf. So, I use workqueue. I want to discuss the focus
>> subject on mailnglist next time.
>>
>
> I wonder this feature is dependent on this firmware version?
>
> .snip
The value can be changable by the firmware, but the usage of focus is not.
The specific mode can be added too. But, it also maintains same usage.
It's scheduled at the next time to consider the version. But, it's hard to
consider all cases.
>
>> +static int m5mols_start_monitor(struct v4l2_subdev *sd)
>> +{
>> +struct m5mols_info *info = to_m5mols(sd);
>> +int ret;
>> +
>> +ret = m5mols_set_mode(sd, MODE_PARAM);
>> +if (!ret)
>> +ret = i2c_w8_param(sd, CAT1_MONITOR_SIZE, info-
>>> res_preset);
>> +if (!ret)
>> +ret = i2c_w8_param(sd, CAT1_MONITOR_FPS, info->fps_preset);
>> +if (!ret)
>> +ret = m5mols_set_mode(sd, MODE_MONITOR);
>> +if (!ret && info->do_once) {
>> +/* After probing the driver, this should be callde once.
>> */
>> +v4l2_ctrl_handler_setup(&info->handle);
> As test result, When sensor is set monitor mode, if this API is called,
> Preview data(get from sensor) is craked. Surely, it is good working if this
> API is called in paramset mode.
> That waw no problem in Version 5. Because it is returned before
> v4l2_ctrl_handler_init()
> In m5mols_init_controls(version 5) :
> ret = i2c_r16_ae(sd, CAT3_MAX_GAIN_MON, (u32 *)&max_ex_mon);
> if (ret)
> return ret; // if success, return.
>
> My test case is :
> S_power->s_fmt->s_stream.
It's a little tricky to control parameter & monitor mode in the M-5MOLS sensor.
Any commands or control is specified that it's available in Docunemt, but
it's just literaly "available", doesn't mean "working well". Especially,
the version difference between firmware is the biggest source of this problems.
Probably, the sensor you have is a different firmware I think.
So If there is any other problem, I recommend to use previous version plz.
If you show me the all version strings, I might help you.
>
> .
> BRs Sungchun.
>
>
Thanks for comments, and any other issues or opinions, let me know.
Regards,
Heungjun Kim
--
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
Re: [RFC] API for controlling Scenemode Preset
Hi Laurent, 2011. 3. 31., 오후 11:12, Laurent Pinchart 작성: > Hi HeungJun, > > On Thursday 31 March 2011 07:39:09 Kim, HeungJun wrote: >> Hello everyone, >> >> This is a suggestion about the preset for the scenemode of camera. It's >> just one API, and its role determines which current scenemode preset of >> camera is. >> >> The kinds of scenemode are various at each camera. But, as you look around >> camera, the each scenemode has common name and the specific scenemode just >> exist or not. So, I started to collect the scenemode common set of Fujitsu >> M-5MOLS and NEC CE147. And, I found these modes are perfetly matched, >> althogh the names are a little different. > > [snip] > > Are those presets really implemented in hardware ? I expect that they control > various configuration parameters such as white balance. Can all those > parameters also be controlled manually, or are they (or some of them) > settable > only through the scene mode presets ? Yeah. These modes can be easily activated only one I2C register access. So, maybe this is the reason why this is called 'preset'. Although it needs previous works, the all recommended flow table(or order? I can't express well) of I2C command(like relative white balance, exposure, iso, etc) are ready in document. Probably, it can be concerned about control clustered with the other controls. Because, the scene mode itself means 'preset' which is accompanied by various control. But, I think doing that is the role of driver's side, and the truth to be needed scene mode API is irrelevant. Thanks for comments. Regards, Heungjun Kim > > -- > Regards, > > Laurent Pinchart > -- > 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 -- 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
[RFC] API for controlling Scenemode Preset
Hello everyone,
This is a suggestion about the preset for the scenemode of camera. It's just
one API, and its role determines which current scenemode preset of camera is.
The kinds of scenemode are various at each camera. But, as you look around
camera, the each scenemode has common name and the specific scenemode just
exist or not. So, I started to collect the scenemode common set of Fujitsu
M-5MOLS and NEC CE147. And, I found these modes are perfetly matched, althogh
the names are a little different.
I introduce these scenemode preset.
Fujitsu M5MONEC CE147
PortraitPortrait
Landscape Landscape
Sports Sports
Party & Indoor Indoor & Party
Beach & SnowBeach & Snow
Sunset Sunset
Dawn & Dusk Dawn
FallFallColor
Night Night
Against Light Against
FireFireworks
TextText
Candle Candlelight
The camera just one scememode at one time, so these can be express by menu type
like this.
CID name
: V4L2_CID_SCENEMODE
CID enumeration
: enum v4l2_scenemode {
V4L2_SCENEMODE_PORTRAIT = 0,
V4L2_SCENEMODE_LANDSCAPE= 1,
V4L2_SCENEMODE_SPORTS = 2,
V4L2_SCENEMODE_PARTY_INDOOR = 3,
V4L2_SCENEMODE_BEACH_SNOW = 4,
V4L2_SCENEMODE_SUNSET = 5,
V4L2_SCENEMODE_DAWN_DUSK= 6,
V4L2_SCENEMODE_FALLCOLOR= 7,
V4L2_SCENEMODE_NIGHT= 8,
V4L2_SCENEMODE_AGAINST_LIGHT= 9,
V4L2_SCENEMODE_FIREWORKS= 10,
V4L2_SCENEMODE_TEXT = 11,
V4L2_SCENEMODE_CANDLELIGHT = 12,
};
Thanks for reading, and welcome always any comments & opinions & any other
cases.
I want to know any other case very much. :)
Ragards,
Heungjun Kim
--
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
Re: [RFC] V4L2 API for flash devices
Hi Sakari, 2011. 3. 30., 오후 8:37, Sakari Ailus 작성: > Kim, HeungJun wrote: >> Hi Sakari, > > Hi HeungJun, > >> 2011-03-29 오후 11:41, Sakari Ailus 쓴 글: >>> Kim, HeungJun wrote: >> [snip] >>>> I think it's not different method to turn on/off, whatever the mode name >>>> is. >>>> But, the mode name DEDICATED is look more reasonable, because the reason >>>> which is devided FLASH and TORCH in the mode, is why only power up the led, >>>> not sensor. >>> >>> Sensor? Is the flash part of the sensor module for you? >> Yes. The flash is a part of the sensor module(our case like M-5MOLS). >> Precisely, the sensor internal core's gpio pin is connected with >> external Flash LED, and the control master is the sensor internal core. >> For turnning on the Flash LED, we should use I2C register access. >> So, I think it's exactly matches with hardware strobe as you metioned. > > Ok, I think I'm lost now. :-) > > What signals are sent from sensor to flash in both torch and flash cases? I guess the signal probably is just continuous repetition High/Low like PWM signal, which is generated by the core of sensor module. Although I don't check what signal it is, it's very possible. Because it's the only way to be able to control intensity of Flash. So, I think the torch and flash case is the same way or signal in this case. > >>> I think it should be other factors than the flash mode that are used to >>> make the decision on whether to power on the sensor or not. >>> >>> The factors based on which to power the subdevs probably will be >>> discussed in the future, and which entity is responsible for power >>> management. The power management code originally was part of the Media >>> controller framework but it was removed since it was not seen to be >>> generic enough. >>> >>> Many subdev drivers (including the adp1653) basically get powered as >>> long as the subdev device node is open. Sensor can be powered based on >>> other factors as well, such as the streaming state and what are the >>> connections to the video nodes. >> That's the start point I said. When the user use only the flash, it should be >> accompanied(of course, I have same circumstance) by opening the videonode >> and doing the media control operation, but we have no option to do because >> it's depending on the hardware connection architecture. > > When the user only needs to use the flash, in this case the user must > open the subdev node which is exported by the flash controller driver. > Not the video node, which is handled in the bridge (ISP) driver. > >> So, I suggesst that, if we can not give to users(of course, this user >> want to use only flash function, not the camera) proper method usage >> (openning the videonode for using flash), let's express that the camera >> flash is used in the DEDICATED MODE now, as the enumeration name DEDICATED. > > No. The video nodes should not be involved since they are related to the > bridge (ISP) which is not needed to use the flash. Assuming that this is > the situation. > > This is how the use case should go: > > 1. open subdev node, e.g. /dev/v4l-subdev0, which is the flash > (flash controller powered on) > 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_TORCH > (flash is on now) > 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_NONE > (flash is off now) > 3. close the file handle > (flash controller powered off) Probably you mean media controller framework is based on. I get it. :) > >> But, I think it might be not a big issue. So, any others don't comment at >> this, >> it's ok for me to pass this naming issue. >> >> I can see this API is very cool for camera man just like me. > > Thanks! > >> plus: actually I have the one of N-series, N810. So, the omap3isp is >> available to >> activate this device, not even it's cpu is omap3? Just question. > > The N810 has OMAP 2420 which has a completely different camera bridge, > and there's no flash. The drivers for the camera in N810 are omap24xxcam > and tcm825x. The drivers are functional in mainline but the platform > data is missing, as well as the CBUS driver. This work is queued but > unknown when there's time for this. Thanks for plus reply. I've tested tony's patch for booting the ubuntu long time ago, but I'm sure this gadget is good device. > > Regards, > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > -- > 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 -- 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
Re: [RFC] V4L2 API for flash devices
Hi Sakari, 2011-03-29 오후 11:41, Sakari Ailus 쓴 글: > Kim, HeungJun wrote: [snip] >> I think it's not different method to turn on/off, whatever the mode name is. >> But, the mode name DEDICATED is look more reasonable, because the reason >> which is devided FLASH and TORCH in the mode, is why only power up the led, >> not sensor. > > Sensor? Is the flash part of the sensor module for you? Yes. The flash is a part of the sensor module(our case like M-5MOLS). Precisely, the sensor internal core's gpio pin is connected with external Flash LED, and the control master is the sensor internal core. For turnning on the Flash LED, we should use I2C register access. So, I think it's exactly matches with hardware strobe as you metioned. > > I think it should be other factors than the flash mode that are used to > make the decision on whether to power on the sensor or not. > > The factors based on which to power the subdevs probably will be > discussed in the future, and which entity is responsible for power > management. The power management code originally was part of the Media > controller framework but it was removed since it was not seen to be > generic enough. > > Many subdev drivers (including the adp1653) basically get powered as > long as the subdev device node is open. Sensor can be powered based on > other factors as well, such as the streaming state and what are the > connections to the video nodes. That's the start point I said. When the user use only the flash, it should be accompanied(of course, I have same circumstance) by opening the videonode and doing the media control operation, but we have no option to do because it's depending on the hardware connection architecture. So, I suggesst that, if we can not give to users(of course, this user want to use only flash function, not the camera) proper method usage (openning the videonode for using flash), let's express that the camera flash is used in the DEDICATED MODE now, as the enumeration name DEDICATED. But, I think it might be not a big issue. So, any others don't comment at this, it's ok for me to pass this naming issue. I can see this API is very cool for camera man just like me. Cheers! plus: actually I have the one of N-series, N810. So, the omap3isp is available to activate this device, not even it's cpu is omap3? Just question. Regards, Heungjun Kim -- 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
Re: [RFC] V4L2 API for flash devices
Hi Sakari, Here's my humble opinions about this RFC. Almost, this control may be also applied immediately in our case. But, I have some opinions about that. So, read comments plz and I wish this might be help to it. 2011-03-28 오후 9:55, Sakari Ailus 쓴 글: > Hi, > > This is a proposal for an interface for controlling flash devices on the > V4L2/v4l2_subdev APIs. My plan is to use the interface in the ADP1653 > driver, the flash controller used in the Nokia N900. > > Comments and questions are very, very welcome! > > > Scope > = > > This RFC is focused mostly on the ADP1653 [1] and similar chips [2, 3] > which provides following functionality. [2, 3] mostly differ on the > available faults --- for example, there are faults also for the > indicator LED. > > - High power LED output (flash or torch modes) > - Low power indicator LED output (a.k.a. privacy light) > - Programmable flash timeout > - Software and hardware strobe > - Fault detection > - Overvoltage > - Overtemperature > - Short circuit > - Timeout > - Programmable current (both high-power and indicator LEDs) > > If anyone else is aware of hardware which significantly differs from > these and does not get served well under the proposed interface, please > tell about it. > > This RFC does NOT address the synchronisation of the flash to a given > frame since this task is typically performed by the sensor through a > strobe signal. The host does not have enough information for this --- > exact timing information on the exposure of the sensor pixel array. In > this case the flash synchronisation is visible to the flash controller > as the hardware strobe originating from the sensor. > > Flash synchronisation requires > > 1) flash control capability from the sensor including a strobe output, > 2) strobe input in the flash controller, > 3) (optionally) ability to program sensor parameters at given frame, > such as flash strobe, and > 4) ability to read back metadata produced by the sensor related to a > given frame. This should include whether the frame is exposed with > flash, i.e. the sensor's flash strobe output. > > Since we have little examples of both in terms of hardware support, > which is in practice required, it was decided to postpone the interface > specification for now. [6] > > Xenon flash controllers exist but I don't have a specific example of > those. Typically the interface is quite simple. Gpio pins for charge and > strobe. The length of the strobe signal determines the strength of the > flash pulse. The strobe is controlled by the sensor as for LED flash if > it is hardware based. > > > Known use cases > === > > The use case listed below concentrate on using a flash in a mobile > device, for example in a mobile phone. The use cases could be somewhat > different in devices the primary use of which is camera. > > Unsynchronised LED flash (software strobe) > -- > > Unsynchronised LED flash is controlled directly by the host as the > sensor. The flash must be enabled by the host before the exposure of the > image starts and disabled once it ends. The host is fully responsible > for the timing of the flash. > > Example of such device: Nokia N900. > > > Synchronised LED flash (hardware strobe) > > > The synchronised LED flash is pre-programmed by the host (power and > timeout) but controlled by the sensor through a strobe signal from the > sensor to the flash. > > The sensor controls the flash duration and timing. This control > typically must be programmed to the sensor, and specifying an interface > for this is out of scope of this RFC. > > The LED flash controllers we know of can function in both synchronised > and unsynchronised modes. This case used in Galaxy S and the other these days smartphone in Samsung. So, I checked possible APIs for our case, but it's not almost very different with software strobe. It's safe to say, software strobe may be enough detailed to express hardware strobe. So, software strobe APIs can cover the others. This is just samsung case, but any case is possible. Is there any other cases to be introduced, everybody? > > > LED flash as torch > -- > > LED flash may be used as torch in conjunction with another use case > involving camera or individually. [4] > > > Synchronised xenon flash > > > The synchronised xenon flash is controlled more closely by the sensor > than the LED flash. There is no separate intensity control for the xenon > flash as its intensity is determined by the length of the strobe pulse. > Several consecutive strobe pluses are possible but this needs to be > still controlled by the sensor. > > > Proposed interface > == > > The flash, either LED or xenon, does not require large amounts of data > to control it. There are parameters to control it but they are > independent and assumably som
[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation
Document about the mode of auto focus and new controls about rectangle auto
focus
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 67 +
Documentation/DocBook/v4l/videodev2.h.xml |8 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only
control.
+
+ V4L2_CID_FOCUS_AUTO_MODE
+ enum v4l2_focus_auto_mode_type
+ Enables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+
+
+
+
+
+
+
V4L2_FOCUS_AUTO_NORMAL
+ Normal mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_MACRO
+ Macro mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_CONTINUOUS
+ Continuous mode Auto focus, continuous shot.
+
+
+
V4L2_FOCUS_AUTO_FACE_DETECTION
+ Face detection mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_RECTANGLE
+ Rectangle mode Auto focus, single shot.
+
+
+
+
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
+ integer
+ This control means the left
+side's point of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
+ integer
+ This control means the top
+side's point of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
+ integer
+ This control means the width
+length of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
+ integer
+ This control means the height
+length of the rectangle expressing focusing spot.
+
+
+
V4L2_CID_PRIVACY
boolean
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+enum v4l2_focus_auto_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ "Normal Mode",
+ "Macro Mode",
+ "Continuous Mode",
+ "Face Detection Mode",
+ "Rectangle Mode",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+ case V4L2_CID_FOCUS_AUTO_MODE: return "Focus, Mode";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle
Width";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle
Height";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ "Normal Mode",
+ "Macro Mode",
+ "Continuous Mode",
+ "Face Detection Mode",
+ "Rectangle Mode",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+ case V4L2_CID_FOCUS_AUTO_MODE: return "Focus, Mode";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle
Width";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle
Height";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
Hello, This is third version of RFC patch series about adding auto focus mode and controls. The patch of the previous version bring about the issue to be able to execute only once, not repeatedly. Because the each modes are defined by menu type. To solve this, we add the new control of choosing focus mode, and if doing repeatedly, it's alright that you determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. In the case of new added rectangle mode, these each controls belongs to 4 new controls, can make to point by the form of rectangle. These 4 new each control values mean left x coordinate, top y coordinate, width x length, height y length. It's similar to structure v4l2_rect. You can find previous threads about this: http://www.spinics.net/lists/linux-media/msg29446.html Thanks and Regards, Heungjun Kim -- 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
Re: [RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
The comments of 2/2 patch are wrong. It's my fault. Please ignore this. And I'll send again. Sorry to confuse. 2011-03-22 오후 5:34, Kim, HeungJun 쓴 글: > Hello, > > This is third version of RFC patch series about adding auto focus mode > and controls. The patch of the previous version bring about the issue > to be able to execute only once, not repeatedly. Because the each modes > are defined by menu type. To solve this, we add the new control of > choosing focus mode, and if doing repeatedly, it's alright that you > determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. > > In the case of new added rectangle mode, these each controls belongs to > 4 new controls, can make to point by the form of rectangle. These 4 new > each control values mean left x coordinate, top y coordinate, > width x length, height y length. It's similar to structure v4l2_rect. > > You can find previous threads about this: > http://www.spinics.net/lists/linux-media/msg29446.html > > Thanks and Regards, > Heungjun Kim > -- > 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 > -- 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
[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 67 +
Documentation/DocBook/v4l/videodev2.h.xml |8 +++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only
control.
+
+ V4L2_CID_FOCUS_AUTO_MODE
+ enum v4l2_focus_auto_mode_type
+ Enables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+
+
+
+
+
+
+
V4L2_FOCUS_AUTO_NORMAL
+ Normal mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_MACRO
+ Macro mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_CONTINUOUS
+ Continuous mode Auto focus, continuous shot.
+
+
+
V4L2_FOCUS_AUTO_FACE_DETECTION
+ Face detection mode Auto focus, single shot.
+
+
+
V4L2_FOCUS_AUTO_RECTANGLE
+ Rectangle mode Auto focus, single shot.
+
+
+
+
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
+ integer
+ This control means the left
+side's point of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
+ integer
+ This control means the top
+side's point of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
+ integer
+ This control means the width
+length of the rectangle expressing focusing spot.
+
+
+
+ V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
+ integer
+ This control means the height
+length of the rectangle expressing focusing spot.
+
+
+
V4L2_CID_PRIVACY
boolean
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+enum v4l2_focus_auto_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus
It supports various modes of auto focus. Each modes define as the enumerations
of menu type.
V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE
In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.
V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT
Signed-off-by: Kim, Heungjun
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 16
include/linux/videodev2.h| 13 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto_mode[] = {
+ "Normal Mode",
+ "Macro Mode",
+ "Continuous Mode",
+ "Face Detection Mode",
+ "Rectangle Mode",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO_MODE:
+ return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+ case V4L2_CID_FOCUS_AUTO_MODE: return "Focus, Mode";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle
Width";
+ case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle
Height";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_FOCUS_AUTO_MODE (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum v4l2_focus_mode_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+ V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+ V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT (V4L2_CID_CAMERA_CLASS_BASE+23)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.0.4
--
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
[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls
Hello, This is third version of RFC patch series about adding auto focus mode and controls. The patch of the previous version bring about the issue to be able to execute only once, not repeatedly. Because the each modes are defined by menu type. To solve this, we add the new control of choosing focus mode, and if doing repeatedly, it's alright that you determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO. In the case of new added rectangle mode, these each controls belongs to 4 new controls, can make to point by the form of rectangle. These 4 new each control values mean left x coordinate, top y coordinate, width x length, height y length. It's similar to structure v4l2_rect. You can find previous threads about this: http://www.spinics.net/lists/linux-media/msg29446.html Thanks and Regards, Heungjun Kim -- 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
referencing other control values in the clustered control
Hi Hans, I have a question about referencing control values. For example: 1) "A" control and "B" control is clustered, and each is defined v4l2_ctrl a, b. 2) These two control is relevant, and start to make one process by real control "A". 3) The b->val is should be referenced for process in the "A" control function, even though in which is the "A". And, in this case, 3) is right? I mean, if the ctrl value clustered with another ctrl can be referenced in the another ctrl function, or not. Regards, Heungjun Kim -- 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
Re: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
Hi Sylwester, 2011-03-20 오전 4:28, Sylwester Nawrocki 쓴 글: > On 03/19/2011 04:11 PM, Kim HeungJun wrote: >> Hi Sylwester, >> >> Thanks for the reviews. :) >> >> 2011. 3. 19., 오후 10:37, Sylwester Nawrocki 작성: >> >>> Hi HeungJun, >>> >>> On 03/16/2011 02:38 PM, Kim, Heungjun wrote: >>>> Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated >>>> image signal processor. >>>> [snip] >>>> >>>> 3. Speed-up whole I2C operation >>>>: I've tested several times for decreasing the stabilization time >>>>while I2C communication, and I have find proper time. Of course, >>>>it's more faster than previous version. >>> >>> That sounds good. Do you think the delays before I2C read/write could >>> be avoided in some (if not all) cases by using some status registers >>> polling? >> I don't understand literally. Could you explain more detailed with some >> examples? >> My understanding is that it might be an issues or problem when getting some >> status registers with polling it. is it right? > > My concern is that we might not need an extra delay between consecutive > read or write operations in every case. Possibly it would be enough > to read the status of some operations instead. But that just what I suspect. Ah, I understand. The consecutive delay needs to read/write operations. Because, in non-delay cases, I found the values is not changed to be read when the driver is reading continuously at the different address. I means, if there is not regular amount of delay in r/w operations, the value is kept the previous value to be read by I2C operation. It's the same way in writing case. It's wierd. It might be different the kind of M-5MOLS sensor's FW and packaging type. But, I expect that the internal ARM core of M-5MOLS takes time to proceed something and to load values through I2C bus for the host process. Regards, Heungjun Kim -- 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
Re: [PATCH] Add support for M-5MOLS 8 Mega Pixel camera
Hi Sylwester, Thanks for the reviews. :) 2011. 3. 19., 오후 10:37, Sylwester Nawrocki 작성: > Hi HeungJun, > > On 03/16/2011 02:38 PM, Kim, Heungjun wrote: >> Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated >> image signal processor. >> >> Signed-off-by: Heungjun Kim >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> >> Hi Hans and everyone, >> >> This is sixth version of M-5MOLS 8 Mega Pixel camera sensor. And, if you see > > Would be good to indicate the version in the subject too. > >> previous version, you can find at: >> http://www.spinics.net/lists/linux-media/msg29350.html >> >> This driver patch is fixed several times, and the important issues is almost >> corrected. And, I hope that this is the last version one merged for 2.6.39. >> I look forward to be reviewed one more time. >> >> The summary of this version's feature is belows: >> >> 1. Add focus control >> : I've suggest menu type focus control, but I agreed this version is >> not yet the level accepted. So, I did not use focus control which >> I suggest. >> The M-5MOLS focus routine takes some time to execute. But, the user >> application calling v4l2 control, should not hanged while streaming >> using q/dqbuf. So, I use workqueue. I want to discuss the focus >> subject on mailnglist next time. >> >> 2. Add irq routine >> : M-5MOLS can issues using GPIO pin, and I insert the basic routine >> of irq. This version handles only the Auto focus interrupt source. >> It shows only lens focusing status, don't any action now. >> >> 3. Speed-up whole I2C operation >> : I've tested several times for decreasing the stabilization time >> while I2C communication, and I have find proper time. Of course, >> it's more faster than previous version. > > That sounds good. Do you think the delays before I2C read/write could > be avoided in some (if not all) cases by using some status registers > polling? I don't understand literally. Could you explain more detailed with some examples? My understanding is that it might be an issues or problem when getting some status registers with polling it. is it right? > >> >> 4. Let streamon() be called once at the streamming >> : It might be an issue, videobuf2 framework calls streamon when >> qbuf() for enqueueing. It means, the driver's streamon() function > > No, that's not really the case. At last videobuf2 buf_queue op might be > called in response to VIDIOC_STREAMON. Certainly there must be some bug > in the host driver if subdev's s_stream is being called repeatedly. Ah, it's good news. I seemed to use some little old version of vb2. Then, I would try to merge new vb2 on our branch, and I need some help on that. I'll contact you. After that, I test new vb2 merged on our branch and chech if there is not any issues, I'll correct to use just enable variable not using is_streaming(), and also correct comments. Actually, that has happened low frame rate issues on M-5MOLS, I had have headache cause of this some weeks, and it's the suspects. :D It's my fault not to use newer version. So, letting me know this new version is very happy for me. > >> might be callled continuously if there is no proper handling in the >> subdev driver, and low the framerate by adding unneeded I2C operation. >> The M-5MOLS sensor needs command one time for streaming. If commands >> once, this sensor streams continuously, and this version handles it. >> >> 5. Update FW >> : It's a little tricky. Originally, the v4l2 frame provide load_fw(), >> but, there is the occasion which should do in openning the videonode, >> and it's the same occasion with us. So, if it's not wrong or it makes >> any problem, we hope to insert m5mols_update_fw() with weak attribute. >> And, I'm sorry that the fw updating code is confidential. unserstand >> by favor, plz. >> >> And, as always, this driver is tested on s5pc210 board using s5p-fimc driver. >> >> I'll wait for reviewing. >> >> Thanks and Regards, >> Heungjun Kim >> Samsung Electronics DMC R&D Center >> >> drivers/media/video/Kconfig |2 + >> drivers/media/video/Makefile |1 + >> drivers/media/video/m5mols/Kconfig |5 + >> drivers/media/video/m5mols/Makefile |3 + >> drivers/media/video/m
Re: the focus terms or sequences
Hi, 2011. 3. 17., 오전 12:27, Laurent Pinchart 작성: > On Wednesday 16 March 2011 16:17:30 Kim HeungJun wrote: >> 2011. 3. 16., 오후 11:15, Laurent Pinchart 작성: >>> On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote: >>>> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글: >>> [snip] [snip] >>> Is the macro focus mode a singleshot focus or a continuous auto-focus ? >> >> Of course. yes. > > Which one ? Singleshot ? Or CAF ? I mean Singleshot :) Regards, Heungjun Kim-- 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
Re: the focus terms or sequences
2011. 3. 16., 오후 11:15, Laurent Pinchart 작성: > Hi, > > On Wednesday 16 March 2011 05:50:11 Kim, HeungJun wrote: >> 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글: > > [snip] > >>> What bothers me with your auto-focus implementation is that the user >>> might want to perform auto-focus several times. Let's imagine this use >>> case: >>> >>> 1. The user points the camera (webcam, cellphone camera, digital camera, >>> it doesn't matter) at an object. >>> >>> 2. The user presses a button to perform singleshot auto-focus (it can be >>> a physical button or a button on the camera screen, once again it >>> doesn't matter). >>> >>> 3. The application sets the focus control to AUTO. >>> >>> 4. The driver and device perform auto-focus once. The lens is moved so >>> that the object is in focus. >>> >>> 5. The user points the camera at another object. >>> >>> 6. The user presses a button to perform singleshot auto-focus. >>> >>> 7. The applications sets the focus control to AUTO. As the focus control >>> value was already AUTO, nothing is done. >>> >>> This is clearly broken. That's why we need a V4L2 button control in >>> addition to the menu control. >> >> Yes. Youre'rignt. The menu control dosen't called one more with the same >> value. It's now worked I know. But, the reason why I choose menu type for >> focus, is because the menu type can let the user-application know how many >> kinds of focus this sensor have & support, using querymenu. The only way >> letting know, is currently the menu type. >> >> On the other hand, not-working twice or more executions is handled by >> user-application. The user-application want twice auto focus, it calls >> AUTO-Manual-(or any other control value)-and AUTO once again. It's wierd, >> but It can satisfy application and drivers. >> >> And, but it might be irrelevant, the user-application(or upper layer >> platform) can determine how to draw & arrange the UI objects after it >> knows the kinds of focus method at last. >> >> It may be a time to need another type of control. And such control should >> satisfy these: 1. letting the user-application know how many kinds in the >> controls(like a querymenu) 2. being available to be called one more. >> >> How about your opinion? > > I think we need a menu control (to select the focus type) and a button > control > (to run singleshot auto-focus). When the menu control is in auto-focus mode, > setting the button control will run the auto-focus algorithm once. Ah. it's very reasonable. When the focus mode keeps the menu type, and doing focus is button type, even if another new mode is needed to insert, we can add easily. I agree with this. But, the drivers using focus like uvc, should be changed. And we should probably consider the cluster between focus mode and execution. is it right? > > Is the macro focus mode a singleshot focus or a continuous auto-focus ? Of course. yes. I'll make another patch about this, and could you look around this? Thanks, Heungjun Kim-- 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
[PATCH] Add support for M-5MOLS 8 Mega Pixel camera
Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated image signal processor. Signed-off-by: Heungjun Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Hi Hans and everyone, This is sixth version of M-5MOLS 8 Mega Pixel camera sensor. And, if you see previous version, you can find at: http://www.spinics.net/lists/linux-media/msg29350.html This driver patch is fixed several times, and the important issues is almost corrected. And, I hope that this is the last version one merged for 2.6.39. I look forward to be reviewed one more time. The summary of this version's feature is belows: 1. Add focus control : I've suggest menu type focus control, but I agreed this version is not yet the level accepted. So, I did not use focus control which I suggest. The M-5MOLS focus routine takes some time to execute. But, the user application calling v4l2 control, should not hanged while streaming using q/dqbuf. So, I use workqueue. I want to discuss the focus subject on mailnglist next time. 2. Add irq routine : M-5MOLS can issues using GPIO pin, and I insert the basic routine of irq. This version handles only the Auto focus interrupt source. It shows only lens focusing status, don't any action now. 3. Speed-up whole I2C operation : I've tested several times for decreasing the stabilization time while I2C communication, and I have find proper time. Of course, it's more faster than previous version. 4. Let streamon() be called once at the streamming : It might be an issue, videobuf2 framework calls streamon when qbuf() for enqueueing. It means, the driver's streamon() function might be callled continuously if there is no proper handling in the subdev driver, and low the framerate by adding unneeded I2C operation. The M-5MOLS sensor needs command one time for streaming. If commands once, this sensor streams continuously, and this version handles it. 5. Update FW : It's a little tricky. Originally, the v4l2 frame provide load_fw(), but, there is the occasion which should do in openning the videonode, and it's the same occasion with us. So, if it's not wrong or it makes any problem, we hope to insert m5mols_update_fw() with weak attribute. And, I'm sorry that the fw updating code is confidential. unserstand by favor, plz. And, as always, this driver is tested on s5pc210 board using s5p-fimc driver. I'll wait for reviewing. Thanks and Regards, Heungjun Kim Samsung Electronics DMC R&D Center drivers/media/video/Kconfig |2 + drivers/media/video/Makefile |1 + drivers/media/video/m5mols/Kconfig |5 + drivers/media/video/m5mols/Makefile |3 + drivers/media/video/m5mols/m5mols.h | 251 ++ drivers/media/video/m5mols/m5mols_controls.c | 213 + drivers/media/video/m5mols/m5mols_core.c | 1062 ++ drivers/media/video/m5mols/m5mols_reg.h | 218 ++ include/media/m5mols.h | 35 + 9 files changed, 1790 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/m5mols/Kconfig create mode 100644 drivers/media/video/m5mols/Makefile create mode 100644 drivers/media/video/m5mols/m5mols.h create mode 100644 drivers/media/video/m5mols/m5mols_controls.c create mode 100644 drivers/media/video/m5mols/m5mols_core.c create mode 100644 drivers/media/video/m5mols/m5mols_reg.h create mode 100644 include/media/m5mols.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4498b94..581a0f9 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -746,6 +746,8 @@ config VIDEO_NOON010PC30 ---help--- This driver supports NOON010PC30 CIF camera from Siliconfile +source "drivers/media/video/m5mols/Kconfig" + config VIDEO_OMAP3 tristate "OMAP 3 Camera support (EXPERIMENTAL)" select OMAP_IOMMU diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index ace5d8b..a65458b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o diff --git a/drivers/media/video/m5mols/Kconfig b/drivers/media/video/m5mols/Kconfig new file mode 100644 index 000..220282b --- /dev/null +++ b/drivers/media/video/m5mols/Kconfig @@ -0,0 +1,5 @@ +config VIDEO_M5MOLS + tristate "Fujitsu M-5MOLS 8MP sensor support" + depends on I2C && VIDEO_V4L2 + ---help--- + T
Re: the focus terms or sequences
Hi Laurent, First, I hope to be good at the warsaw meeting. :) 2011-03-16 오전 9:14, Laurent Pinchart 쓴 글: > Hi HeungJun, > > On Monday 14 March 2011 08:02:01 Kim, HeungJun wrote: >> Hi Laurent, >> >> I heard of that there was a chance between you and Sylwester telling about >> the menu entries focus, and so after that, probably this menu style of the >> patch I sent, need to be more upgraded. So, can you tell me the kind or >> sequence of the UVC device breifly? >> >> I guess the word *AUTO* at the UVC device means doing focus continuously, >> not once or one time. > > That's correct. In the UVC context, auto focus means CAF and manual focus > means... well, manual focus :-) > >> But, at the sensors I used the *AUTO* focus means doing focus once, on the >> other hand *CONTINUOUS* means doing continuously. So, we need to be clear >> terms about focus. >> >> At the sensor I used, the focus needs 3 kinds of commands: >> 1) setting mode >> >> : it makes the lens initial position for each AF(Normal, Continuous, >> : Night mode Focus, etc), >> >> and set the AF status Idle. >> 2) execute AF >> >> : doing the move of the lens >> >> 3) read AF status >> >> : checking the lens status(Focus failed, Focus success, Idle, Busy) >> >> and do the proper jobs. >> >> I don't know uvc case well, so, If you share about this, it can be help. > > What bothers me with your auto-focus implementation is that the user might > want to perform auto-focus several times. Let's imagine this use case: > > 1. The user points the camera (webcam, cellphone camera, digital camera, it > doesn't matter) at an object. > > 2. The user presses a button to perform singleshot auto-focus (it can be a > physical button or a button on the camera screen, once again it doesn't > matter). > > 3. The application sets the focus control to AUTO. > > 4. The driver and device perform auto-focus once. The lens is moved so that > the object is in focus. > > 5. The user points the camera at another object. > > 6. The user presses a button to perform singleshot auto-focus. > > 7. The applications sets the focus control to AUTO. As the focus control > value > was already AUTO, nothing is done. > > This is clearly broken. That's why we need a V4L2 button control in addition > to the menu control. > Yes. Youre'rignt. The menu control dosen't called one more with the same value. It's now worked I know. But, the reason why I choose menu type for focus, is because the menu type can let the user-application know how many kinds of focus this sensor have & support, using querymenu. The only way letting know, is currently the menu type. On the other hand, not-working twice or more executions is handled by user-application. The user-application want twice auto focus, it calls AUTO-Manual-(or any other control value)-and AUTO once again. It's wierd, but It can satisfy application and drivers. And, but it might be irrelevant, the user-application(or upper layer platform) can determine how to draw & arrange the UI objects after it knows the kinds of focus method at last. It may be a time to need another type of control. And such control should satisfy these: 1. letting the user-application know how many kinds in the controls(like a querymenu) 2. being available to be called one more. How about your opinion? Regards, Heungjun Kim -- 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
the focus terms or sequences
Hi Laurent, I heard of that there was a chance between you and Sylwester telling about the menu entries focus, and so after that, probably this menu style of the patch I sent, need to be more upgraded. So, can you tell me the kind or sequence of the UVC device breifly? I guess the word *AUTO* at the UVC device means doing focus continuously, not once or one time. But, at the sensors I used the *AUTO* focus means doing focus once, on the other hand *CONTINUOUS* means doing continuously. So, we need to be clear terms about focus. At the sensor I used, the focus needs 3 kinds of commands: 1) setting mode : it makes the lens initial position for each AF(Normal, Continuous, Night mode Focus, etc), and set the AF status Idle. 2) execute AF : doing the move of the lens 3) read AF status : checking the lens status(Focus failed, Focus success, Idle, Busy) and do the proper jobs. I don't know uvc case well, so, If you share about this, it can be help. Thanks, Heungjun Kim -- 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
Re: [RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Hi Sylwester, 2011-03-09 오전 8:08, Sylwester Nawrocki 쓴 글: > Hi HeungJun, > > On 03/03/2011 04:22 PM, Laurent Pinchart wrote: >> Hi, >> >> On Thursday 03 March 2011 15:34:36 Kim HeungJun wrote: >>> 2011. 3. 3., 오후 10:24, Laurent Pinchart 작성: >>>> On Thursday 03 March 2011 14:17:10 Kim HeungJun wrote: >>>>> 2011. 3. 3., 오후 7:08, Laurent Pinchart 작성: >>>>>> On Thursday 03 March 2011 03:16:34 Kim, HeungJun wrote: >>>>>>> Document about the type changes and the enumeration of the auto focus >>>>>>> control. >>>>>>> >>>>>>> Signed-off-by: Heungjun Kim >>>>>>> Signed-off-by: Kyungmin Park >>>>>>> --- >>>>>>> Documentation/DocBook/v4l/controls.xml| 31 >>>>>>> +--- Documentation/DocBook/v4l/videodev2.h.xml >>>>>>> | 6 + >>>>>>> 2 files changed, 33 insertions(+), 4 deletions(-) >>>>>>> >>>>>>> diff --git a/Documentation/DocBook/v4l/controls.xml >>>>>>> b/Documentation/DocBook/v4l/controls.xml index 2fae3e8..889fa84 100644 >>>>>>> --- a/Documentation/DocBook/v4l/controls.xml >>>>>>> +++ b/Documentation/DocBook/v4l/controls.xml >>>>>>> @@ -1801,12 +1801,35 @@ negative values towards infinity. This is a >>>>>>> write-only control. >>>>>>> >>>>>>> >>>>>>> >>>>>>> - >>>>>>> + >>>>>>> >>>>>>> >>>>>> >>>>>>> spanname="id">V4L2_CID_FOCUS_AUTO - >>>>>>> boolean >>>>>>> + enum v4l2_focus_auto_type >>>>>>> >>>>>>> Enables automatic focus >>>>>>> >>>>>>> -adjustments. The effect of manual focus adjustments while this >>>>>>> feature -is enabled is undefined, drivers should ignore such >>>>>>> requests. +adjustments of the normal or macro or >>>>>>> continuous(CAF) mode. The effect of +manual focus adjustments while >>>>>>> this feature is enabled is undefined, +drivers should ignore such >>>>>>> requests. Possible values are: + >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> V4L2_FOCUS_MANUAL >>>>>>> + Manual focus mode. >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> V4L2_FOCUS_AUTO >>>>>>> + Auto focus mode with normal operation. >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> V4L2_FOCUS_MACRO >>>>>>> + Auto focus mode with macro operation. >>>>>>> + >>>>>>> + >>>>>>> + >>>>>>> V4L2_FOCUS_CONTINUOUS >>>>>>> + Auto focus mode with continuous(CAF) >>>>>>> operation. >>>>>> >>>>>> I should have asked this sooner, but what's the difference between >>>>>> normal AF and continuous AF ? >>>>> >>>>> Let's assume that the whole focus process(of course the sensor-internal >>>>> process automatically) is below : 1) pointing the object focussed >>>>> >>>>> : mostly this is possible to be a middle spot, or pre-given orient x >>>>> :& y set from register. >>>>> >>>>> (The mode using given orient x& y, may be defined V4L2_FOCUS_TOUCH >>>>> or >>>>> >>>>> whatever, but I know touch auto focus suggestion is determined nothing >>>>> so far, because of that, after this I will suggest to discuss about it >>>>> one more.) 2) starting and completing the move of the motor to control >>>>> lens, using the focusing internal algorithm 3) check whether the lens >>>>> position is proper or
Re: [RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
2011. 3. 4., 오전 12:22, Laurent Pinchart 작성: > Hi, > > On Thursday 03 March 2011 15:34:36 Kim HeungJun wrote: >> 2011. 3. 3., 오후 10:24, Laurent Pinchart 작성: >>> On Thursday 03 March 2011 14:17:10 Kim HeungJun wrote: >>>> 2011. 3. 3., 오후 7:08, Laurent Pinchart 작성: >>>>> On Thursday 03 March 2011 03:16:34 Kim, HeungJun wrote: >>>>>> Document about the type changes and the enumeration of the auto focus >>>>>> control. >>>>>> >>>>>> Signed-off-by: Heungjun Kim >>>>>> Signed-off-by: Kyungmin Park >>>>>> --- >>>>>> Documentation/DocBook/v4l/controls.xml| 31 >>>>>> +--- Documentation/DocBook/v4l/videodev2.h.xml >>>>>> | 6 + >>>>>> 2 files changed, 33 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/Documentation/DocBook/v4l/controls.xml >>>>>> b/Documentation/DocBook/v4l/controls.xml index 2fae3e8..889fa84 100644 >>>>>> --- a/Documentation/DocBook/v4l/controls.xml >>>>>> +++ b/Documentation/DocBook/v4l/controls.xml >>>>>> @@ -1801,12 +1801,35 @@ negative values towards infinity. This is a >>>>>> write-only control. >>>>>> >>>>>> >>>>>> >>>>>> - >>>>>> + >>>>>> >>>>>> >>>>> >>>>>> spanname="id">V4L2_CID_FOCUS_AUTO - >>>>>> boolean >>>>>> +enum v4l2_focus_auto_type >>>>>> >>>>>>Enables automatic focus >>>>>> >>>>>> -adjustments. The effect of manual focus adjustments while this >>>>>> feature -is enabled is undefined, drivers should ignore such >>>>>> requests. +adjustments of the normal or macro or >>>>>> continuous(CAF) mode. The effect of +manual focus adjustments while >>>>>> this feature is enabled is undefined, +drivers should ignore such >>>>>> requests. Possible values are: + >>>>>> + >>>>>> + >>>>>> + >>>>>> + >>>>>> + >>>>>> V4L2_FOCUS_MANUAL >>>>>> + Manual focus mode. >>>>>> + >>>>>> + >>>>>> + >>>>>> V4L2_FOCUS_AUTO >>>>>> + Auto focus mode with normal operation. >>>>>> + >>>>>> + >>>>>> + >>>>>> V4L2_FOCUS_MACRO >>>>>> + Auto focus mode with macro operation. >>>>>> + >>>>>> + >>>>>> + >>>>>> V4L2_FOCUS_CONTINUOUS >>>>>> + Auto focus mode with continuous(CAF) >>>>>> operation. >>>>> >>>>> I should have asked this sooner, but what's the difference between >>>>> normal AF and continuous AF ? >>>> >>>> Let's assume that the whole focus process(of course the sensor-internal >>>> process automatically) is below : 1) pointing the object focussed >>>> >>>> : mostly this is possible to be a middle spot, or pre-given orient x >>>> : & y set from register. >>>> >>>> (The mode using given orient x & y, may be defined V4L2_FOCUS_TOUCH >>>> or >>>> >>>> whatever, but I know touch auto focus suggestion is determined nothing >>>> so far, because of that, after this I will suggest to discuss about it >>>> one more.) 2) starting and completing the move of the motor to control >>>> lens, using the focusing internal algorithm 3) check whether the lens >>>> position is proper or not, using the focusing internal algorithm, too. >>>> (If the position is not proper, the image may looks defocused) >>>> >>>> In the Normal AF mode, the sensor do the whole focusing process once, >>>> and after completing to move lens, even though the sensor failed >>>> focusing process. On the other hand, the sensor repea
Re: using V4L2_CID_BRIGHTNESS or V4L2_CID_EXPOSURE in the camera
Hi Laurent, 2011. 3. 4., 오전 12:05, Laurent Pinchart 작성: > Hi Kim, probably it's difficult to call my name. Just call me riverful. > > On Thursday 03 March 2011 16:01:24 Kim HeungJun wrote: >> Hello everyone, >> >> I have a question about realization the camera brightness control (or >> exposure, because it's similar effect). I'm confused this similar two >> control - V4L2_CID_BRIGHTNESS and V4L2_CID_EXPOSURE. >> >> These control both express the brightness consequently. >> >> The CID can express the brightness - V4L2_CID_EXPOSURE, is prepared in the >> camera class. And V4L2_CID_BRIGHTNESS seems be possible to use in the >> camera driver, although it is defined in the global(?) class. >> >> So, which CID I can use to express the image's brightness?? > > V4L2_CID_EXPOSURE is used to control the exposure time (which obviously > influences the brightness), and V4L2_CID_BRIGHTNESS to control the brightness > offset (constant value added to all pixels in the image by a processing block > in the digital domain). And I didn't know before, it helps very much for me. :) Thanks, Heungjun Kim -- 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
using V4L2_CID_BRIGHTNESS or V4L2_CID_EXPOSURE in the camera
Hello everyone, I have a question about realization the camera brightness control (or exposure, because it's similar effect). I'm confused this similar two control - V4L2_CID_BRIGHTNESS and V4L2_CID_EXPOSURE. These control both express the brightness consequently. The CID can express the brightness - V4L2_CID_EXPOSURE, is prepared in the camera class. And V4L2_CID_BRIGHTNESS seems be possible to use in the camera driver, although it is defined in the global(?) class. So, which CID I can use to express the image's brightness??-- 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
Re: [RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Hi, 2011. 3. 3., 오후 10:24, Laurent Pinchart 작성: > Hi, > > On Thursday 03 March 2011 14:17:10 Kim HeungJun wrote: >> 2011. 3. 3., 오후 7:08, Laurent Pinchart 작성: >>> On Thursday 03 March 2011 03:16:34 Kim, HeungJun wrote: >>>> Document about the type changes and the enumeration of the auto focus >>>> control. >>>> >>>> Signed-off-by: Heungjun Kim >>>> Signed-off-by: Kyungmin Park >>>> --- >>>> Documentation/DocBook/v4l/controls.xml| 31 >>>> +--- Documentation/DocBook/v4l/videodev2.h.xml | >>>> 6 + >>>> 2 files changed, 33 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/Documentation/DocBook/v4l/controls.xml >>>> b/Documentation/DocBook/v4l/controls.xml index 2fae3e8..889fa84 100644 >>>> --- a/Documentation/DocBook/v4l/controls.xml >>>> +++ b/Documentation/DocBook/v4l/controls.xml >>>> @@ -1801,12 +1801,35 @@ negative values towards infinity. This is a >>>> write-only control. >>>> >>>> >>>> >>>> - >>>> + >>>> >>>>>>> >>>> spanname="id">V4L2_CID_FOCUS_AUTO - >>>> boolean >>>> + enum v4l2_focus_auto_type >>>> >>>> Enables automatic focus >>>> >>>> -adjustments. The effect of manual focus adjustments while this feature >>>> -is enabled is undefined, drivers should ignore such requests. >>>> +adjustments of the normal or macro or continuous(CAF) mode. The effect >>>> of +manual focus adjustments while this feature is enabled is >>>> undefined, +drivers should ignore such requests. Possible values >>>> are: + >>>> + >>>> + >>>> + >>>> + >>>> +V4L2_FOCUS_MANUAL >>>> +Manual focus mode. >>>> + >>>> + >>>> +V4L2_FOCUS_AUTO >>>> +Auto focus mode with normal operation. >>>> + >>>> + >>>> +V4L2_FOCUS_MACRO >>>> +Auto focus mode with macro operation. >>>> + >>>> + >>>> + >>>> V4L2_FOCUS_CONTINUOUS >>>> +Auto focus mode with continuous(CAF) operation. >>> >>> I should have asked this sooner, but what's the difference between normal >>> AF and continuous AF ? >> >> Let's assume that the whole focus process(of course the sensor-internal >> process automatically) is below : 1) pointing the object focussed >> >>: mostly this is possible to be a middle spot, or pre-given orient x & >>: y set from register. >> >>(The mode using given orient x & y, may be defined V4L2_FOCUS_TOUCH or >> whatever, but I know touch auto focus suggestion is determined nothing so >> far, because of that, after this I will suggest to discuss about it one >> more.) 2) starting and completing the move of the motor to control lens, >> using the focusing internal algorithm 3) check whether the lens position >> is proper or not, using the focusing internal algorithm, too. (If the >> position is not proper, the image may looks defocused) >> >> In the Normal AF mode, the sensor do the whole focusing process once, and >> after completing to move lens, even though the sensor failed focusing >> process. On the other hand, the sensor repeats 1~3 in the Continuous AF >> mode periodically, regardless of success of failure. > > OK, that was my understanding as well. How will that work with the proposed > focus menu control ? Don't you need a button control for normal auto-focus ? You mean that the normal auto-focus control type should be a button, right? For now, in our case the user application assumes that such modes(normal, MACRO, CAF, TOUCH or oriented mode, or something) are already ready in the driver. So, I did't need the normal auto-focus is a button type. But, IMHO, the focus control of camera is right to follow the next procedure, 1) choosing the modes as I said upper. (because, the camera dose not have one more focus mode.) 2) adjusting the value of the mode set right before. 3) doing the action of the mode. 1) is the same call the control V4L2_AUTO_FOCUS of menu type. 2), 3) is the same call the control dedicated focus control. Currently, the focus control excepting manual is not needed another control. If touch mode are needed, we can add another enum value, e.g. V4L2_FOCUS_ORIENT. and add another dedicated control, e.g., V4L2_CID_FOCUS_ORIENT_X, V4L2_CID_FOCUS_ORIENT_Y. I think this as I use digital camera. We normally follow such procedure, using the digital camera. If I get your words wrongly, give me some clue :) Thanks, Heungjun Kim -- 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
Re: [RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Hi, 2011. 3. 3., 오후 7:08, Laurent Pinchart 작성: > Hi, > > On Thursday 03 March 2011 03:16:34 Kim, HeungJun wrote: >> Document about the type changes and the enumeration of the auto focus >> control. >> >> Signed-off-by: Heungjun Kim >> Signed-off-by: Kyungmin Park >> --- >> Documentation/DocBook/v4l/controls.xml| 31 >> +--- Documentation/DocBook/v4l/videodev2.h.xml | >> 6 + >> 2 files changed, 33 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/DocBook/v4l/controls.xml >> b/Documentation/DocBook/v4l/controls.xml index 2fae3e8..889fa84 100644 >> --- a/Documentation/DocBook/v4l/controls.xml >> +++ b/Documentation/DocBook/v4l/controls.xml >> @@ -1801,12 +1801,35 @@ negative values towards infinity. This is a >> write-only control. >> >> >> - >> + >> > spanname="id">V4L2_CID_FOCUS_AUTO - >> >> boolean >> +enum v4l2_focus_auto_type >>Enables automatic focus >> -adjustments. The effect of manual focus adjustments while this feature >> -is enabled is undefined, drivers should ignore such requests. >> +adjustments of the normal or macro or continuous(CAF) mode. The effect of >> +manual focus adjustments while this feature is enabled is undefined, >> +drivers should ignore such requests. Possible values are: >> + >> + >> + >> + >> + >> + V4L2_FOCUS_MANUAL >> + Manual focus mode. >> + >> + >> + V4L2_FOCUS_AUTO >> + Auto focus mode with normal operation. >> + >> + >> + V4L2_FOCUS_MACRO >> + Auto focus mode with macro operation. >> + >> + >> + >> V4L2_FOCUS_CONTINUOUS >> + Auto focus mode with continuous(CAF) operation. > > I should have asked this sooner, but what's the difference between normal AF > and continuous AF ? Let's assume that the whole focus process(of course the sensor-internal process automatically) is below : 1) pointing the object focussed : mostly this is possible to be a middle spot, or pre-given orient x & y set from register. (The mode using given orient x & y, may be defined V4L2_FOCUS_TOUCH or whatever, but I know touch auto focus suggestion is determined nothing so far, because of that, after this I will suggest to discuss about it one more.) 2) starting and completing the move of the motor to control lens, using the focusing internal algorithm 3) check whether the lens position is proper or not, using the focusing internal algorithm, too. (If the position is not proper, the image may looks defocused) In the Normal AF mode, the sensor do the whole focusing process once, and after completing to move lens, even though the sensor failed focusing process. On the other hand, the sensor repeats 1~3 in the Continuous AF mode periodically, regardless of success of failure. Regards, Heungjun Kim -- 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
Re: [RFC] snapshot mode, flash capabilities and control
Hi Guennadi, I have another question about capture, not related with exact this topic. Dose the sensor which you use make EXIF information in itself while capturing?? If it is right, how to deliver EXIF information from v4l2(subdev or media driver) to userapplication? Regards, Heungjun Kim 2011-02-24 오후 9:18, Guennadi Liakhovetski 쓴 글: > Agenda. > === > > In a recent RFC [1] I proposed V4L2 API extensions to support fast switching > between multiple capture modes or data formats. However, this is not > sufficient > to efficiently leverage snapshot capabilities of existing hardware - sensors > and > SoCs, and to satisfy user-space needs, a few more functions have to be > implemented. > > Snapshot and strobe / flash capabilities vary significantly between sensors. > Some of them only capture a single image upon trigger activation, some can > capture several images, readout and exposure capabilities vary too. Not all > sensors support a strobe signal, and those, that support it, also offer very > different options to select strobe beginning and duration. This proposal is > trying to select a minimum API, that can be reasonably supported by many > systems and provide a reasonable functionality set to the user. > > Proposed implementation. > > > 1. Switch the interface into the snapshot mode. This is required in addition > to > simply configuring the interface with a different format to activate hardware- > specific support for triggered single image capture. It is proposed to use the > VIDIOC_S_PARM ioctl() with a new V4L2_MODE_SNAPSHOT value for the > struct v4l2_captureparm::capturemode and ::capability fields. Further > hardware-specific details can be passed in ::extendedmode, ::readbuffers can > be > used to specify the exact number of frames to be captured. Similarly, > VIDIOC_G_PARM shall return supported and current capture modes. > > Many sensors provide the ability to trigger snapshot capture either from an > external source or from a control register. Usually, however, there is no > possibility to select the trigger source, either of them can be used at any > time. > > 2. Specify a flash mode. Define new capture capabilities to be used with > struct v4l2_captureparm::capturemode: > > V4L2_MODE_FLASH_SYNC /* synchronise flash with image capture */ > V4L2_MODE_FLASH_ON/* turn on - "torch-mode" */ > V4L2_MODE_FLASH_OFF /* turn off */ > > Obviously, the above synchronous operation does not exactly define beginning > and > duration of the strobe signal. It is proposed to leave the specific flash > timing > configuration to the driver itself and, possibly, to driver-specific extended > mode flags. > > 3. Add a sensor-subdev operation > > int (*snapshot_trigger)(struct v4l2_subdev *sd) > > to start capturing the next frame in the snapshot mode. > > References. > === > > [1] > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/29357 > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- > 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 > -- 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
[RFC PATCH RESEND v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..da4aa7a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Manual Focus",
+ "Normal Auto Focus",
+ "Macro Auto Focus",
+ "Continuous Auto Focus",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO:
+ return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
- case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..959d59e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH RESEND v2 0/3] v4l2-ctrls: add new focus mode
Hello, Agenda == I faced to the absence of the mode of v4l2 focus for a couple of years. While dealing with some few mobile camera sensors, the focus modes are needed more than the current v4l2 focus mode, e.g. a Macro & Continuous mode. The M-5MOLS camera sensor I dealt with, also support these 2 modes. So, I'm going to suggest supports of more detailed v4l2 focus mode. Version == This is second version patch about auto focus mode. The second version changes are below: 1. switch enumeration value between V4L2_FOCUS_AUTO and V4L2_FOCUS_MACRO, for maintaing previous auto focus mode value. 2. add documentations about the changes of auto focus mode. 3. There are a little of changes since the second version submission, but it's not big changes as considering the patch version is up. So, this patch keep the previous version 2. This RFC series of patch adds new auto focus modes, and documents it. The first patch the boolean type of V4L2_CID_FOCUS_AUTO to menu type, and insert menus 4 enumerations: V4L2_FOCUS_MANUAL, V4L2_FOCUS_AUTO, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS The recent mobile camera sensors with ISP supports Macro & Continuous Auto Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact focusing mode of camera sensor. The second patch let the uvc driver using V4L2_CID_FOCUS_AUTO by boolean type, be able to use the type of menu. The third patch documentation about changes of the auto focus mode. Thanks for reading this, and I hope any ideas and any comments. Regards, Heungjun Kim -- 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
[RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Document about the type changes and the enumeration of the auto focus control.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 31 +---
Documentation/DocBook/v4l/videodev2.h.xml |6 +
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..889fa84 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1801,12 +1801,35 @@ negative values towards infinity. This is a write-only
control.
-
+
V4L2_CID_FOCUS_AUTO
- boolean
+ enum v4l2_focus_auto_type
Enables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
-is enabled is undefined, drivers should ignore such requests.
+adjustments of the normal or macro or continuous(CAF) mode. The effect of
+manual focus adjustments while this feature is enabled is undefined,
+drivers should ignore such requests. Possible values are:
+
+
+
+
+
+ V4L2_FOCUS_MANUAL
+ Manual focus mode.
+
+
+ V4L2_FOCUS_AUTO
+ Auto focus mode with normal operation.
+
+
+ V4L2_FOCUS_MACRO
+ Auto focus mode with macro operation.
+
+
+
V4L2_FOCUS_CONTINUOUS
+ Auto focus mode with continuous(CAF) operation.
+
+
+
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..ccf6c2b 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1291,6 +1291,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_exposure_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO, maintaining v4l2 menu
index.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/uvc/uvc_ctrl.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..064827f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 0, "Manual Mode" },
+ { 1, "Auto Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
.size = 1,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .menu_info = focus_auto_controls,
+ .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
1.7.0.4
--
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
Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Laurent,
2011-02-25 오후 9:58, Laurent Pinchart 쓴 글:
> Hi,
>
> On Friday 25 February 2011 13:46:01 Kim, HeungJun wrote:
>> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
>> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/uvc/uvc_ctrl.c |9 -
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
>> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..b98b9f1 100644
>> --- a/drivers/media/video/uvc/uvc_ctrl.c
>> +++ b/drivers/media/video/uvc/uvc_ctrl.c
>> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
>> { { 8, "Aperture Priority Mode" },
>> };
>>
>> +static struct uvc_menu_info focus_auto_controls[] = {
>> +{ 1, "Auto Mode" },
>> +{ 0, "Manual Mode" },
>
> Now that manual focus has value 0 and auto focus value 1, the menu entries
> need to be the other way around.
I don't really get it. My understanding is that your words are structure
uvc_menu_info should be changed as fitted to focus menu type. right?
But, I thinks they don't need to be changed, and I don't find wrong,
I don't know how to fix what you telling me exactly.
So, could you explain more details? Some examples helps to me.
Sorry to bother if you are busy, but it's good for me your advice.
I'll waiting.
Thanks and Regards,
Heungjun Kim
--
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
[RFC PATCH RESEND v2 3/3] v4l2-ctrls: document the changes about auto focus mode
Document about the type changes and the enumeration of the auto focus control.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 31 +---
Documentation/DocBook/v4l/videodev2.h.xml |6 +
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..889fa84 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1801,12 +1801,35 @@ negative values towards infinity. This is a write-only
control.
-
+
V4L2_CID_FOCUS_AUTO
- boolean
+ enum v4l2_focus_auto_type
Enables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
-is enabled is undefined, drivers should ignore such requests.
+adjustments of the normal or macro or continuous(CAF) mode. The effect of
+manual focus adjustments while this feature is enabled is undefined,
+drivers should ignore such requests. Possible values are:
+
+
+
+
+
+ V4L2_FOCUS_MANUAL
+ Manual focus mode.
+
+
+ V4L2_FOCUS_AUTO
+ Auto focus mode with normal operation.
+
+
+ V4L2_FOCUS_MACRO
+ Auto focus mode with macro operation.
+
+
+
V4L2_FOCUS_CONTINUOUS
+ Auto focus mode with continuous(CAF) operation.
+
+
+
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..ccf6c2b 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1291,6 +1291,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_exposure_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/uvc/uvc_ctrl.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..b98b9f1 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 1, "Auto Mode" },
+ { 0, "Manual Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -560,8 +565,10 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
.size = 1,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .menu_info = focus_auto_controls,
+ .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
1.7.0.4
--
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
[RFC PATCH RESEND v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..da4aa7a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Manual Focus",
+ "Normal Auto Focus",
+ "Macro Auto Focus",
+ "Continuous Auto Focus",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO:
+ return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
- case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..959d59e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH RESEND v2 0/3] v4l2-ctrls: add new focus mode
Hello, Agenda == I faced to the absence of the mode of v4l2 focus for a couple of years. While dealing with some few morebile camera sensors, the focus modes are needed more than the current v4l2 focus mode, like a Macro & Continuous mode. The M-5MOLS camera sensor I dealt with, also support these 2 modes. So, I'm going to suggest supports of more detailed v4l2 focus mode. Version == This is second version patch about auto focus mode. The second version changes are below: 1. switch enumeration value between V4L2_FOCUS_AUTO and V4L2_FOCUS_MACRO, for maintaing previous auto focus mode value. 2. add documentations about the changes of auto focus mode. This RFC series of patch adds new auto focus modes, and documents it. The first patch the boolean type of V4L2_CID_FOCUS_AUTO to menu type, and insert menus 4 enumerations: V4L2_FOCUS_MANUAL, V4L2_FOCUS_AUTO, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS The recent mobile camera sensors with ISP supports Macro & Continuous Auto Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact focusing mode of camera sensor. The second patch let the uvc driver using V4L2_CID_FOCUS_AUTO by boolean type, be able to use the type of menu. The third patch documentation about changes of the auto focus mode. Thanks for reading this, and I hope any ideas and any comments. Regards, Heungjun Kim -- 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
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
2011-02-25 오후 7:25, Laurent Pinchart 쓴 글:
> Hi,
>
> On Friday 25 February 2011 11:18:43 Kim, HeungJun wrote:
>> 2011-02-25 오후 6:20, Laurent Pinchart 쓴 글:
>>> On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
>>>> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
>>>> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>>>>
>>>> Signed-off-by: Heungjun Kim
>>>> Signed-off-by: Kyungmin Park
>>>> ---
>>>>
>>>> drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
>>>> 1 files changed, 10 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
>>>> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
>>>> --- a/drivers/media/video/uvc/uvc_ctrl.c
>>>> +++ b/drivers/media/video/uvc/uvc_ctrl.c
>>>> @@ -333,6 +333,11 @@ static struct uvc_menu_info
>>>> exposure_auto_controls[] = { { 8, "Aperture Priority Mode" },
>>>>
>>>> };
>>>>
>>>> +static struct uvc_menu_info focus_auto_controls[] = {
>>>> + { 2, "Auto Mode" },
>>>> + { 1, "Manual Mode" },
>>>
>>> According to the UVC spec, this should be 0 for manual mode and 1 for
>>> auto mode.
>>
>> OK, I'll modify this values depends on below my question..
>>
>>>> +};
>>>> +
>>>>
>>>> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
>>>>
>>>>__u8 query, const __u8 *data)
>>>>
>>>> {
>>>>
>>>> @@ -558,10 +563,12 @@ static struct uvc_control_mapping
>>>> uvc_ctrl_mappings[] = { .name = "Focus, Auto",
>>>>
>>>>.entity = UVC_GUID_UVC_CAMERA,
>>>>.selector = UVC_CT_FOCUS_AUTO_CONTROL,
>>>>
>>>> - .size = 1,
>>>> + .size = 2,
>>>
>>> Why do you change the control size ?
>>>
>>>>.offset = 0,
>>>>
>>>> - .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
>>>> - .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
>>>> + .v4l2_type = V4L2_CTRL_TYPE_MENU,
>>>> + .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
>>>
>>> The UVC control is still a boolean.
>>
>> You're saying that, the control size should be 1 because it's right to
>> maintain the boolean type, So, then, the uvc driver dosen't needed to be
>> changed. is it right?
>
> You still need to change v4l2_type from V4L2_CTRL_TYPE_BOOLEAN to
> V4L2_CTRL_TYPE_MENU, and add the menu entries. I don't see a need to change
> anything else.
>
Ah ok. I I confused a little. Thanks for the good catch.
Together focus name patch, I'll re-send patch.
Regards,
Heungjun Kim
--
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
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
2011-02-25 오후 7:28, Laurent Pinchart 쓴 글:
> On Friday 25 February 2011 10:54:02 Hans Verkuil wrote:
>> On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
>>> On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
>>>> Support more modes of autofocus, it changes the type of
>>>> V4L2_CID_FOCUS_AUTO from boolean to menu. And it includes 4 kinds of
>>>> enumeration types:
>>>>
>>>> V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO,
>>>> V4L2_FOCUS_CONTINUOUS
>>>>
>>>> Signed-off-by: Heungjun Kim
>>>> Signed-off-by: Kyungmin Park
>>>> ---
>>>>
>>>> drivers/media/video/v4l2-ctrls.c | 11 ++-
>>>> include/linux/videodev2.h|6 ++
>>>> 2 files changed, 16 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/media/video/v4l2-ctrls.c
>>>> b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
>>>> --- a/drivers/media/video/v4l2-ctrls.c
>>>> +++ b/drivers/media/video/v4l2-ctrls.c
>>>> @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>>>
>>>>"Aperture Priority Mode",
>>>>NULL
>>>>
>>>>};
>>>>
>>>> + static const char * const camera_focus_auto[] = {
>>>> + "Manual Mode",
>>>> + "Auto Mode",
>>>> + "Macro Mode",
>>>> + "Continuous Mode",
>>>
>>> This might be nit-picking, but maybe the menu entries should be named
>>> "Manual Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus".
>>> Hans ?
>>
>> Yes, that's better. Although I believe that it should be 'Macro Auto
>> Focus', right?
>
> I suppose so. Heungjun could confirm that.
>
>> But if we change this for 'focus' then we need to do the same for the auto
>> exposure menu which currently also uses the term 'Mode'.
>>
>> Do you agree?
>
> Auto Mode and Manual Mode could be renamed to Auto Exposure and Manual
> Exposure, but Shutter Priority Exposure and Aperture Priority Exposure don't
> sound right.
>
I guess the reason why "Shutter Priority Exposure" dosen't always imply auto
iris
exposure, but the current name "Shutter Prority Mode" can be imagined including
auto iris. The contrary case seems the same.
Although tt's the different story, the exposure be made up 3 factor
(shutter speed/aperture/iso), but there is not the enum name matching iso
factor now.
So, it looks better that the name should be changed all later.
But, it looks good for me the focus name is below:
"Manual Focus"
"Normal Auto Focus"
"Macro Auto Focus"
"Continuous Auto Focus"
If any ideas, I'll re-send the patch series.
Regards,
Heungjun Kim
--
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
Re: [RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Hans, and Laurent,
2011-02-25 오후 6:54, Hans Verkuil 쓴 글:
> On Friday, February 25, 2011 10:21:59 Laurent Pinchart wrote:
>> On Friday 25 February 2011 07:21:27 Kim, HeungJun wrote:
>>> Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
>>> from boolean to menu. And it includes 4 kinds of enumeration types:
>>>
>>> V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
>>>
>>> Signed-off-by: Heungjun Kim
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/media/video/v4l2-ctrls.c | 11 ++-
>>> include/linux/videodev2.h|6 ++
>>> 2 files changed, 16 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/media/video/v4l2-ctrls.c
>>> b/drivers/media/video/v4l2-ctrls.c index 2412f08..0b1cce0 100644
>>> --- a/drivers/media/video/v4l2-ctrls.c
>>> +++ b/drivers/media/video/v4l2-ctrls.c
>>> @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>> "Aperture Priority Mode",
>>> NULL
>>> };
>>> + static const char * const camera_focus_auto[] = {
>>> + "Manual Mode",
>>> + "Auto Mode",
>>> + "Macro Mode",
>>> + "Continuous Mode",
>>
>> This might be nit-picking, but maybe the menu entries should be named
>> "Manual
>> Focus", "Auto Focus", "Macro Focus" and "Continuous Auto Focus". Hans ?
>
> Yes, that's better. Although I believe that it should be 'Macro Auto Focus',
> right?
>
> But if we change this for 'focus' then we need to do the same for the auto
> exposure menu which currently also uses the term 'Mode'.
>
> Do you agree?
Although listenning Laurent's opinion first, if my opinion is asked, I agree
using term 'Focus', and agree using term 'Exposure' (is it right??) at the
exposure auto control, too.
If the name is decided, and came to the conclusion, I would modify to maintain
the term 'Focus' in the focus control name.
Regards,
Heungjun Kim
--
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
Re: [RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Laurent,
2011-02-25 오후 6:20, Laurent Pinchart 쓴 글:
> On Friday 25 February 2011 07:21:32 Kim, HeungJun wrote:
>> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
>> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
>> 1 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
>> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..795fd3f 100644
>> --- a/drivers/media/video/uvc/uvc_ctrl.c
>> +++ b/drivers/media/video/uvc/uvc_ctrl.c
>> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
>> { { 8, "Aperture Priority Mode" },
>> };
>>
>> +static struct uvc_menu_info focus_auto_controls[] = {
>> +{ 2, "Auto Mode" },
>> +{ 1, "Manual Mode" },
>
> According to the UVC spec, this should be 0 for manual mode and 1 for auto
> mode.
OK, I'll modify this values depends on below my question..
>
>> +};
>> +
>> static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
>> __u8 query, const __u8 *data)
>> {
>> @@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[]
>> = { .name= "Focus, Auto",
>> .entity = UVC_GUID_UVC_CAMERA,
>> .selector = UVC_CT_FOCUS_AUTO_CONTROL,
>> -.size = 1,
>> +.size = 2,
>
> Why do you change the control size ?
>
>> .offset = 0,
>> -.v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
>> -.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
>> +.v4l2_type = V4L2_CTRL_TYPE_MENU,
>> +.data_type = UVC_CTRL_DATA_TYPE_BITMASK,
>
> The UVC control is still a boolean.
You're saying that, the control size should be 1 because it's right to maintain
the boolean type,
So, then, the uvc driver dosen't needed to be changed. is it right?
Thanks for the reviews, and I'll wait answer.
Regards,
Heungjun KIm
--
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
[RFC PATCH v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..795fd3f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 2, "Auto Mode" },
+ { 1, "Manual Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.name = "Focus, Auto",
.entity = UVC_GUID_UVC_CAMERA,
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
- .size = 1,
+ .size = 2,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
- .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
+ .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
+ .menu_info = focus_auto_controls,
+ .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
1.7.0.4
--
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
[RFC PATCH v2 1/3] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..0b1cce0 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Manual Mode",
+ "Auto Mode",
+ "Macro Mode",
+ "Continuous Mode",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO:
+ return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
- case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..959d59e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH v2 3/3] v4l2-crls: document the changes about auto focus mode
Document about the type changes and the enumeration of the auto focus control.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/v4l/controls.xml| 31 +---
Documentation/DocBook/v4l/videodev2.h.xml |6 +
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..889fa84 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1801,12 +1801,35 @@ negative values towards infinity. This is a write-only
control.
-
+
V4L2_CID_FOCUS_AUTO
- boolean
+ enum v4l2_focus_auto_type
Enables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
-is enabled is undefined, drivers should ignore such requests.
+adjustments of the normal or macro or continuous(CAF) mode. The effect of
+manual focus adjustments while this feature is enabled is undefined,
+drivers should ignore such requests. Possible values are:
+
+
+
+
+
+ V4L2_FOCUS_MANUAL
+ Manual focus mode.
+
+
+ V4L2_FOCUS_AUTO
+ Auto focus mode with normal operation.
+
+
+ V4L2_FOCUS_MACRO
+ Auto focus mode with macro operation.
+
+
+
V4L2_FOCUS_CONTINUOUS
+ Auto focus mode with continuous(CAF) operation.
+
+
+
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..ccf6c2b 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1291,6 +1291,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_exposure_auto_type {
+ V4L2_FOCUS_MANUAL = 0,
+ V4L2_FOCUS_AUTO = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH v2 0/3] v4l2-ctrls: add new focus mode
Hello, Agenda == I faced to the absence of the mode of v4l2 focus for a couple of years. While dealing with some few morebile camera sensors, the focus modes are needed more than the current v4l2 focus mode, like a Macro & Continuous mode. The M-5MOLS camera sensor I dealt with, also support these 2 modes. So, I'm going to suggest supports of more detailed v4l2 focus mode. Version == This is second version patch about auto focus mode. The second version changes are below: 1. switch enumeration value between V4L2_FOCUS_AUTO and V4L2_FOCUS_MACRO, for maintaing previous auto focus mode value. 2. add documentations about the changes of auto focus mode. This RFC series of patch adds new auto focus modes, and documents it. The first patch the boolean type of V4L2_CID_FOCUS_AUTO to menu type, and insert menus 4 enumerations: V4L2_FOCUS_MANUAL, V4L2_FOCUS_AUTO, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS The recent mobile camera sensors with ISP supports Macro & Continuous Auto Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact focusing mode of camera sensor. The second patch let the previous drivers using V4L2_CID_FOCUS_AUTO by boolean type be able to use the type of menu. The third patch documentation about changes of the auto focus mode. Thanks for reading this, and I hope any ideas and any comments. Regards, Heungjun Kim -- 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
Re: [RFC] snapshot mode, flash capabilities and control
Hi Guennadi, I think, it's maybe a good suggestion for current trend! ( I'm not sure this express *trend* is right :)) But, the flash or strobe control connected with sensor can be controlled by user application directly, not in the sensor subdev device. For example, let's think that there is a Flash light application. Its function is just power-up LED. So, in this case, if the flash control mechanism should be used *only* in the V4L2 API belonging through S/G_PARM, this mechanism might be a little complicated, nevertheless it's possible to control led/strobe using S/G_PARM. I mean that we must check the camera must be in the capture state or not, or another setting (like a FPS) should be checked. Namely, for powering up LED, the more procedure is needed. Also, we can think another case. Generally, the LED/STROBE/FLASH is connected with camera sensor directly, but another case can be existed that LED connected with Processor by controlling GPIO. So, In this case, using LED framework look more better I guess, and then user application access LED frame sysfs node eaisly. So, IMHO, probably it's the better option for now to make another CID like V4L2_CID_STROBE clearly, then in the case connected directly with sensor, we control using I2C or another command method for sensor in the V4L2_CID_STROBE, OR in the case connected directly with process, we also using V4L2_CID_STROBE, but the led framework code is in the CID control functions. Actually, because I also think deeply same issue for a long time, so I wanna very talk about this issues. How about dealing with this? Regards, Heungjun Kim 2011. 2. 25., 오전 1:07, Guennadi Liakhovetski 작성: > Hi Hans > > Thanks for the review. Perhaps, I should have mentioned it in the original > post, I've written down this RFC to have a basis for a discussion. The > specific API proposals in it are nothing solid, of course, so, we can > freely discuss it here now, or, maybe we get a chance to discuss it > together with the earlier one, concerning multiple queues, if and when we > meet personally next time;) Concerning your specific comments: > > On Thu, 24 Feb 2011, Hans Verkuil wrote: > >> On Thursday, February 24, 2011 13:18:39 Guennadi Liakhovetski wrote: >>> Agenda. >>> === >>> >>> In a recent RFC [1] I proposed V4L2 API extensions to support fast switching >>> between multiple capture modes or data formats. However, this is not >>> sufficient >>> to efficiently leverage snapshot capabilities of existing hardware - >>> sensors and >>> SoCs, and to satisfy user-space needs, a few more functions have to be >>> implemented. >>> >>> Snapshot and strobe / flash capabilities vary significantly between sensors. >>> Some of them only capture a single image upon trigger activation, some can >>> capture several images, readout and exposure capabilities vary too. Not all >>> sensors support a strobe signal, and those, that support it, also offer very >>> different options to select strobe beginning and duration. This proposal is >>> trying to select a minimum API, that can be reasonably supported by many >>> systems and provide a reasonable functionality set to the user. >>> >>> Proposed implementation. >>> >>> >>> 1. Switch the interface into the snapshot mode. This is required in >>> addition to >>> simply configuring the interface with a different format to activate >>> hardware- >>> specific support for triggered single image capture. It is proposed to use >>> the >>> VIDIOC_S_PARM ioctl() with a new V4L2_MODE_SNAPSHOT value for the >>> struct v4l2_captureparm::capturemode and ::capability fields. Further >>> hardware-specific details can be passed in ::extendedmode, ::readbuffers >>> can be >>> used to specify the exact number of frames to be captured. Similarly, >>> VIDIOC_G_PARM shall return supported and current capture modes. >>> >>> Many sensors provide the ability to trigger snapshot capture either from an >>> external source or from a control register. Usually, however, there is no >>> possibility to select the trigger source, either of them can be used at any >>> time. >> >> I'd rather see a new VIDIOC_G/S_SNAPSHOT ioctl then adding stuff to G/S_PARM. >> Those G/S_PARM ioctls should never have been added to V4L2 in the current >> form. >> >> AFAIK the only usable field is timeperframe, all others are either not used >> at >> all or driver specific. >> >> I am very much in favor of freezing the G/S_PARM ioctls. > > Ic, of course, I knew nothing about this status of G/S_PARM. As it stands, > it seemed a pretty good fit for what I want to do, but, yes, I agree, that > this ioctl() as such is not very pretty, so, sure, we can use a new one. > But first, in principle you agree, that adding this functionality to V4L2 > makes sense instead of relying exclusively on STREAMON / STREAMOFF for > still images? But in fact, streaming vs. snapshot does fit under the same > category as fps setting, IMHO,
Re: [RFC PATCH 0/2] v4l2-ctrls: add new focus mode
Hi Laurent, First, Thanks to reply. I commented below. 2011-02-24 오후 7:49, Laurent Pinchart 쓴 글: > Hi, > > On Thursday 24 February 2011 11:45:13 Kim, HeungJun wrote: >> Hello, >> >> I faced to the absence of the mode of v4l2 focus for a couple of years. >> While dealing with some few morebile camera sensors, the focus modes >> are needed more than the current v4l2 focus mode, like a Macro & >> Continuous mode. The M-5MOLS camera sensor I dealt with, also support >> these 2 modes. So, I'm going to suggest supports of more detailed >> v4l2 focus mode. >> >> This RFC series of patch adds new auto focus modes, and documents it. >> >> The first changes the boolean type of V4L2_CID_FOCUS_AUTO to menu type, >> and insert menus 4 enumerations: >> >> V4L2_FOCUS_AUTO, >> V4L2_FOCUS_MACRO, >> V4L2_FOCUS_MANUAL, >> V4L2_FOCUS_CONTINUOUS >> >> The recent mobile camera sensors with ISP supports Macro & Continuous Auto >> Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. > > I'm curious, what sensor are you referring to ? Yes. The Fujitsu M-5MO LS sensor supports these modes. And, actually NEC CE147 sensor also support Macro Focus mode, not includeing CAF mode. The current Samsung Galaxy S phone use same sensor(M-5MO) too. and these mobile phone's camera suport Macro Focus mode. Regards, Heungjun Kim -- 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
Re: [RFC PATCH 1/2] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
Hi Hans,
Thanks for reviewing, and I'll send another version including Docbook documents.
Regards,
Heungjun Kim
2011-02-24 오후 7:59, Hans Verkuil 쓴 글:
> On Thursday, February 24, 2011 11:45:22 Kim, HeungJun wrote:
>> For support more modes of autofocus, it changes the type of
>> V4L2_CID_FOCUS_AUTO
>> from boolean to menu. And it includes 4 kinds of enumeration types:
>>
>> V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/v4l2-ctrls.c | 11 ++-
>> include/linux/videodev2.h|6 ++
>> 2 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/v4l2-ctrls.c
>> b/drivers/media/video/v4l2-ctrls.c
>> index 2412f08..5c48d49 100644
>> --- a/drivers/media/video/v4l2-ctrls.c
>> +++ b/drivers/media/video/v4l2-ctrls.c
>> @@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>> "Aperture Priority Mode",
>> NULL
>> };
>> +static const char * const camera_focus_auto[] = {
>> +"Auto Mode",
>> +"Manual Mode",
>> +"Macro Mode",
>> +"Continuous Mode",
>> +NULL
>> +};
>> static const char * const colorfx[] = {
>> "None",
>> "Black & White",
>> @@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>> return camera_power_line_frequency;
>> case V4L2_CID_EXPOSURE_AUTO:
>> return camera_exposure_auto;
>> +case V4L2_CID_FOCUS_AUTO:
>> +return camera_focus_auto;
>> case V4L2_CID_COLORFX:
>> return colorfx;
>> case V4L2_CID_TUNE_PREEMPHASIS:
>> @@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
>> v4l2_ctrl_type *type,
>> case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
>> case V4L2_CID_MPEG_VIDEO_PULLDOWN:
>> case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
>> -case V4L2_CID_FOCUS_AUTO:
>> case V4L2_CID_PRIVACY:
>> case V4L2_CID_AUDIO_LIMITER_ENABLED:
>> case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
>> @@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
>> v4l2_ctrl_type *type,
>> case V4L2_CID_MPEG_STREAM_TYPE:
>> case V4L2_CID_MPEG_STREAM_VBI_FMT:
>> case V4L2_CID_EXPOSURE_AUTO:
>> +case V4L2_CID_FOCUS_AUTO:
>> case V4L2_CID_COLORFX:
>> case V4L2_CID_TUNE_PREEMPHASIS:
>> *type = V4L2_CTRL_TYPE_MENU;
>> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>> index 5122b26..dda3e37 100644
>> --- a/include/linux/videodev2.h
>> +++ b/include/linux/videodev2.h
>> @@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
>> #define V4L2_CID_FOCUS_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+10)
>> #define V4L2_CID_FOCUS_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+11)
>> #define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12)
>> +enum v4l2_focus_auto_type {
>> +V4L2_FOCUS_AUTO = 0,
>> +V4L2_FOCUS_MANUAL = 1,
>
> Currently this is a boolean, so 0 means manual and 1 means auto. Let's keep
> that order. So FOCUS_AUTO should be 1 and FOCUS_MANUAL should be 0.
>
> The documentation of this control must also be updated in the V4L2 DocBook.
>
> Regards,
>
> Hans
>
>> +V4L2_FOCUS_MACRO = 2,
>> +V4L2_FOCUS_CONTINUOUS = 3
>> +};
>>
>> #define V4L2_CID_ZOOM_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>> #define V4L2_CID_ZOOM_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>>
>
--
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
[RFC PATCH 2/2] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
The place using V4L2_CID_FOCUS_AUTO is one, in only this uvc driver here.
So, only this driver affects the changes of V4L2_CID_FOCUS_AUTO type changes.
---
drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..795fd3f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 2, "Auto Mode" },
+ { 1, "Manual Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.name = "Focus, Auto",
.entity = UVC_GUID_UVC_CAMERA,
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
- .size = 1,
+ .size = 2,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
- .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
+ .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
+ .menu_info = focus_auto_controls,
+ .menu_count = ARRAY_SIZE(focus_auto_controls),
},
{
.id = V4L2_CID_IRIS_ABSOLUTE,
--
1.7.0.4
--
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
[RFC PATCH 2/2] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
The place using V4L2_CID_FOCUS_AUTO is one, in only this uvc driver here.
So, only this driver affects the changes of V4L2_CID_FOCUS_AUTO type changes.
---
drivers/media/video/uvc/uvc_ctrl.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index 59f8a9a..795fd3f 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] = {
{ 8, "Aperture Priority Mode" },
};
+static struct uvc_menu_info focus_auto_controls[] = {
+ { 2, "Auto Mode" },
+ { 1, "Manual Mode" },
+};
+
static __s32 uvc_ctrl_get_zoom(struct uvc_control_mapping *mapping,
__u8 query, const __u8 *data)
{
@@ -558,10 +563,12 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.name = "Focus, Auto",
.entity = UVC_GUID_UVC_CAMERA,
.selector = UVC_CT_FOCUS_AUTO_CONTROL,
- .size = 1,
+ .size = 2,
.offset = 0,
- .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
- .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ .v4l2_type = V4L2_CTRL_TYPE_MENU,
+ .data_type = UVC_CTRL_DATA_TYPE_BITMASK,
+ .menu_info = focus_auto_
--
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
[RFC PATCH 1/2] v4l2-ctrls: change the boolean type of V4L2_CID_FOCUS_AUTO to menu type
For support more modes of autofocus, it changes the type of V4L2_CID_FOCUS_AUTO
from boolean to menu. And it includes 4 kinds of enumeration types:
V4L2_FOCUS_AUTO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_MACRO, V4L2_FOCUS_CONTINUOUS
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 11 ++-
include/linux/videodev2.h|6 ++
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..5c48d49 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_focus_auto[] = {
+ "Auto Mode",
+ "Manual Mode",
+ "Macro Mode",
+ "Continuous Mode",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +259,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_FOCUS_AUTO:
+ return camera_focus_auto;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -416,7 +425,6 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_GOP_CLOSURE:
case V4L2_CID_MPEG_VIDEO_PULLDOWN:
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
- case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
case V4L2_CID_AUDIO_LIMITER_ENABLED:
case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
@@ -450,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+ case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5122b26..dda3e37 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,12 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FOCUS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+10)
#define V4L2_CID_FOCUS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+11)
#define V4L2_CID_FOCUS_AUTO(V4L2_CID_CAMERA_CLASS_BASE+12)
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_AUTO = 0,
+ V4L2_FOCUS_MANUAL = 1,
+ V4L2_FOCUS_MACRO = 2,
+ V4L2_FOCUS_CONTINUOUS = 3
+};
#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
--
1.7.0.4
--
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
[RFC PATCH 0/2] v4l2-ctrls: add new focus mode
Hello, I faced to the absence of the mode of v4l2 focus for a couple of years. While dealing with some few morebile camera sensors, the focus modes are needed more than the current v4l2 focus mode, like a Macro & Continuous mode. The M-5MOLS camera sensor I dealt with, also support these 2 modes. So, I'm going to suggest supports of more detailed v4l2 focus mode. This RFC series of patch adds new auto focus modes, and documents it. The first changes the boolean type of V4L2_CID_FOCUS_AUTO to menu type, and insert menus 4 enumerations: V4L2_FOCUS_AUTO, V4L2_FOCUS_MACRO, V4L2_FOCUS_MANUAL, V4L2_FOCUS_CONTINUOUS The recent mobile camera sensors with ISP supports Macro & Continuous Auto Focus aka CAF mode, of course normal AUTO mode, even Continuous mode. Changing the type of V4L2_CID_FOCUS_MODE, is able to define more exact focusing mode of camera sensor. The second changes let the previous drivers using V4L2_CID_FOCUS_AUTO by boolean type be able to use the type of menu. Thanks for reading this, and I hope any ideas and any comments. Regards, Heungjun Kim -- 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
Re: [PATCH v5] Add support for M5MO-LS 8 Mega Pixel camera
Hello, I hope this patch. I missed 1 file, sorry. I would submit another patch as the same name and same version. Thanks, Heungjun Kim 2011-02-23 오후 9:08, Kim, HeungJun 쓴 글: > Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated > image signal processor. > > Signed-off-by: Heungjun Kim > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > > --- > > Hello, > > This is fifth version of M-5MOLS 8 Mega Pixel camera sensor. > > The fifth version changes are below: > 1. remove dynmic regulator consumer name array > 2. rename M5MOLS to M-5MOLS in the comments. M-5MOLS is original name. > 3. remove unused type and register address definition > 4. fix some typos. > > The fourth version changes are below: > 1. combine splitted i2c_transfer functions to single I2C operation > 2. remove unneeded checking for control values > 3. fix some typos and code clean > > The third version changes are below: > 1. the method to writing register accordint to state value > 2. changing mdelay to usleep_range because of not hogging > > The second versions changes are below: > 1. remove I2C function macro, and use static inline for type-safe. > 2. use the v4l2 control framework documented at v4l2-control.txt. > 3. Add regulator enable/disable functions > 4. fix any coding problems > > The first version patch is here: > http://www.spinics.net/lists/linux-media/msg26246.html > > This driver is tested on s5pc210 board using s5p-fimc driver. > > Thanks for any ideas. > > Regards, > Heungjun Kim > Samsung Electronics DMC R&D Center > --- > drivers/media/video/Kconfig |2 + > drivers/media/video/Makefile |1 + > drivers/media/video/m5mols/Kconfig |6 + > drivers/media/video/m5mols/Makefile |3 + > drivers/media/video/m5mols/m5mols.h | 200 ++ > drivers/media/video/m5mols/m5mols_controls.c | 163 + > drivers/media/video/m5mols/m5mols_core.c | 882 > ++ > drivers/media/video/m5mols/m5mols_reg.h | 103 +++ > include/media/m5mols.h |2 + > 9 files changed, 1362 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/m5mols/Kconfig > create mode 100644 drivers/media/video/m5mols/Makefile > create mode 100644 drivers/media/video/m5mols/m5mols.h > create mode 100644 drivers/media/video/m5mols/m5mols_controls.c > create mode 100644 drivers/media/video/m5mols/m5mols_core.c > create mode 100644 drivers/media/video/m5mols/m5mols_reg.h > create mode 100644 include/media/m5mols.h > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index d40a8fc..6a03aad 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -746,6 +746,8 @@ config VIDEO_NOON010PC30 > ---help--- > This driver supports NOON010PC30 CIF camera from Siliconfile > > +source "drivers/media/video/m5mols/Kconfig" > + > config SOC_CAMERA > tristate "SoC camera support" > depends on VIDEO_V4L2 && HAS_DMA && I2C > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 251b7ca..adb9361 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o > obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o > obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o > obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o > +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ > > obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o > obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o > diff --git a/drivers/media/video/m5mols/Kconfig > b/drivers/media/video/m5mols/Kconfig > new file mode 100644 > index 000..a4ac129 > --- /dev/null > +++ b/drivers/media/video/m5mols/Kconfig > @@ -0,0 +1,6 @@ > +config VIDEO_M5MOLS > + tristate "Fujitsu M-5MOLS 8MP sensor support" > + depends on I2C && VIDEO_V4L2 > + ---help--- > + This driver supports Fujitsu M-5MOLS camera sensor with ISP > + > diff --git a/drivers/media/video/m5mols/Makefile > b/drivers/media/video/m5mols/Makefile > new file mode 100644 > index 000..b5d19bf > --- /dev/null > +++ b/drivers/media/video/m5mols/Makefile > @@ -0,0 +1,3 @@ > +m5mols-objs := m5mols_core.o m5mols_controls.o > + > +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o > diff --git a/drivers/media/video/m5mols/m5mols.h > b/drivers/media/video/m5mols/m5mols.h > new file mode 100644 > index 000..28ffd35 > --- /dev/null > +++ b/drivers/media/video/m5mol
[PATCH v5] Add support for M-5MOLS 8 Mega Pixel camera
Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated image signal processor. Signed-off-by: Heungjun Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Hello, This is fifth version of M-5MOLS 8 Mega Pixel camera sensor. I missed one file at the just previous version fifth patch. I hope the previous one ignored, and I re-send the patch adding the missing file. And this patch would maintain as the same name, version and contents. Sorry to make coufusing. The fifth version changes are below: 1. remove dynmic regulator consumer name array 2. rename M5MOLS to M-5MOLS in the comments. M-5MOLS is original name. 3. remove unused type and register address definition 4. fix some typos. The fourth version changes are below: 1. combine splitted i2c_transfer functions to single I2C operation 2. remove unneeded checking for control values 3. fix some typos and code clean The third version changes are below: 1. the method to writing register accordint to state value 2. changing mdelay to usleep_range because of not hogging The second versions changes are below: 1. remove I2C function macro, and use static inline for type-safe. 2. use the v4l2 control framework documented at v4l2-control.txt. 3. Add regulator enable/disable functions 4. fix any coding problems The first version patch is here: http://www.spinics.net/lists/linux-media/msg26246.html This driver is tested on s5pc210 board using s5p-fimc driver. Thanks for any ideas. Regards, Heungjun Kim Samsung Electronics DMC R&D Center --- drivers/media/video/Kconfig |2 + drivers/media/video/Makefile |1 + drivers/media/video/m5mols/Kconfig |6 + drivers/media/video/m5mols/Makefile |3 + drivers/media/video/m5mols/m5mols.h | 200 ++ drivers/media/video/m5mols/m5mols_controls.c | 163 + drivers/media/video/m5mols/m5mols_core.c | 882 ++ drivers/media/video/m5mols/m5mols_reg.h | 103 +++ include/media/m5mols.h | 33 + 9 files changed, 1393 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/m5mols/Kconfig create mode 100644 drivers/media/video/m5mols/Makefile create mode 100644 drivers/media/video/m5mols/m5mols.h create mode 100644 drivers/media/video/m5mols/m5mols_controls.c create mode 100644 drivers/media/video/m5mols/m5mols_core.c create mode 100644 drivers/media/video/m5mols/m5mols_reg.h create mode 100644 include/media/m5mols.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index d40a8fc..6a03aad 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -746,6 +746,8 @@ config VIDEO_NOON010PC30 ---help--- This driver supports NOON010PC30 CIF camera from Siliconfile +source "drivers/media/video/m5mols/Kconfig" + config SOC_CAMERA tristate "SoC camera support" depends on VIDEO_V4L2 && HAS_DMA && I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 251b7ca..adb9361 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o diff --git a/drivers/media/video/m5mols/Kconfig b/drivers/media/video/m5mols/Kconfig new file mode 100644 index 000..a4ac129 --- /dev/null +++ b/drivers/media/video/m5mols/Kconfig @@ -0,0 +1,6 @@ +config VIDEO_M5MOLS + tristate "Fujitsu M-5MOLS 8MP sensor support" + depends on I2C && VIDEO_V4L2 + ---help--- + This driver supports Fujitsu M-5MOLS camera sensor with ISP + diff --git a/drivers/media/video/m5mols/Makefile b/drivers/media/video/m5mols/Makefile new file mode 100644 index 000..b5d19bf --- /dev/null +++ b/drivers/media/video/m5mols/Makefile @@ -0,0 +1,3 @@ +m5mols-objs:= m5mols_core.o m5mols_controls.o + +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o diff --git a/drivers/media/video/m5mols/m5mols.h b/drivers/media/video/m5mols/m5mols.h new file mode 100644 index 000..28ffd35 --- /dev/null +++ b/drivers/media/video/m5mols/m5mols.h @@ -0,0 +1,200 @@ +/* + * Driver internal Header for M-5MOLS 8M Pixel camera sensor with ISP + * + * Copyright (C) 2011 Samsung Electronics Co., Ltd + * Author: HeungJun Kim, riverful@samsung.com + * + * Copyright (C) 2009 Samsung Electronics Co., Ltd + * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your opti
[PATCH v5] Add support for M5MO-LS 8 Mega Pixel camera
Add I2C/V4L2 subdev driver for M-5MOLS camera sensor with integrated
image signal processor.
Signed-off-by: Heungjun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Hello,
This is fifth version of M-5MOLS 8 Mega Pixel camera sensor.
The fifth version changes are below:
1. remove dynmic regulator consumer name array
2. rename M5MOLS to M-5MOLS in the comments. M-5MOLS is original name.
3. remove unused type and register address definition
4. fix some typos.
The fourth version changes are below:
1. combine splitted i2c_transfer functions to single I2C operation
2. remove unneeded checking for control values
3. fix some typos and code clean
The third version changes are below:
1. the method to writing register accordint to state value
2. changing mdelay to usleep_range because of not hogging
The second versions changes are below:
1. remove I2C function macro, and use static inline for type-safe.
2. use the v4l2 control framework documented at v4l2-control.txt.
3. Add regulator enable/disable functions
4. fix any coding problems
The first version patch is here:
http://www.spinics.net/lists/linux-media/msg26246.html
This driver is tested on s5pc210 board using s5p-fimc driver.
Thanks for any ideas.
Regards,
Heungjun Kim
Samsung Electronics DMC R&D Center
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols/Kconfig |6 +
drivers/media/video/m5mols/Makefile |3 +
drivers/media/video/m5mols/m5mols.h | 200 ++
drivers/media/video/m5mols/m5mols_controls.c | 163 +
drivers/media/video/m5mols/m5mols_core.c | 882 ++
drivers/media/video/m5mols/m5mols_reg.h | 103 +++
include/media/m5mols.h |2 +
9 files changed, 1362 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols/Kconfig
create mode 100644 drivers/media/video/m5mols/Makefile
create mode 100644 drivers/media/video/m5mols/m5mols.h
create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
create mode 100644 drivers/media/video/m5mols/m5mols_core.c
create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
create mode 100644 include/media/m5mols.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d40a8fc..6a03aad 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,8 @@ config VIDEO_NOON010PC30
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
+source "drivers/media/video/m5mols/Kconfig"
+
config SOC_CAMERA
tristate "SoC camera support"
depends on VIDEO_V4L2 && HAS_DMA && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 251b7ca..adb9361 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols/Kconfig
b/drivers/media/video/m5mols/Kconfig
new file mode 100644
index 000..a4ac129
--- /dev/null
+++ b/drivers/media/video/m5mols/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_M5MOLS
+ tristate "Fujitsu M-5MOLS 8MP sensor support"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This driver supports Fujitsu M-5MOLS camera sensor with ISP
+
diff --git a/drivers/media/video/m5mols/Makefile
b/drivers/media/video/m5mols/Makefile
new file mode 100644
index 000..b5d19bf
--- /dev/null
+++ b/drivers/media/video/m5mols/Makefile
@@ -0,0 +1,3 @@
+m5mols-objs:= m5mols_core.o m5mols_controls.o
+
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
new file mode 100644
index 000..28ffd35
--- /dev/null
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -0,0 +1,200 @@
+/*
+ * Driver internal Header for M-5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef M5MOLS_H
+#define M5MOLS_H
+
+#include
+#include "m5mols_reg.h"
+
+#define v4l2msg(fmt, arg...) do {\
+ v4l2_dbg(1, m5mols_debug, &info->sd, fmt, ## arg); \
+
Re: [PATCH v4] Add support for M5MO-LS 8 Mega Pixel camera
I've checked runnig checkpatch.pl, but I've not seen this message before. And I re-check the patch sent now, but it's not. Probably, It's issue between git send-email and our mail server setting. I'll check once again, and resend. Thanks let me know. Regards Heungjun Kim 2011-02-08 오전 6:45, Sylwester Nawrocki 쓴 글: > Hi HeungJun, > > On 02/07/2011 12:44 PM, Heungjun Kim wrote: >> Add I2C/V4L2 subdev driver for M5MO-LS camera sensor with integrated >> image processor. >> > > There is something wrong with this patch. It looks like it got mangled by > the mailer. I can see some Korean characters in it and checkpatch.pl > returns errors: > > ERROR: patch seems to be corrupt (line wrapped?) > #122: FILE: drivers/media/video/Kconfig:747: > =20 > > ERROR: spaces required around that '=' (ctx:WxV) > #208: FILE: drivers/media/video/m5mols/m5mols.h:36: > + I2C_8BIT=3D 1, > ^ > > ERROR: spaces required around that '=' (ctx:WxV) > #209: FILE: drivers/media/video/m5mols/m5mols.h:37: > + I2C_16BIT =3D 2, > ^ > > ERROR: spaces required around that '=' (ctx:WxV) > #210: FILE: drivers/media/video/m5mols/m5mols.h:38: > + I2C_32BIT =3D 4, > ^ > ... > > ERROR: spaces required around that '=' (ctx:WxV) > #1500: FILE: drivers/media/video/m5mols/m5mols_core.c:892: > + .remove =3D m5mols_remove, > ^ > > ERROR: spaces required around that '=' (ctx:WxV) > #1501: FILE: drivers/media/video/m5mols/m5mols_core.c:893: > + .id_table =3D m5mols_id, > ^ > > WARNING: please, no space before tabs > #1672: FILE: include/media/m5mols.h:23: > +* ^I^Ito be called after enabling and before disabling$ > > total: 344 errors, 6 warnings, 1514 lines checked > > > Regards, > Sylwester > -- 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
Re: [PATCH v3] Add support for M5MO-LS 8 Mega Pixel camera
I would fix this things and resend as soon as possible. As I say once again, thanks to review it :) Regards, HeungJun Kim 2011. 2. 3., 오후 4:49, Hans Verkuil 작성: > Just some small points... > > On Tuesday, January 25, 2011 07:33:58 Heungjun Kim wrote: >> Add I2C/V4L2 subdev driver for M5MO-LS camera sensor with integrated >> image processor. >> >> Signed-off-by: Heungjun Kim >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> >> --- >> >> Hello, >> >> This is third version of M5MOLS 8 Mega Pixel camera sensor. >> >> The first version patch is here: >> http://www.spinics.net/lists/linux-media/msg26246.html >> >> The second versions changes are below: >> 1. remove I2C function macro, and use static inline for type-safe. >> 2. use the v4l2 control framework documented at v4l2-control.txt. >> 3. Add regulator enable/disable functions >> 4. fix any coding problems >> >> The third version changes are below: >> 1. the method to writing register accordint to state value >> 2. changing mdelay to usleep_range because of not hogging >> >> This driver is tested on s5pc210 board using s5p-fimc driver. >> >> Thanks for any ideas. >> >> Regards, >> Heungjun Kim >> Samsung Electronics DMC R&D Center >> --- >> drivers/media/video/Kconfig |2 + >> drivers/media/video/Makefile |1 + >> drivers/media/video/m5mols/Kconfig |6 + >> drivers/media/video/m5mols/Makefile |3 + >> drivers/media/video/m5mols/m5mols.h | 261 >> drivers/media/video/m5mols/m5mols_controls.c | 173 + >> drivers/media/video/m5mols/m5mols_core.c | 898 >> ++ >> drivers/media/video/m5mols/m5mols_reg.h | 103 +++ >> include/media/m5mols.h | 31 + >> 9 files changed, 1478 insertions(+), 0 deletions(-) >> create mode 100644 drivers/media/video/m5mols/Kconfig >> create mode 100644 drivers/media/video/m5mols/Makefile >> create mode 100644 drivers/media/video/m5mols/m5mols.h >> create mode 100644 drivers/media/video/m5mols/m5mols_controls.c >> create mode 100644 drivers/media/video/m5mols/m5mols_core.c >> create mode 100644 drivers/media/video/m5mols/m5mols_reg.h >> create mode 100644 include/media/m5mols.h >> >> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig >> index d40a8fc..6a03aad 100644 >> --- a/drivers/media/video/Kconfig >> +++ b/drivers/media/video/Kconfig >> @@ -746,6 +746,8 @@ config VIDEO_NOON010PC30 >> ---help--- >>This driver supports NOON010PC30 CIF camera from Siliconfile >> >> +source "drivers/media/video/m5mols/Kconfig" >> + >> config SOC_CAMERA >> tristate "SoC camera support" >> depends on VIDEO_V4L2 && HAS_DMA && I2C >> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile >> index 251b7ca..adb9361 100644 >> --- a/drivers/media/video/Makefile >> +++ b/drivers/media/video/Makefile >> @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o >> obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o >> obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o >> obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o >> +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ >> >> obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o >> obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o >> diff --git a/drivers/media/video/m5mols/Kconfig >> b/drivers/media/video/m5mols/Kconfig >> new file mode 100644 >> index 000..387425b >> --- /dev/null >> +++ b/drivers/media/video/m5mols/Kconfig >> @@ -0,0 +1,6 @@ >> +config VIDEO_M5MOLS >> +tristate "Fujitsu M5MO-LS 8MP sensor support" >> +depends on I2C && VIDEO_V4L2 >> +---help--- >> + This driver supports Fujitsu M5MO-LS camera sensor with ISP >> + >> diff --git a/drivers/media/video/m5mols/Makefile >> b/drivers/media/video/m5mols/Makefile >> new file mode 100644 >> index 000..b5d19bf >> --- /dev/null >> +++ b/drivers/media/video/m5mols/Makefile >> @@ -0,0 +1,3 @@ >> +m5mols-objs := m5mols_core.o m5mols_controls.o >> + >> +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o >> diff --git a/drivers/media/video/m5mols/m5mols.h >> b/drivers/media/video/m5mols/m5mols.h >> new file mode 100644 >> index 000..320c976 >> --- /dev/null >> +++ b/drivers/media/video/m5mols/m5mols.h >> @@ -0,0 +1,261 @@ >> +/* >> + * Header for M5MOLS 8M Pixel camera sensor with ISP >> + * >> + * Copyright (C) 2011 Samsung Electronics Co., Ltd >> + * Author: HeungJun Kim, riverful@samsung.com >> + * >> + * Copyright (C) 2009 Samsung Electronics Co., Ltd >> + * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License as published by >> + * the Free Software Foundation; either version 2 of the License, or >> + * (at your option) any later version. >> + */ >> + >> +#ifndef M5MOLS_H >> +#define M5MOLS_H >> + >> +#include >> +#include "m5mols_reg.
Re: [PATCH v2] Add support for M5MO-LS 8 Mega Pixel camera
Hi Sylwester, Oh. Very thanks to reviewing. It's almost not a big deal to change and I'll fix this and resend. 2011. 1. 23., 오후 1:16, Sylwester Nawrocki 작성: > HeungJun, > > as I didn't really get a chance to review this patch in its current > form before, please let me now add some further comments. > > On 01/22/2011 11:12 AM, Kim, HeungJun wrote: >> Hello, >> >> This is second patch of I2C/V4L2 subdev driver for M5MOLS 8 Mega Pixel camera >> sensor using MIPI interface. >> >> The first version patch is here: >> http://www.spinics.net/lists/linux-media/msg26246.html >> >> And the first verion's issues was corrected referencing with quick reviews of >> Hans Verkuil and Sylwester Nawrocki. >> >> The main issues is below: >> 1. remove I2C function macro, and use static inline for type-safe. >> 2. use the v4l2 control framework documented at v4l2-control.txt. >> 3. Add regulator enable/disable functions >> 4. fix any coding problems >> >> The driver supports currently that: >> 1. Preview enables on each resolution and format code >> V4L2_MBUS_FMT_VYUY8_2X8. >> 2. The 5 kind of control was working well. >> >> This driver is tested on s5pc210 board using s5p-fimc driver. >> >> Thanks to any ideas. >> >> Regrads, >> Heungjun Kim >> >> Signed-off-by: Heungjun Kim >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> drivers/media/video/Kconfig |2 + >> drivers/media/video/Makefile |1 + >> drivers/media/video/m5mols/Kconfig |6 + >> drivers/media/video/m5mols/Makefile |3 + >> drivers/media/video/m5mols/m5mols.h | 257 >> drivers/media/video/m5mols/m5mols_controls.c | 173 + >> drivers/media/video/m5mols/m5mols_core.c | 898 >> ++ >> drivers/media/video/m5mols/m5mols_reg.h | 103 +++ >> 8 files changed, 1443 insertions(+), 0 deletions(-) >> create mode 100644 drivers/media/video/m5mols/Kconfig >> create mode 100644 drivers/media/video/m5mols/Makefile >> create mode 100644 drivers/media/video/m5mols/m5mols.h >> create mode 100644 drivers/media/video/m5mols/m5mols_controls.c >> create mode 100644 drivers/media/video/m5mols/m5mols_core.c >> create mode 100644 drivers/media/video/m5mols/m5mols_reg.h >> >> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig >> index ce3555a..fd3130a 100644 >> --- a/drivers/media/video/Kconfig >> +++ b/drivers/media/video/Kconfig >> @@ -746,6 +746,8 @@ config VIDEO_NOON010PC30 >> ---help--- >>This driver supports NOON010PC30 CIF camera from Siliconfile >> >> +source "drivers/media/video/m5mols/Kconfig" >> + >> config SOC_CAMERA >> tristate "SoC camera support" >> depends on VIDEO_V4L2&& HAS_DMA&& I2C >> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile >> index 251b7ca..adb9361 100644 >> --- a/drivers/media/video/Makefile >> +++ b/drivers/media/video/Makefile >> @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o >> obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o >> obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o >> obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o >> +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ >> >> obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o >> obj-$(CONFIG_SOC_CAMERA_MT9M001)+= mt9m001.o >> diff --git a/drivers/media/video/m5mols/Kconfig >> b/drivers/media/video/m5mols/Kconfig >> new file mode 100644 >> index 000..387425b >> --- /dev/null >> +++ b/drivers/media/video/m5mols/Kconfig >> @@ -0,0 +1,6 @@ >> +config VIDEO_M5MOLS >> +tristate "Fujitsu M5MO-LS 8MP sensor support" >> +depends on I2C&& VIDEO_V4L2 >> +---help--- >> + This driver supports Fujitsu M5MO-LS camera sensor with ISP >> + >> diff --git a/drivers/media/video/m5mols/Makefile >> b/drivers/media/video/m5mols/Makefile >> new file mode 100644 >> index 000..b5d19bf >> --- /dev/null >> +++ b/drivers/media/video/m5mols/Makefile >> @@ -0,0 +1,3 @@ >> +m5mols-objs := m5mols_core.o m5mols_controls.o >> + >> +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o >> diff --git a/drivers/media/video/m5mols/m5mols.h >> b/drivers/media/video/m5mols/m5mols.h >> new file mode 100644 >> index 000..eaeb7ca >> --- /
Re: [RFC PATCH 3/3] v4l2-ctrls: update control framework documentation
Hi Sylwester, It's my humble opinions. Just read plz :) 2011. 1. 23., 오후 8:08, Sylwester Nawrocki 작성: [snip] >> +Handling autogain/gain-type Controls with Auto Clusters >> +=== >> + >> +A common type of control cluster is one that handles 'auto-foo/foo'-type >> +controls. Typical examples are autogain/gain, autoexposure/exposure, >> +autowhitebalance/red balance/blue balance. In all cases you have one >> controls >> +that determines whether another control is handled automatically by the >> hardware, >> +or whether it is under manual control from the user. >> + >> +The way these are supposed to be handled is that if you set one of the 'foo' >> +controls, then the 'auto-foo' control should automatically switch to manual >> +mode, except when you set the 'auto-foo' control at the same time, in which > > Do "set the 'auto-foo' control at the same time" refer to what is done in > a driver? I can't see how this statement could apply to userland. If you are talking about how platform or user application can call CID twice in such specific case, as you already know, yes, it happened. Actually, I have been faced the same difficulty with platform and user application peoples. But, for now, this new control framework seems to be easy handling the driver actions. When the user controls the devices, the user application wants to call only one CID. For example, when the user exposures camera device manually, they want to call only V4L2_CID_EXPOSURE, not call additionally V4L2_CID_EXPOSURE_AUTO setting the enumeration by V4L2_EXPOSURE_MANUAL. IMHO, the ultimate reason seems that V4L2_CID_EXPOSURE is only responsible to handle Manual Exposure, but the V4L2_CID_EXPOSURE_AUTO can influence Auto and Manual case. The all CID having AUTO feature is likely to be the same case. But, as I know, the previous driver using this CID having AUTO feature still exist now, and it is very difficult to change the current control logic to handle devices. The birth of new v4l2_ctrl framework seems to be the better options I think, and I'm very happy for that because it's ok not to be worry about how to set the internal variables for matching the control sequence with platform and user any more. -- 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
Re: [RFC PATCH 03/12] mt9m001: convert to the control framework.
Hello,
I'm reading threads about the new v4l2_ctrl framework and If you don't mind
I gotta tell you my humble opinion about testing result the new v4l2_ctrl
framework subdev.
I have actually similar curcumstance, with I2C subdev M5MOLS Fujitsu device
which is just send the patch and S5PC210 board for testing this, except not
using soc_camera framework.
But, it's maybe helpful to discuss about this changes to everyone.
2011. 1. 23., 오전 6:21, Guennadi Liakhovetski 작성:
> On Wed, 12 Jan 2011, Hans Verkuil wrote:
>
>> Signed-off-by: Hans Verkuil
[snip]
>> -case V4L2_CID_EXPOSURE:
>> -/* mt9m001 has maximum == default */
>> -if (ctrl->value > qctrl->maximum || ctrl->value <
>> qctrl->minimum)
>> -return -EINVAL;
>> -else {
>> -unsigned long range = qctrl->maximum - qctrl->minimum;
>> -unsigned long shutter = ((ctrl->value - qctrl->minimum)
>> * 1048 +
>> +case V4L2_CID_EXPOSURE_AUTO:
>> +/* Force manual exposure if only the exposure was changed */
>> +if (!ctrl->has_new)
>> +ctrl->val = V4L2_EXPOSURE_MANUAL;
>> +if (ctrl->val == V4L2_EXPOSURE_MANUAL) {
>> +unsigned long range = exp->maximum - exp->minimum;
>> +unsigned long shutter = ((exp->val - exp->minimum) *
>> 1048 +
>> range / 2) / range + 1;
>>
>> dev_dbg(&client->dev,
>> "Setting shutter width from %d to %lu\n",
>> -reg_read(client, MT9M001_SHUTTER_WIDTH),
>> -shutter);
>> +reg_read(client, MT9M001_SHUTTER_WIDTH),
>> shutter);
>> if (reg_write(client, MT9M001_SHUTTER_WIDTH, shutter) <
>> 0)
>> return -EIO;
>> -mt9m001->exposure = ctrl->value;
>> -mt9m001->autoexposure = 0;
>> -}
>> -break;
>> -case V4L2_CID_EXPOSURE_AUTO:
>> -if (ctrl->value) {
>> +} else {
>> const u16 vblank = 25;
>> unsigned int total_h = mt9m001->rect.height +
>> mt9m001->y_skip_top + vblank;
>> -if (reg_write(client, MT9M001_SHUTTER_WIDTH,
>> - total_h) < 0)
>> +
>> +if (reg_write(client, MT9M001_SHUTTER_WIDTH, total_h) <
>> 0)
>> return -EIO;
>> -qctrl = soc_camera_find_qctrl(icd->ops,
>> V4L2_CID_EXPOSURE);
>> -mt9m001->exposure = (524 + (total_h - 1) *
>> - (qctrl->maximum - qctrl->minimum)) /
>> -1048 + qctrl->minimum;
>> -mt9m001->autoexposure = 1;
>> -} else
>> -mt9m001->autoexposure = 0;
>> -break;
>> +exp->val = (524 + (total_h - 1) *
>> +(exp->maximum - exp->minimum)) / 1048 +
>> +exp->minimum;
>> +}
>> +return 0;
>> }
>> -return 0;
>> +return -EINVAL;
>
> It seems to me, that you've dropped V4L2_CID_EXPOSURE here, was it
> intentional? I won't verify this in detail now, because, if it wasn't
> intentional and you fix it in v2, I'll have to re-check it anyway. Or is
> it supposed to be handled by that V4L2_EXPOSURE_MANUAL? So, if the user
> issues a V4L2_CID_EXPOSURE, are you getting V4L2_CID_EXPOSURE_AUTO with
> val == V4L2_EXPOSURE_MANUAL instead? Weird...
I also wonder first at this part for a long time like below:
1. when calling V4L2_CID_EXPOSURE_AUTO with V4L2_EXPOSURE_AUTO, it's ok.
2. when calling V4L2_CID_EXPOSURE_AUTO with V4L2_EXPOSURE_MANUAL, it's
also ok.
3. when calling V4L2_CID_EXPOSURE? where the device handle this CID?
but, after testing with application step by step, I finally know below:
when calling V4L2_CID_EXPOSURE, changing internal(v4l2_ctrl framework) variable,
exactly struct v4l2_ctrl exposure, which is register for probing time by
V4L2_CID_EXPOSURE, and clustered with struct v4l2_ctrl autoexposure. So, when
the device no needs to handle this values, but it automatically calls control
clustered with
itself, in this case the V4L2_CID_EXPOSURE calls(just
words)V4L2_CID_EXPOSURE_AUTO.
So, the my POV is that foo clustered with auto_foo calls auto_foo with foo's
characteristics.
But, Hans probably would do more clear answer.
Regards,
Heungjun Kim
--
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
[PATCH v2] Add support for M5MO-LS 8 Mega Pixel camera
Hello,
This is second patch of I2C/V4L2 subdev driver for M5MOLS 8 Mega Pixel camera
sensor using MIPI interface.
The first version patch is here:
http://www.spinics.net/lists/linux-media/msg26246.html
And the first verion's issues was corrected referencing with quick reviews of
Hans Verkuil and Sylwester Nawrocki.
The main issues is below:
1. remove I2C function macro, and use static inline for type-safe.
2. use the v4l2 control framework documented at v4l2-control.txt.
3. Add regulator enable/disable functions
4. fix any coding problems
The driver supports currently that:
1. Preview enables on each resolution and format code V4L2_MBUS_FMT_VYUY8_2X8.
2. The 5 kind of control was working well.
This driver is tested on s5pc210 board using s5p-fimc driver.
Thanks to any ideas.
Regrads,
Heungjun Kim
Signed-off-by: Heungjun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols/Kconfig |6 +
drivers/media/video/m5mols/Makefile |3 +
drivers/media/video/m5mols/m5mols.h | 257
drivers/media/video/m5mols/m5mols_controls.c | 173 +
drivers/media/video/m5mols/m5mols_core.c | 898 ++
drivers/media/video/m5mols/m5mols_reg.h | 103 +++
8 files changed, 1443 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols/Kconfig
create mode 100644 drivers/media/video/m5mols/Makefile
create mode 100644 drivers/media/video/m5mols/m5mols.h
create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
create mode 100644 drivers/media/video/m5mols/m5mols_core.c
create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ce3555a..fd3130a 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,8 @@ config VIDEO_NOON010PC30
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
+source "drivers/media/video/m5mols/Kconfig"
+
config SOC_CAMERA
tristate "SoC camera support"
depends on VIDEO_V4L2 && HAS_DMA && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 251b7ca..adb9361 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols/Kconfig
b/drivers/media/video/m5mols/Kconfig
new file mode 100644
index 000..387425b
--- /dev/null
+++ b/drivers/media/video/m5mols/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_M5MOLS
+ tristate "Fujitsu M5MO-LS 8MP sensor support"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This driver supports Fujitsu M5MO-LS camera sensor with ISP
+
diff --git a/drivers/media/video/m5mols/Makefile
b/drivers/media/video/m5mols/Makefile
new file mode 100644
index 000..b5d19bf
--- /dev/null
+++ b/drivers/media/video/m5mols/Makefile
@@ -0,0 +1,3 @@
+m5mols-objs:= m5mols_core.o m5mols_controls.o
+
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
new file mode 100644
index 000..eaeb7ca
--- /dev/null
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -0,0 +1,257 @@
+/*
+ * Header for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef M5MOLS_H
+#define M5MOLS_H
+
+#include
+#include "m5mols_reg.h"
+
+#define v4l2msg(fmt, arg...) do {\
+ v4l2_dbg(1, m5mols_debug, &info->sd, fmt, ## arg); \
+} while (0)
+
+extern int m5mols_debug;
+
+enum m5mols_mode {
+ MODE_SYSINIT,
+ MODE_PARMSET,
+ MODE_MONITOR,
+ MODE_UNKNOWN,
+};
+
+enum m5mols_i2c_size {
+ I2C_8BIT= 1,
+ I2C_16BIT = 2,
+ I2C_32BIT = 4,
+ I2C_MAX = 4,
+};
+
+enum m5mols_fps {
+ M5MOLS_FPS_AUTO = 0,
+ M5MOLS_FPS_10 = 10,
+ M5MOLS_FPS_12 = 12,
+ M5MOLS_FPS_15 = 15,
+ M5MOLS_FPS_20 = 20,
+ M5MOLS_FPS_21 = 21,
+ M5MOLS_FPS
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Hi Sylwester,
Thanks for some comments. I'll reflects this comments for the next version
patch. It's clear that there is a few things I missed. It's better to let's
talk about this rest things, as Mr. Park said.
But, I wanna remind one thing, and know your exact thiking. about MACROs.
I re-comments of that. look around and re-re-comments it, plz.
>> +
>> +/* MACRO */
>> +#define e_check_w(fn, cat, byte, val, bitwidth)do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if ((ret)< 0) {\
>> +dev_err(&client->dev, "fail i2c WRITE [%s] - "\
>> +"category:0x%02x, "\
>> +"bytes:0x%02x, "\
>> +"value:0x%02x\n",\
>> +(bitwidth),\
>> +(cat), (byte), (u32)val);\
>> +return ret;\
>> +}\
>> +} while (0)
>> +
>> +#define e_check_r(fn, cat, byte, val, bitwidth)do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if ((ret)< 0) {\
>> +dev_err(&client->dev, "fail i2c READ [%s] - "\
>> +"category:0x%02x, "\
>> +"bytes:0x%02x, "\
>> +"value:0x%02x\n",\
>> +(bitwidth),\
>> +(cat), (byte), (u32)(*val));\
>> +return ret;\
>> +}\
>> +} while (0)
>> +
>> +#define REG_W_8(cat, byte, value)\
>> +e_check_w(m5mols_write_reg(sd, M5MOLS_8BIT, cat, byte, value),\
>> +cat, byte, value, "8bit")
>> +#define REG_R_8(cat, byte, value)\
>> +e_check_r(m5mols_read_reg(sd, M5MOLS_8BIT, cat, byte, value),\
>> +cat, byte, value, "8bit")
>> +
>> +#define e_check_mode(fn, mode)do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if (ret< 0) {\
>> +dev_err(&client->dev, "Failed to %s mode\n",\
>> +(mode));\
>> +return ret;\
>> +}\
>> +} while (0)
>
> These macros really do not look good. Moreover they all change
> the control flow, i.e. return a value. From Documentation/CodingStyle:
>
> "Things to avoid when using macros:
>
> 1) macros that affect control flow:
>
> #define FOO(x) \
> do {\
> if (blah(x) < 0)\
> return -EBUGGERED; \
> } while(0)
>
> is a _very_ bad idea. It looks like a function call but exits the
> "calling" function; don't break the internal parsers of those who will
> read the code."
I know about Documentation/CodingStyle and absolutely know about
the risks of MACRO like upper case. I even know the _very_'s meanings.
But, I think this case is different any other MACRO cases to be concrete
whether use or not. Actually, I've not even found address symbol using T32
debuggers cause of MACROs. I have realized danger before long time.
I know Documentation/CodingStyle is very strong recommandation.
And must keep this style but, it seems to happen the specific case.
The specific means, not general and only used in the M5MOLS code.
The following is my thinking at past.
1. There are a lot of I2C communication is in M5MOLS driver code.
The M5MOLS has 16 category, and about 50 commands in the each category.
If each command need 1 line on the code, the amount to be charged I2C
communication only is 800 lines. What if each command be plused 3~4
error checking code? The code amount is 3200 lines at least. Moreover,
No guarantiee 1 command only 1 time excuetion. So, 3200 more lines
would be added at the future. (The m5mo driver you've seen and used before,
is not yet inserted all controls.)
For now, this driver supports only small function. But, If any all other
controls inserted this code, I can guarantee. it seems so hard to catch
the flow of code and operation. And, it seems to cause more problems for
functionalities and hiding bugs, rather than keep using CodingStyle.
2. m5mols I2C communications, namely m5mols_read_reg/write_reg is needed
many arguments. It violates to do checkpatch.pl 80 characters frequently.
So, I inserted next lines the rest of m5mols_read_reg(), it effects more
line added, consequently it looks like upper case.
3. Any other reason is discussed with Hans. And he explained alternative method.
so, I'll follow this because I think he is right.
I thought, exact when the wrong MACRO usage case told at CodingStyle is
happened.
(I don't believe that wrong MACRO usage must keep all the time in the kernel
code.)
And
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Hi Hans,
2010-12-16 오후 4:27, Hans Verkuil 쓴 글:
> Thanks for the reminder, I missed this patch.
>
> Review comments are below.
>
>> +
>> +/* MACRO */
>> +#define e_check_w(fn, cat, byte, val, bitwidth) do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if ((ret) < 0) {\
>> +dev_err(&client->dev, "fail i2c WRITE [%s] - " \
>> +"category:0x%02x, " \
>> +"bytes:0x%02x, "\
>> +"value:0x%02x\n", \
>> +(bitwidth), \
>> +(cat), (byte), (u32)val); \
>> +return ret; \
>> +} \
>> +} while (0)
>> +
>> +#define e_check_r(fn, cat, byte, val, bitwidth) do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if ((ret) < 0) {\
>> +dev_err(&client->dev, "fail i2c READ [%s] - " \
>> +"category:0x%02x, " \
>> +"bytes:0x%02x, "\
>> +"value:0x%02x\n", \
>> +(bitwidth), \
>> +(cat), (byte), (u32)(*val));\
>> +return ret; \
>> +} \
>> +} while (0)
>> +
>> +#define REG_W_8(cat, byte, value) \
>> +e_check_w(m5mols_write_reg(sd, M5MOLS_8BIT, cat, byte, value), \
>> +cat, byte, value, "8bit")
>> +#define REG_R_8(cat, byte, value) \
>> +e_check_r(m5mols_read_reg(sd, M5MOLS_8BIT, cat, byte, value), \
>> +cat, byte, value, "8bit")
>> +
>> +#define e_check_mode(fn, mode) do {\
>> +int ret;\
>> +ret = (int)(fn);\
>> +if (ret < 0) { \
>> +dev_err(&client->dev, "Failed to %s mode\n",\
>> +(mode));\
>> +return ret; \
>> +} \
>> +} while (0)
>> +
>> +#define mode_monitoring(sd) \
>> +e_check_mode(m5mols_monitoring_mode(sd), "MONITORING")
>> +#define mode_parameter(sd) \
>> +e_check_mode(m5mols_parameter_mode(sd), "PARAMETER")
>
> All these #defines above can be replaced by static inline functions. That the
> better option since static inline functions are type-safe.
>
You're definitely right. So, I know that #defines must be used carefully,
either.
But, in this driver code, the macros to use ultimately like this(e.g.,
REG_W_8(),
REG_R_8(), mode_monitoring(), mode_parameter()), is never return any value.
It return itself, if any error is sensed.
Namely, it's a bulk of codes, not a function.
IMHO, The reasons I made of this macro are 3 things.
1. It may not looks good to add 3 or 4 lines code for checking error return
values.
2. It can prevent to miss error-checking code. Just use macro, then be able to
handle error check, and show the kernel msg about i2c error return, or
anything
errors.
3. If this macro changes to function type, it need one more error checking codes
in the functions using this macros. So, then, the driver operation flow is a
litte mess-up.
Actually, to use static inline function for typesafing is right, I know.
But, can you think one more time, plz?
If I'm wrong after your thinking, I'll change this to inline functions.
>> +static struct v4l2_queryctrl m5mols_controls[] = {
>> +/* White balance */
>> +{
>> +.id = V4L2_CID_AUTO_WHITE_BALANCE,
>> +.type = V4L2_CTRL_TYPE_BOOLEAN,
>> +.name = "Auto White Balance",
>> +.minimum= 0,
>> +.maximum= 1,
>> +.step = 1,
>> +.default_value = 0,
>> +},
>> +/* Exposure metering/control */
>> +{
>> +.id = V4L2_CID_EXPOSURE_AUTO,
>> +.type = V4L2_CTRL_TYPE_INTEGER,
>> +.name = "Exposure control preset",
>> +.minimum= 0,
>> +.maximum= 3,
>> +.step = 1,
>> +.default_value = V4L2_EXPOSURE_AUTO,
>>
Re: [PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
Hi Hans,
Any comments? Just ping.
Thanks.
Regards,
HeungJun Kim
2010-12-10 오후 4:40, Kim, HeungJun 쓴 글:
> This patch adds support for M5MOLS Mega Pixel Fujitsu camera sensor.
>
> --
>
> Hello,
>
> This is an initial version of I2C/V4L2 subdev driver for M5MOLS camera
> sensor using MIPI interface from Fujitsu. This sensor supports various
> resolution at various fps on Monitoring(as we know preview),
> Preview(camcording), Capture(JPEG) mode. And, each mode supports
> different resolution range. Moreover, there are many image processing
> controls(flip, rotation, focus, zoom) and effects(even like a face
> recognitions). It has been tested with samsung/fimc and s5p-fimc driver
> on Aquila board. And this driver changed until now.
>
> This version supports just Monitoring mode at it's own many resolutions.
> But, there are many features in this sensor, and it's so hard to express
> all this features using a current CID or something else. so, I hope
> this initial version is merged soon in v4l/dvb, and then I wish the
> new needed CID is being added for this, and any other devices in addition.
>
> Any ideas are appreciated, Let me know.
>
> Thanks.
>
> Regards,
> HeungJun Kim
>
> Signed-off-by: Heungjun Kim
> Signed-off-by: Kyungmin Part
> ---
> drivers/media/video/Kconfig |6 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/m5mols.c | 1410
> ++
> include/media/m5mols.h | 31 +
> 4 files changed, 1448 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/m5mols.c
> create mode 100644 include/media/m5mols.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 6830d28..f2e6080 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -712,6 +712,12 @@ config VIDEO_SR030PC30
> ---help---
> This driver supports SR030PC30 VGA camera from Siliconfile
>
> +config VIDEO_M5MOLS
> + tristate "Fujitsu M5MOLS 8M Pixel sensor support"
> + depends on I2C && VIDEO_V4L2
> + ---help---
> + This driver supports M5MOLS 8 MEGA Pixel camera from Fujitsu
> +
> config VIDEO_VIA_CAMERA
> tristate "VIAFB camera controller support"
> depends on FB_VIA
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index af79d47..c76e44f 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
> obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
> obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
> obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o
> +obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
>
> obj-$(CONFIG_SOC_CAMERA_IMX074) += imx074.o
> obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
> diff --git a/drivers/media/video/m5mols.c b/drivers/media/video/m5mols.c
> new file mode 100644
> index 000..9f5c445
> --- /dev/null
> +++ b/drivers/media/video/m5mols.c
> @@ -0,0 +1,1410 @@
> +/*
> + * Driver for M5MOLS 8M Pixel camera sensor with ISP
> + *
> + * Copyright (C) 2010 Samsung Electronics Co., Ltd
> + * Author: HeungJun Kim, riverful@samsung.com
> + *
> + * Copyright (C) 2009 Samsung Electronics Co., Ltd
> + * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static int debug;
> +module_param(debug, int, 0644);
> +
> +/* MACRO */
> +#define e_check_w(fn, cat, byte, val, bitwidth) do {\
> + int ret;\
> + ret = (int)(fn);\
> + if ((ret) < 0) {\
> + dev_err(&client->dev, "fail i2c WRITE [%s] - " \
> + "category:0x%02x, " \
> + "bytes:0x%02x, "\
> + "value:0x%02x\n", \
> + (bitwidth), \
> + (cat), (byte), (u32)val); \
> + return ret; \
> + }
Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
2010-12-15 오후 4:57, Hans Verkuil 쓴 글:
> On Wednesday, December 15, 2010 01:19:43 Laurent Pinchart wrote:
>> Hi,
>>
>> (CC'ing linux-media this time, please discard the previous mail)
>>
>> On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
>>> Hi Laurent and Hans,
>>>
>>> I am working on V4L2 subdev for M5MOLS by Fujitsu.
>>> and I wanna listen your comments about Auto Focus mode of my ideas.
>>> the details is in the following link discussed at the past.
>>> Although the situation(adding the more various functions at the M5MOLS
>>> or any other MEGA camera sensor, I worked.)is changed,
>>> so I wanna continue this threads for now.
>>>
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
>>>
>>> First of all, the at least two more mode of auto-focus exists in the
>>> M5MOLS camera sensor. So, considering defined V4L2 controls and the
>>> controls in the M5MOLS, I suggest like this:
>>>
>>> +enum v4l2_focus_auto_type {
>>> + V4L2_FOCUS_AUTO_NORMAL = 0,
>>> + V4L2_FOCUS_AUTO_MACRO = 1,
>>> + V4L2_FOCUS_AUTO_POSITION = 2,
>>> +};
>>> +#define V4L2_CID_FOCUS_POSITION
>>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>>>
>>> -#define V4L2_CID_ZOOM_ABSOLUTE
>>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>>> -#define V4L2_CID_ZOOM_RELATIVE
>>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>>> +#define V4L2_CID_ZOOM_ABSOLUTE
>>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>>> +#define V4L2_CID_ZOOM_RELATIVE
>>> (V4L2_CID_CAMERA_CLASS_BASE+15)
>>>
>>>
>>> The M5MOLS(or other recent camera sensor) can have at least 2 mode although
>>> in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
>>> positioning focus mode, AKA. POSITION AF mode.
>>>
>>> The MACRO mode scan short range, and this mode can be used at the
>>> circumstance in the short distance with object and camera lens. So, It has
>>> fast lens movement, but the command FOCUSING dosen't works well at the
>>> long distance object.
>>>
>>> On the other hand, NORMAL mode can this. As the words, It's general and
>>> normal focus mode. The M5MOLS scan fully in the mode.
>>>
>>> In the Position AF mode, the position(expressed x,y) is given at the
>>> M5MOLS, and then the M5MOLS focus this area. But, the time given the
>>> position, is normally touch the lcd screen at the mobile device, in my
>>> case. If the time is given from button, it's no big problem *when*. But,
>>> in touch-lcd screen case, the position is read at the touch screen driver,
>>> before command FOCUS to camera sensor. It's the why I add another
>>> CID(V4L2_CID_FOCUS_POSITION).
>>
>> I'm pretty sure that some devices would require a rectangle instead of
>> coordinates to define the focus point. Even a rectangle might not be enough.
>> It would help if we could get feedback from camera designers here.
>>
>> Hans, should we add a new control type to pass coordinates/rectangles ? :-)
>
> It's a bit tricky actually since QUERYCTRL can return only one set of min/max
> values. For coordinates/rectangles we need two sets (horizontal and vertical).
>
> And I think it is important to know the min/max values.
>
> Regards,
>
> Hans
>
I agree with that.
So, IMHO, my real ideas is that:
1. It aparts two cid for focus POSITIONING.
(e.g., V4L2_CID_FOCUS_POSX, V4L2_CID_FOCUS_POSY. )
2. The min/max is changed, responsible for current camera sensor operating mode
& size.
The rectangle case is possible for focus mode. But, It can be dealt with this in
the subdev driver, although the camera sensor support rectangle focus.
Thanks.
Regards,
HeungJun Kim
--
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
Re: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
Hi Laurent,
2010-12-15 오전 9:19, Laurent Pinchart 쓴 글:
> Hi,
>
> (CC'ing linux-media this time, please discard the previous mail)
>
> On Tuesday 14 December 2010 12:27:32 Kim, HeungJun wrote:
>> Hi Laurent and Hans,
>>
>> I am working on V4L2 subdev for M5MOLS by Fujitsu.
>> and I wanna listen your comments about Auto Focus mode of my ideas.
>> the details is in the following link discussed at the past.
>> Although the situation(adding the more various functions at the M5MOLS
>> or any other MEGA camera sensor, I worked.)is changed,
>> so I wanna continue this threads for now.
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
>>
>> First of all, the at least two more mode of auto-focus exists in the
>> M5MOLS camera sensor. So, considering defined V4L2 controls and the
>> controls in the M5MOLS, I suggest like this:
>>
>> +enum v4l2_focus_auto_type {
>> +V4L2_FOCUS_AUTO_NORMAL = 0,
>> +V4L2_FOCUS_AUTO_MACRO = 1,
>> +V4L2_FOCUS_AUTO_POSITION = 2,
>> +};
>> +#define V4L2_CID_FOCUS_POSITION
>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>>
>> -#define V4L2_CID_ZOOM_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+13)
>> -#define V4L2_CID_ZOOM_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>> +#define V4L2_CID_ZOOM_ABSOLUTE
>> (V4L2_CID_CAMERA_CLASS_BASE+14)
>> +#define V4L2_CID_ZOOM_RELATIVE
>> (V4L2_CID_CAMERA_CLASS_BASE+15)
>>
>>
>> The M5MOLS(or other recent camera sensor) can have at least 2 mode although
>> in any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports
>> positioning focus mode, AKA. POSITION AF mode.
>>
>> The MACRO mode scan short range, and this mode can be used at the
>> circumstance in the short distance with object and camera lens. So, It has
>> fast lens movement, but the command FOCUSING dosen't works well at the
>> long distance object.
>>
>> On the other hand, NORMAL mode can this. As the words, It's general and
>> normal focus mode. The M5MOLS scan fully in the mode.
>>
>> In the Position AF mode, the position(expressed x,y) is given at the
>> M5MOLS, and then the M5MOLS focus this area. But, the time given the
>> position, is normally touch the lcd screen at the mobile device, in my
>> case. If the time is given from button, it's no big problem *when*. But,
>> in touch-lcd screen case, the position is read at the touch screen driver,
>> before command FOCUS to camera sensor. It's the why I add another
>> CID(V4L2_CID_FOCUS_POSITION).
>
> I'm pretty sure that some devices would require a rectangle instead of
> coordinates to define the focus point. Even a rectangle might not be enough.
> It would help if we could get feedback from camera designers here.
>
> Hans, should we add a new control type to pass coordinates/rectangles ? :-)
>
Very glad to be sure that.
As you know, the recent camera sensor embedded in mobile devices has evoluted
rapidly in a decade. It's not digital camera, but it operates like digital
camera. Actually, the camera sensor module with ISP in the recent mobile device
use the same one in the digital camera. And I can let you know this newer
control types, like in a uppper FOCUS case.(e.g.,iso, exposure, wb, wdr(wide
dynamic range), effects, the method to get jpeg bulk streams with sync, even
face detections.)
So, I'll make general patch or RFC patch about new control types which is
needed at
the the mobile device, based on M5MOLS and some sensors else, for generality.
(considering another ISP like a NEC, Samsung sensor modules. It is available
for me.)
After that, I'm glad with being reviewed it to Hans and Laurent.
(Actually, I don't know who is the maintainer of CID of camera. Let me know,
plz. :-) )
If Laurent and Hans agree with that, I'll prepare patch works.
Thanks for reading.
ps. I wanna know where the recent v4l2 control is described, as already told
at the previous my mail.
Regards,
HeungJun Kim
--
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
Fwd: What if add enumerations at the V4L2_FOCUS_MODE_AUTO?
I miss linux-media email addres.
So, I added it.
Thanks.
-
Hi Laurent and Hans,
I am working on V4L2 subdev for M5MOLS by Fujitsu.
and I wanna listen your comments about Auto Focus mode of my ideas.
the details is in the following link discussed at the past.
Although the situation(adding the more various functions at the M5MOLS
or any other MEGA camera sensor, I worked.)is changed,
so I wanna continue this threads for now.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg03543.html
First of all, the at least two more mode of auto-focus exists in the
M5MOLS camera sensor. So, considering defined V4L2 controls and the controls
in the M5MOLS, I suggest like this:
+enum v4l2_focus_auto_type {
+ V4L2_FOCUS_AUTO_NORMAL = 0,
+ V4L2_FOCUS_AUTO_MACRO = 1,
+ V4L2_FOCUS_AUTO_POSITION = 2,
+};
+#define V4L2_CID_FOCUS_POSITION
(V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13)
-#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+14)
+#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+15)
The M5MOLS(or other recent camera sensor) can have at least 2 mode although in
any cases : *MACRO* and *NORMAL* mode. plus, M5MOLS supports positioning focus
mode, AKA. POSITION AF mode.
The MACRO mode scan short range, and this mode can be used at the circumstance
in the short distance with object and camera lens. So, It has fast lens
movement,
but the command FOCUSING dosen't works well at the long distance object.
On the other hand, NORMAL mode can this. As the words, It's general and normal
focus
mode. The M5MOLS scan fully in the mode.
In the Position AF mode, the position(expressed x,y) is given at the M5MOLS,
and then the M5MOLS focus this area. But, the time given the position, is
normally touch the lcd screen at the mobile device, in my case. If the time is
given from button, it's no big problem *when*. But, in touch-lcd screen case,
the position is read at the touch screen driver,
before command FOCUS to camera sensor. It's the why I add another
CID(V4L2_CID_FOCUS_POSITION).
So, how do you think about this?
Thanks to read my ideas, and I wait for your answer.
Regrads,
HeungJun Kim
PS. can you let me know where the recent v4l2 controls is described or
specificated??
I found this -
http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#camera-controls,
but It seems a little old, I think.
--
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
Re: I wonder the difference with mbus_pixelcode and v4l2_colorspace.
Thanks Guennadi, Actually, I have been confused between MC & MB. Including this, the link of Laurent is very helpful for me to make M5MOLS subdev driver. Regard, HeungJun Kim 2010-12-08 오후 4:23, Guennadi Liakhovetski 쓴 글: > Hi > > On Wed, 8 Dec 2010, Kim, HeungJun wrote: > >> Hi Guennadi, >> >> I wonder the difference with pixelcode mediabus and v4l2_colorspace. >> In mt9m001.c subdev driver, the "format" seems be determined using the >> combination pixelcode & colorspace. In the previous kernel >> version(before using Media Controller), >> somtimes the pixelformat is used for defining format of isp device. But, >> I gonna change to use Media Controller. > > The change to mediabus pixelcodes has happened a while ago, whereas media > controller is still not in the mainline. Mediabus is physically a bus > between various parts of the media (video) subsystem, e.g., between a > sensor and an SoC, or between resizers, format converters, etc., as long > as data between them is exchanged directly over a set of data and sync > lines, and not via mamory buffers. Original V4L2 fourcc codes on the other > side describe data format in _memory_. > > The use of a pixelcode and a colorspace has been selected for the new > mediabus API, so, that's what we have to use now in drivers, using this > API. > >> So, can you tell me where I find about Media Controller, especially >> pixelcode and colorspace? > > Again - these are not directly related things. The MC API has adopted, > extended and is using the mediabus API, Laurent has documented many things > wonderfully, have a look at > http://www.ideasonboard.org/media/media/subdev.html#v4l2-mbus-format > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- 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
[PATCH] V4L/DVB: Add support for M5MOLS Mega Pixel camera
This patch adds support for M5MOLS Mega Pixel Fujitsu camera sensor.
--
Hello,
This is an initial version of I2C/V4L2 subdev driver for M5MOLS camera
sensor using MIPI interface from Fujitsu. This sensor supports various
resolution at various fps on Monitoring(as we know preview),
Preview(camcording), Capture(JPEG) mode. And, each mode supports
different resolution range. Moreover, there are many image processing
controls(flip, rotation, focus, zoom) and effects(even like a face
recognitions). It has been tested with samsung/fimc and s5p-fimc driver
on Aquila board. And this driver changed until now.
This version supports just Monitoring mode at it's own many resolutions.
But, there are many features in this sensor, and it's so hard to express
all this features using a current CID or something else. so, I hope
this initial version is merged soon in v4l/dvb, and then I wish the
new needed CID is being added for this, and any other devices in addition.
Any ideas are appreciated, Let me know.
Thanks.
Regards,
HeungJun Kim
Signed-off-by: Heungjun Kim
Signed-off-by: Kyungmin Part
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols.c | 1410 ++
include/media/m5mols.h | 31 +
4 files changed, 1448 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols.c
create mode 100644 include/media/m5mols.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6830d28..f2e6080 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -712,6 +712,12 @@ config VIDEO_SR030PC30
---help---
This driver supports SR030PC30 VGA camera from Siliconfile
+config VIDEO_M5MOLS
+ tristate "Fujitsu M5MOLS 8M Pixel sensor support"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This driver supports M5MOLS 8 MEGA Pixel camera from Fujitsu
+
config VIDEO_VIA_CAMERA
tristate "VIAFB camera controller support"
depends on FB_VIA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index af79d47..c76e44f 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols.c b/drivers/media/video/m5mols.c
new file mode 100644
index 000..9f5c445
--- /dev/null
+++ b/drivers/media/video/m5mols.c
@@ -0,0 +1,1410 @@
+/*
+ * Driver for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2010 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+
+/* MACRO */
+#define e_check_w(fn, cat, byte, val, bitwidth)do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) < 0) {\
+ dev_err(&client->dev, "fail i2c WRITE [%s] - " \
+ "category:0x%02x, " \
+ "bytes:0x%02x, "\
+ "value:0x%02x\n", \
+ (bitwidth), \
+ (cat), (byte), (u32)val); \
+ return ret; \
+ } \
+} while (0)
+
+#define e_check_r(fn, cat, byte, val, bitwidth)do {\
+ int ret;\
+ ret = (int)(fn);\
+ if ((ret) < 0) {\
+ dev_err(&client->dev, "fail i2c READ [%s] - " \
+ "category:0x%02x, " \
+ "bytes:0x%02x, "\
+ "value:0x%02x\n", \
+ (bitwidth), \
+ (cat), (byte), (u32)(*val));\
+ return ret;
I wonder the difference with mbus_pixelcode and v4l2_colorspace.
Hi Guennadi, I wonder the difference with pixelcode mediabus and v4l2_colorspace. In mt9m001.c subdev driver, the "format" seems be determined using the combination pixelcode & colorspace. In the previous kernel version(before using Media Controller), somtimes the pixelformat is used for defining format of isp device. But, I gonna change to use Media Controller. So, can you tell me where I find about Media Controller, especially pixelcode and colorspace? Thanks. Regards, HeungJun Kim -- 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
dose the subdev driver need pm features??
Hi Hans and everyone, I wonder if the subdev driver need pm features, like a power-off when suspend and power-on when resume. Commonly, It seems alright that the platform driver using this subdev driver must do such process. But, thinking deeply, irrelevantly at this dependency of the platform and the subdev, I think the subdev driver must support pm features. If the platform driver dosen't support subdev driver's pm, the ISP or camera device controlled with non-pm-support subdev driver, may have a problems when the system is suspended/resumed. In the subev driver, using pm or not. which one is right?? Regards, HeungJun Kim -- 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
When do I use v4l2_i2c_data structure or regular I2C driver method??
Hello Hans and everyone, The I2C V4L2 driver(sensor or lens motor controll chip or whatever) can be registerd with 2 method, I know. 1) using v4l2_i2c_data structure defined in the v4l2-i2c-drv.h 2) not using v4l2_i2c_data, just use i2c_add_driver() like registering method regular i2c driver. But, I don't know the precise difference between upper 2 method. Maybe, I think that there is the clear reason as Hans made it. What's the reason?? If there is any ideas, let me know, plz. Thanks. Regards, HeungJun -- 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
RE: how can deal with the stream in only on-the-fly-output available HW block??
4L2 classic method. (cause of no buffers) 3) in the preview mode, there is another option is using media framework. (must be changed Block A code from platform device type to subdev type) 4) base kernel version 2.6.34, and already is working using a little hacks. (not using v4l2 type, only use S_FMT and STREAMON ioctl calls.) My question is this. Q) what's the best choice to keep the V4L2 description & framework, between changing buf_type and using media framework, in this case?? I'm not sure, but we have also a plan to upload ths SoC patches to the mainline, probably. So, it's very significant to keep the V4L2 specification, also just using V4L2. Thanks to advise and read. Regards, HeungJun, Kim > > Regards, > > Hans > > > > > I would show this SoC's media H/W Blocks flowchart briefly. > > > > > > > > +--+ > > | FIFO Link| > > +---| using |---+ > > | | Internal SRAM | | > >+---+| +--+ | > >| C || | > >| C | ++---+ > > +---+ > >| D | | H/W Block A || H/W Block B > > | > >| | +---++ Vsync issued > > +---+ > >| S +---+ Sensor| Pre - | using Interrupt |Post - > > | > >| E | | Interface | Processor | recognized at| Processor > > | > >| N | ++--++ H/W Block B > > +-+-+ > >| S || | | > >| O |+--+ | > >| R | Vsync issued | DMA Link > >+---+ using Interrupt | > > recognized in H/W Block A | > >| > > > > +---+-+ > >| DMA Bus > > | > > > > +-+ > > > > If the flowchart is crashed, copy and paste in the notepad or something. > > In the fixed size font, it will looks well. > > > > Actualy my opinion, any other buf_type is needed to define in such case, > > like a V4L2_BUF_FLAG_FIFO, not using media framework. > > > > Thanks to reading, and I'll wait any advises and opinions. > > > > Regards, > > HeungJun, Kim > > > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Kim, HeungJun > Sent: Wednesday, September 15, 2010 3:39 PM > To: 'Laurent Pinchart'; hverk...@xs4all.nl > Cc: linux-media@vger.kernel.org; inki@samsung.com; > kyungmin.p...@samsung.com > Subject: RE: how can deal with the stream in only on-the-fly-output > available HW block?? > > Sorry, I miss sending msg into any other thread. > Send with the right thread, Again. > > Thanks, > HeungJun Kim > > -- > -- > -- > > Hi Laurent, and Hans, > > I checked media frameworks, it was helpful for me, but It's not usable on > my > case. Because, before defining the device for using media frameworks, the > device must be defined by some other device like FB, ALSA, DVB, etc. But, > this H/W Block is no way to define using any other method in current V4L2 > frameworks. > > So, I wanna listen to your advices about this cases. > > It has 2 modes, the Preview mode to have Capturing & FIFOing capability, > and > the Capture mode to DMAing capabilitiy. Exactly, in Preview mode, it > dosen't > need any other V4L2 IOCTL calls related with buffer, like VIDIOC_REQBUFS, > VIDIOC_QUERYBUFS, and mmap() operation. Using just VIDIOC_S_FMT IOCTL > calls, > is able to define this block. Because, it has no buffers. The QBUF and > DQBUF > looping, also is same any other V4L2 driver working process. On the other > hand, In Capture mode, the same stream of Preview mode, is able to get > using > WDMA. So, at this mode, it need V4L2 IOCTL calls related with buffers. > > I would show this SoC's m
RE: how can deal with the stream in only on-the-fly-output available HW block??
Sorry, I miss sending msg into any other thread. Send with the right thread, Again. Thanks, HeungJun Kim -- Hi Laurent, and Hans, I checked media frameworks, it was helpful for me, but It's not usable on my case. Because, before defining the device for using media frameworks, the device must be defined by some other device like FB, ALSA, DVB, etc. But, this H/W Block is no way to define using any other method in current V4L2 frameworks. So, I wanna listen to your advices about this cases. It has 2 modes, the Preview mode to have Capturing & FIFOing capability, and the Capture mode to DMAing capabilitiy. Exactly, in Preview mode, it dosen't need any other V4L2 IOCTL calls related with buffer, like VIDIOC_REQBUFS, VIDIOC_QUERYBUFS, and mmap() operation. Using just VIDIOC_S_FMT IOCTL calls, is able to define this block. Because, it has no buffers. The QBUF and DQBUF looping, also is same any other V4L2 driver working process. On the other hand, In Capture mode, the same stream of Preview mode, is able to get using WDMA. So, at this mode, it need V4L2 IOCTL calls related with buffers. I would show this SoC's media H/W Blocks flowchart briefly. +--+ | FIFO Link| +---| using |---+ | | Internal SRAM | | +---+| +--+ | | C || | | C | ++---+ +---+ | D | | H/W Block A || H/W Block B | | | +---++ Vsync issued +---+ | S +---+ Sensor| Pre - | using Interrupt |Post - | | E | | Interface | Processor | recognized at| Processor | | N | ++--++ H/W Block B +-+-+ | S || | | | O |+--+ | | R | Vsync issued | DMA Link +---+ using Interrupt | recognized in H/W Block A | | +---+-+ | DMA Bus | +-+ If the flowchart is crashed, copy and paste in the notepad or something. In the fixed size font, it will looks well. Actualy my opinion, any other buf_type is needed to define in such case, like a V4L2_BUF_FLAG_FIFO, not using media framework. Thanks to reading, and I'll wait any advises and opinions. Regards, HeungJun, Kim > -Original Message- > From: Kim, HeungJun [mailto:riverful@samsung.com] > Sent: Tuesday, September 14, 2010 2:11 PM > To: 'linux-media@vger.kernel.org'; 'laurent.pinch...@ideasonboard.com'; > 'hverk...@xs4all.nl' > Cc: 'inki@samsung.com'; 'kyungmin.p...@samsung.com' > Subject: how can deal with the stream in only on-the-fly-output available > HW block?? > > > > -Original Message- > From: Kim, HeungJun [mailto:riverful@samsung.com] > Sent: Tuesday, September 14, 2010 2:02 PM > To: 'laurent.pinch...@ideasonboard.com'; 'hverk...@xs4all.nl' > Subject: RE: how can deal with the stream in only on-the-fly-output > available HW block?? > > > On Monday, September 13, 2010 14:10:55 Kim, HeungJun wrote: > > > Hi all, > > > > > > > > > > > > What if some SoC's specific HW block supports only on-the-fly mode for > > > stream output?? > > > > What do you mean with 'on-the-fly mode'? Does that mean that two HW > blocks > > are linked together so that the video stream goes directly from one to > the > > other without ever being DMA-ed to memory? > > You're right. It's linked with internal SRAM FIFO. So, syncing streams > with both blocks is kept with VSync Interrupt. It's not using DMA-ed to > memory in this mode. > > > > > > > > > In this case, what is the suitable buf_type?? > > > > Suitable buf_type for doing what? > > I wanna define this blocks topology with V4L2 APIs. But, I don't find > suitable buf_type or any definitions in the V4L2 APIs with current SoC's > block media topology. > > > > > You probably need the upcoming media API to be able to correctly deal > with > &
RE: Linux V4L2 support dual stream video capture device
Hi Laurent, and Hans, I checked media frameworks, it was helpful for me, but It's not usable on my case. Because, before defining the device for using media frameworks, the device must be defined by some other device like FB, ALSA, DVB, etc. But, this H/W Block is no way to define using any other method in current V4L2 frameworks. So, I wanna listen to your advices about this cases. It has 2 modes, the Preview mode to have Capturing & FIFOing capability, and the Capture mode to DMAing capabilitiy. Exactly, in Preview mode, it dosen't need any other V4L2 IOCTL calls related with buffer, like VIDIOC_REQBUFS, VIDIOC_QUERYBUFS, and mmap() operation. Using just VIDIOC_S_FMT IOCTL calls, is able to define this block. Because, it has no buffers. The QBUF and DQBUF looping, also is same any other V4L2 driver working process. On the other hand, In Capture mode, the same stream of Preview mode, is able to get using WDMA. So, at this mode, it need V4L2 IOCTL calls related with buffers. I would show this SoC's media H/W Blocks flowchart briefly. +--+ | FIFO Link| +---| using |---+ | | Internal SRAM | | +---+| +--+ | | C || | | C | ++---+ +---+ | D | | H/W Block A || H/W Block B | | | +---++ Vsync issued +---+ | S +---+ Sensor| Pre - | using Interrupt |Post - | | E | | Interface | Processor | recognized at| Processor | | N | ++--++ H/W Block B +-+-+ | S || | | | O |+--+ | | R | Vsync issued | DMA Link +---+ using Interrupt | recognized in H/W Block A | | +---+-+ | DMA Bus | +-+ If the flowchart is crashed, copy and paste in the notepad or something. In the fixed size font, it will looks well. Actualy my opinion, any other buf_type is needed to define in such case, like a V4L2_BUF_FLAG_FIFO, not using media framework. Thanks to reading, and I'll wait any advises and opinions. Regards, HeungJun, Kim > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > Sent: Tuesday, September 14, 2010 6:53 PM > To: Theodore Kilgore > Cc: Wang, Wen W; linux-media@vger.kernel.org; Zhang, Xiaolin; Huang, Kai; > Hu, Gang A > Subject: Re: Linux V4L2 support dual stream video capture device > > Hi Theodore, > > On Monday 13 September 2010 19:17:48 Theodore Kilgore wrote: > > On Mon, 13 Sep 2010, Laurent Pinchart wrote: > > > On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: > > > > Hi all, > > > > > > > > I'm wondering if V4L2 framework supports dual stream video capture > > > > device that transfer a preview stream and a regular stream (still > > > > capture or video capture) at the same time. > > > > > > > > We are developing a device driver with such capability. Our proposal > to > > > > do this in V4L2 framework is to have two device nodes, one as > primary > > > > node for still/video capture and one for preview. > > > > > > If the device supports multiple simultaneous video streams, multiple > > > video nodes is the way to go. > > > > > > > The primary still/video capture device node is used for device > > > > configuration which can be compatible with open sourced applications. > > > > This will ensure the normal V4L2 application can run without code > > > > modification. Device node for preview will only accept preview > buffer > > > > related operations. Buffer synchronization for still/video capture > and > > > > preview will be done internally in the driver. > > > > > > I suspect that the preview device node will need to support more than > the > > > buffer-related operations, as you probably want applications to > configure > > > the preview video stream format and size. > > > > > > > This is our initial idea about the dual stream support in V4L2. Your > > > > comments will be appreciated! > > > > > > You should use the media controller framework. This will allow > > > applications to configure all sizes in the pipeline, including the > frame > > > sizes for the two video nodes. > > > > Hi, Wen, > > > > You have hit upon an old and rather vexing problem. It a
how can deal with the stream in only on-the-fly-output available HW block??
-Original Message- From: Kim, HeungJun [mailto:riverful@samsung.com] Sent: Tuesday, September 14, 2010 2:02 PM To: 'laurent.pinch...@ideasonboard.com'; 'hverk...@xs4all.nl' Subject: RE: how can deal with the stream in only on-the-fly-output available HW block?? > On Monday, September 13, 2010 14:10:55 Kim, HeungJun wrote: > > Hi all, > > > > > > > > What if some SoC's specific HW block supports only on-the-fly mode for > > stream output?? > > What do you mean with 'on-the-fly mode'? Does that mean that two HW blocks > are linked together so that the video stream goes directly from one to the > other without ever being DMA-ed to memory? You're right. It's linked with internal SRAM FIFO. So, syncing streams with both blocks is kept with VSync Interrupt. It's not using DMA-ed to memory in this mode. > > > > > In this case, what is the suitable buf_type?? > > Suitable buf_type for doing what? I wanna define this blocks topology with V4L2 APIs. But, I don't find suitable buf_type or any definitions in the V4L2 APIs with current SoC's block media topology. > > You probably need the upcoming media API to be able to correctly deal with > these issues. Check the mailing list for the patches done by Laurent > Pinchart. > > The current V4L2 API is really not able to handle changes in the internal > video stream topology. Thanks to Hans. It's very helpful. I'll check Laurent's media topology patches. Hello, Laurent, I'm googling and find your patches, so I'm checking with. But, where can I get your patches?? Probably, I would find in this page : http://git.linuxtv.org/, so what's your repository? Regards, HeungJun, Kim > > Regards, > > Hans > > > > > I'm faced with such problem. > > > > > > > > As explanation for my situation briefly, the processor I deal with now > has 3 > > Multimedia H/W blocks, and the problem-one in the 3 blocks do the work > for > > sensor-interfacing and pre-processing. > > > > It supports CCD or CMOS for input, and DMA or On-The-Fly for output. > > Exactly, it has two cases - DMA mode using memory bus & On-The-Fly mode > > connected with any other multimedia blocks. > > > > Also, it use only one format "Bayer RGB" in case of mode the DMA and > > On-The-Fly mode both. > > > > > > > > So, when the device operates in the On-The-Fly mode, is it alright the > > driver's current type is V4L2_BUF_TYPE_VIDEO_CAPTURE? or something else? > > > > or if setting buf_type is wrong itself, what v4l2 API flow is right for > > driver or userspace?? > > > > > > > > the v4l2 buf_type enumeratinos is defined here, but I have no idea about > > suitable enum value in this case, also except for any other under enums > too. > > > > > > > > V4L2_BUF_TYPE_VIDEO_CAPTURE= 1, > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT = 2, > > > > V4L2_BUF_TYPE_VIDEO_OVERLAY= 3, > > > > V4L2_BUF_TYPE_VBI_CAPTURE = 4, > > > > V4L2_BUF_TYPE_VBI_OUTPUT = 5, > > > > V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6, > > > > V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7, > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, > > > > V4L2_BUF_TYPE_PRIVATE = 0x80, > > > > > > > > I'll thanks for any idea or answer. > > > > > > > > Regards, > > > > HeungJun, Kim > > > > > > > > > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of > Cisco -- 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
how can deal with the stream in only on-the-fly-output available HW block??
Hi all, What if some SoC's specific HW block supports only on-the-fly mode for stream output?? In this case, what is the suitable buf_type?? I'm faced with such problem. As explanation for my situation briefly, the processor I deal with now has 3 Multimedia H/W blocks, and the problem-one in the 3 blocks do the work for sensor-interfacing and pre-processing. It supports CCD or CMOS for input, and DMA or On-The-Fly for output. Exactly, it has two cases - DMA mode using memory bus & On-The-Fly mode connected with any other multimedia blocks. Also, it use only one format "Bayer RGB" in case of mode the DMA and On-The-Fly mode both. So, when the device operates in the On-The-Fly mode, is it alright the driver's current type is V4L2_BUF_TYPE_VIDEO_CAPTURE? or something else? or if setting buf_type is wrong itself, what v4l2 API flow is right for driver or userspace?? the v4l2 buf_type enumeratinos is defined here, but I have no idea about suitable enum value in this case, also except for any other under enums too. V4L2_BUF_TYPE_VIDEO_CAPTURE= 1, V4L2_BUF_TYPE_VIDEO_OUTPUT = 2, V4L2_BUF_TYPE_VIDEO_OVERLAY= 3, V4L2_BUF_TYPE_VBI_CAPTURE = 4, V4L2_BUF_TYPE_VBI_OUTPUT = 5, V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6, V4L2_BUF_TYPE_SLICED_VBI_OUTPUT= 7, V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, V4L2_BUF_TYPE_PRIVATE = 0x80, I'll thanks for any idea or answer. Regards, HeungJun, Kim -- 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
