Re: OMAP3 ISP and camera drivers (update 2)
2009. 06. 22, 오후 10:52, Tuukka.O Toivonen 작성: On Saturday 20 June 2009 12:05:13 ext Dongsoo, Nathaniel Kim wrote: Following patch. http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b00f45b209523929b15b5 What happens to the capability when the int device is dummy? (does it mean that there is no int device?) Yes, when the int device is dummy, there is no such a device. For example, when vdev-vdev_sensor == v4l2_int_device_dummy() it means that the device has no sensor. In that case, obviously, the device is not capable of capturing or streaming. OK, what I'm afraid is that even though the device could be opened and recognized as a v4l2 device but has no capability should be weird. Actually I'm not sure about this case is spec-in or not. In my opinion it should be better when the camera interface (or ISP) has no int device (or subdev) attahced on it, no device node mounted in /dev or returning ENODEV. But before that, I'm very curious about why you made in that way. And one more thing. If I want to test how the ISP driver is working, is there any target board that I can buy also a sensor device already attached on it? I think that TI probably has some boards for sale, you could take a look at their web pages. - Tuukka Thank you I'll try to find on their web site :-) Cheers, Nate == Dong Soo, Kim Engineer Mobile S/W Platform Lab. Telecommunication RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
Re: OMAP3 ISP and camera drivers (update 2)
2009. 06. 22, 오후 11:01, Aguirre Rodriguez, Sergio Alberto 작성: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Tuukka.O Toivonen Sent: Monday, June 22, 2009 8:52 AM To: ext Dongsoo, Nathaniel Kim Cc: Sakari Ailus; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Hiremath, Vaibhav; Koskipaa Antti (Nokia-D/Helsinki); Cohen David.A (Nokia-D/Helsinki); Alexey Klimov; g...@mlbassoc.com Subject: Re: OMAP3 ISP and camera drivers (update 2) On Saturday 20 June 2009 12:05:13 ext Dongsoo, Nathaniel Kim wrote: Following patch. http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b0 0f45b209523929b15b5 What happens to the capability when the int device is dummy? (does it mean that there is no int device?) Yes, when the int device is dummy, there is no such a device. For example, when vdev-vdev_sensor == v4l2_int_device_dummy() it means that the device has no sensor. In that case, obviously, the device is not capable of capturing or streaming. And one more thing. If I want to test how the ISP driver is working, is there any target board that I can buy also a sensor device already attached on it? I think that TI probably has some boards for sale, you could take a look at their web pages. Hi Nate, I'm currently rebasing these patches on top of latest Kevin's PM tree, and trying to make 3430SDP (MT9P012 and OV3640), Zoom1 and Zoom2 (not there yet, but in the works) sensors to work in there. Thank you Sergio. So you mean that I can buy OMAP Zoom target board with MT or OV sensor on it sooner or later? cool! You can find this tree on: http://dev.omapzoom.org/?p=saaguirre/linux-omap-camera.git;a=summary Checkout devel branch. That's my latest progress. OK I'll try to look at the devel branch. Cheers, Nate Regards, Sergio - Tuukka -- 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: About VIDIOC_G_OUTPUT/S_OUTPUT ?
Hi Hans, 2009. 05. 22, 오후 9:40, Hans Verkuil 작성: On Friday 22 May 2009 04:05:47 Dongsoo, Nathaniel Kim wrote: Hi Hans, On Thu, May 21, 2009 at 9:07 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Wednesday 20 May 2009 13:48:08 Dongsoo, Nathaniel Kim wrote: Hello everyone, Doing a new camera interface driver job of new AP from Samsung, a single little question doesn't stop making me confused. The camera IP in Samsung application processor supports for two of output paths, like to memory and to LCD FIFO. It seems to be VIDIOC_G_OUTPUT/S_OUTPUT which I need to use (just guessing), but according to Hans's ivtv driver the output of G_OUTPUT/S_OUTPUT is supposed to mean an actually and physically separated real output path like Composite, S-Video and so on. Do you think that memory or LCD FIFO can be an output device in this case? Because in earlier version of my driver, I assumed that the LCD FIFO is a kind of OVERLAY device, so I didn't even need to use G_OUTPUT and S_OUTPUT to route output device. I'm just not sure about which idea makes sense. or maybe both of them could make sense indeed... When you select to memory, then the video from the camera is DMAed to the CPU, right? But selecting to LCD means that the video is routed internally to the LCD without any DMA to the CPU taking place, right? Yes definitely right. This is similar to the passthrough mode of the ivtv driver. This header: linux/dvb/video.h contains an ioctl called VIDEO_SELECT_SOURCE, which can be used to select either memory or a demuxer (or in this case, the camera) as the source of the output (the LCD in this case). It is probably the appropriate ioctl to implement for this. So, in user space we should call VIDIO_SELECT_SOURCE ioctl? Yes. The video.h header is shared between v4l and dvb and contains several ioctls meant to handle output. It is poorly documented and I think it should be merged into the v4l2 API and properly documented/cleaned up. I agree with you. Anyway, camera interface is not a DVB device but supporting this source routing feature means that we also need this API in v4l2. It's valid to use VIDEO_SELECT_SOURCE in an v4l2 driver. It's currently used by ivtv. It's an historical accident that these ioctls ended up in the dvb header. Oh, I'll look into the driver. Cheers. Note that overlays are meant for on-screen displays. Usually these are associated with a framebuffer device. Your hardware may implement such an OSD as well, but that is different from this passthrough feature. Sorry Hans, I'm not sure that I'm following this part. Can I put it in the way like this? The OSD feature in Samsung AP should be handled separated with the selecting source feature (camera-to-FB and camera-to-memory). So that I should implement both of them. (overlay feature and select source feature) Am I following? Please let me know if there is something wrong. Yes, that's correct. BTW, my 5M camera driver which is including the new V4L2 API proposal I gave a talk in SF couldn't have approval from my bosses to be opened to the public. But I'll try to make another camera device driver which can cover must of the API I proposed. That's a shame. Erm, just to make it clear for your bosses: any v4l2 driver that uses any of the videobuf_*, v4l2_i2c_*, v4l2_device_* or v4l2_int_* functions must be a GPL driver, and thus has to be made available upon request. All these functions are marked EXPORT_SYMBOL_GPL. I don't know if they realize this fact. Oops I didn't make it clear that my driver was not used for a commercial product. I made them for our platform development and test, and as a matter of fact my drivers will be opened in the end but not just soon enough. I think there is some issues in non-technical area which I'm not aware of. I'll make another driver with other camera device because I can't wait any longer. My boss approved that should be OK. And actually it is challenging indeed. Cheers, Nate Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/ davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area and he may have fixed some of these issues already. Very useful, that Embedded Linux conference... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
Re: [PATCH 5/5] soc-camera: Convert to a platform driver
2009. 04. 16, 오후 11:56, Guennadi Liakhovetski 작성: On Thu, 16 Apr 2009, Dongsoo Kim wrote: And about camera client with several inputs question, I will say that almost every 3G UMTS phone has dual camera on it. And we can consider every 3G UMTS smart phones have dual camera on it with soc camera solution. No, sorry, this wasn't my question. By client I meant one camera or decoder or whatever chip connects to a camera host. I.e., if we have a single chip with several inputs, that should logically be handled with S_INPUT ioctl, this would further add to the confusion of using different inputs on one video device to switch between chips or inputs / functions on one chip. Yes exactly. It was single chip with several inputs. that I intended to tell. but still don't get what the confusion you mean. Sorry ;-() Cheers, Wow, so, on those phone a dual camera is a single (CMOS) controller with two sensors / lenses / filters?... Cool, do you have an example of such a camera to look for on the net? Preferably with a datasheet available. Oops sorry I didn't mean that. I just meant one single camera interface on Application Processor and two camera modules (sensor, lens, isp) connected. Sorry I explained badly. I considered this as single camera interface with several inputs. Confusion I meant that in this case switching between inputs sometimes switches you to another controller and sometimes to another function within the same controller... I think we don't need to worry about that if we can query camera inputs clearly. Cheers, Nate Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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 about adding FOCUS mode?
Hi,
2009. 03. 28, 오전 1:19, Laurent Pinchart 작성:
Hi,
On Friday 27 March 2009 08:24:27 Hans Verkuil wrote:
On Friday 27 March 2009 07:20:51 Kim, Heung Jun wrote:
Hello, Hans everyone.
I'm trying to adapt the various FOCUS MODE int the NEC ISP driver.
NEC ISP supports 4 focus mode, AUTO/MACRO/MANUAL/FULL or NORMAL.
but, i think that it's a little insufficient to use V4L2 FOCUS
Feature.
so, suggest that,
- change V4L2_CID_FOCUS_AUTO's type from boolean to interger, and
add
the following enumerations for CID values.
enum v4l2_focus_mode {
V4L2_FOCUS_AUTO= 0,
V4L2_FOCUS_MACRO= 1,
V4L2_FOCUS_MANUAL= 2,
V4L2_FOCUS_NORMAL= 3,
V4L2_FOCUS_LASTP= 3,
};
how about this usage? i wanna get some advice about FOCUS MODE.
V4L2_CID_FOCUS_AUTO is meant to change the auto-focus mode. Can you
describe
FOCUS_MACRO and FOCUS_NORMAL in more details ? Are they auto-focus
modes or
just focus presets ?
As far as I know, they represent focus lens movement range.
If you set to AF macro, focus lens scans near range first, so that
focusing movement could finish earlier.
This seems more logical to me:
enum v4l2_focus_mode {
V4L2_FOCUS_MANUAL = 0,
V4L2_FOCUS_AUTO_NORMAL = 1,
V4L2_FOCUS_AUTO_MACRO = 2,
};
At least this maps the current boolean values correctly. I'm not
sure from
your decription what the fourth auto focus mode is supposed to be.
Does an auto-macro focus mode really exists ?
Sure, you can find in some digital camera or brand new high end camera
phones.
By the way, sorry for answering instead of heungjun Kim. I work with
him actually.
Is it OK?
Cheers,
Nate
But I think it might be better to have a separate control that
allows you
to set the auto-focus mode. I can imagine that different devices
might have
different auto-focus modes.
I've CC-ed Laurent since this is more his field than mine.
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
Re: Embedded Linux Conference
Hi Tony, I think I can join you. And also Kyungmin Park I guess. See you then. Nate 2009. 03. 18, 오전 1:45, Tony Lindgren 작성: * Kevin Hilman khil...@deeprootsystems.com [090317 07:50]: Hans Verkuil wrote: On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. I won't be arriving until late Sunday night, and I imagine others may be arrving Monday morning. How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ To get a rough idea how many people we'll have, please reply to this thread, or send me an email if you're planning to attend. Cheers, Tony [1] http://www.embeddedlinuxconference.com/elc_2009/program.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] How to pass camera Orientation to userspace
Hello Hans. I went too far. Just forgot what we can do through porting job. You are right. That should be board specific item. Cheers, Nate 2009. 02. 18, 오후 11:36, Hans de Goede 작성: DongSoo(Nathaniel) Kim wrote: Hello Adam, I've been thinking exactly the same issue not usb but SoC based camera. I have no idea about how usb cameras work but I am quite curious about is it really possible to make proper orientation with only querying camera driver. Because in case of SoC based camera device, many of camera ISPs are supporting VFLIP, HFLIP register on their own, and we can read current orientation by reading those registers. But the problem is ISP's registers are set as not flipped at all but it physically mounted upside down, because the H/W vendor has packed the camera module upside down. (it sounds ridiculous but happens sometimes) That happens a lot with webcams too. Given that these SoC systems will come with some board specific config anyways, all that is needed is to pass some boardconfig in to the camera driver (through platform data for example) which tells the camera driver that on this board the sensor is mounted upside down. So in that case when we query orientation of camera, it returns not flipped vertically or horizontally at all but actually it turns out to be upside down. Actually we are setting camera device to be flipped for default in that case. Ack, but the right thing to do is not to set the vflip and hflip video4linux2 controls on by default, but to invert their meaning, so when the sensor is upside down, the hflip and vflip controls as seen by the application through the v4l2 API will report not flipping, but the hwcontrols will actually be set to flipping, and when an app enables flipping at the v4l2 API level it will actually gets disables at the HW level, this way the upside downness is 100% hidden from userspace. So your problem does not need any of the new API we are working on. The new API is for when the hardware cannot flip and we need to tell userspace to correct for this in software. Regards, Hans -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Thank you for your comment.
BTW, what should I do if I would rather use external ISP device than
OMAP3 internal ISP feature?
You said that you just have raw sensors by now, so you mean this patch
is not verified working with some ISP modules?
I'm testing your patch on my own omap3 target board with NEC ISP...but
unfortunately not working yet ;(
I should try more harder. more research is needed :)
Cheers,
On Thu, Feb 12, 2009 at 4:09 PM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
DongSoo Kim wrote:
Hello.
Hi, and thanks for the comments!
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
snip
+ if (atomic_inc_return(vdev-users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+
OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of sensor + ISP SOC camera modules, I2C command is not
working while the camera module is in standby mode.
I guess that applies to most sensors.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
You're right, there's something wrong with the slave power handling. :)
We were thinking that the sensor (or any slave) power management (current
on, off and standby) could be replaced by four commands: open, close,
streamon and streamoff. The slave could decide by itself what its real power
state is. IMO direct power management doesn't belong to the camera driver
which doesn't drive any hardware anyway.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like ISP for sensor+ISP SOC modules?
I currently have just raw sensors. It'd be nice to keep the interface for
smart sensors the same, though. You still need for a receiver for the image
data, sometimes called the camera controller. That would be the same than
the ISP but without fancy features.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
Dong Soo, Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello.
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
snip
+ if (atomic_inc_return(vdev-users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+ OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of sensor + ISP SOC camera modules, I2C command is not
working while the camera module is in standby mode.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like ISP for sensor+ISP SOC modules?
Then we could make slave devices with conditional cases.
Cheers.
Regards,
Nate
--
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: [V4L2] EV control API for digital camera
On 화, 2009-02-03 at 11:20 +0100, Laurent Pinchart wrote: Hi Nate, On Thursday 29 January 2009, Dongsoo Kim wrote: Thank you. So if V4L2_CID_EXPOSURE is for Exposure Value control, I think there is no api for exposure metering. right? V4L2_CID_EXPOSURE controls the exposure time. This is often implemented through a mechanical or electronic shutter in the device. What kind of exposure metering do you have in mind ? Can you give us some details ? I mean photometry which is all about light meter (or exposure meter). Like spot metering, center weighted things.. Actually many of APIs for camera are missing I guess. You're probably right. The V4L1/V4L2 API have been developed for frame grabbers and extended to webcams. Now that high-end digital cameras get USB connectivity, the V4L2 API should be extended with new controls. Feel free to submit proposals for discussion on the linux-media mailing list. Thank you for you encouraging words. Actually I'm working on some ISP devices from NEC, Fujitsu. and ARM SOC camera interface peripheral like PXA3, S3C64XX, OMAP3.. I wish I could make a device very close to a real digital camera. It wouldn't take so long until I submit a RFC about V4L2 API for digital camera :) (I hope so at least) Cheers. Regards, Nate -- 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
OMAP3430 camear ISP strobe control
Hello. Since I was working on OMAP3 camera driver with camera interface driver in OMAPZOOM repository, I could not figure it out how to control strobe device. I found that strobe control depends on CSI1 (MIPI)..but how could I control that? In my opinion, in case of OMAP3 ISP has to be made in v4l2 int device way. (of course new v4l2 int device commands should be made either) And also new V4L2 API should be made I guess...;( Anyone has any idea? -- 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: [V4L2] EV control API for digital camera
Thank you. So if V4L2_CID_EXPOSURE is for Exposure Value control, I think there is no api for exposure metering. right? Actually many of APIs for camera are missing I guess. Cheers Nate 2009. 01. 30, 오전 3:35, Guennadi Liakhovetski 작성: [removed redhat list from CC] On Thu, 29 Jan 2009, DongSoo Kim wrote: Hello. When we take pictures, sometimes we don't get satisfied with the exposure of picture. Too dark or too bright. For that reason, we need to bias EV which represents Exposure Value. So..if I want to control digital camera module with V4L2 API, which API should I take for EV control? V4L2 document says that V4L2_CID_BRIGHTNESS is for picture brightness, but it is for Image properties and that image means the image frame of TV or PVR things.Am I right? There's also V4L2_CID_EXPOSURE If I may, can I use V4L2_CID_BRIGHTNESS for EV control of digital cameras? or..otherwise I should make a new API for that functionality. I'm little bit confused, because I think the brightness of picture could differ from exposure value of digital camera..help me ;( Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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
[V4L2] EV control API for digital camera
Hello. When we take pictures, sometimes we don't get satisfied with the exposure of picture. Too dark or too bright. For that reason, we need to bias EV which represents Exposure Value. So..if I want to control digital camera module with V4L2 API, which API should I take for EV control? V4L2 document says that V4L2_CID_BRIGHTNESS is for picture brightness, but it is for Image properties and that image means the image frame of TV or PVR things.Am I right? If I may, can I use V4L2_CID_BRIGHTNESS for EV control of digital cameras? or..otherwise I should make a new API for that functionality. I'm little bit confused, because I think the brightness of picture could differ from exposure value of digital camera..help me ;( Regards. Nate -- Dong Soo, Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
Re: [PATCHv2] New V4L2 ioctls for OMAP class of Devices
Hello.
+#define VIDIOC_S_COLOR_SPACE_CONV _IOW('V', 83, struct
v4l2_color_space_conversion)
+#define VIDIOC_G_COLOR_SPACE_CONV _IOR('V', 84, struct
v4l2_color_space_conversion)
Do you mind if I ask a question about those ioctls?
Because as far as I understand, we can use VIDIOC_S_FMT ioctl to convert
colorspaces. Setting through colorspace member in v4l2_pix_format, we
could change output colorspace.
If there is some different use, can you tell me what it is?
Regards,
Nate
--
Dong Soo, Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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
Re: Any rules in making ioctl or cids?
Thank you Mauro. I finally got it what to do. I'll figure it out how to make it easier to control strobe lights through CIDs. Try to avoid creating newer ioctls is the same I think. Cheers, Nate On Fri, Jan 9, 2009 at 1:18 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Fri, 9 Jan 2009 12:20:16 +0900 DongSoo Kim dongsoo@gmail.com wrote: Hello everyone. I'm facing with some questions about Can I make it ioctl or CID? For most cases, creating a control (CID) is better than using another ioctl. Because if I make it in ioctl It should occupy one of the extra ioctl number for v4l2, and I'm afraid it deserves that. Actually I'm working on strobe flash device (like xenon flash, LED flash and so on...) for digital camera. And in my opinion it looks good in v4l2 than in misc device. (or..is there some subsystems for strobe light? sorry I can't find it yet) As far as I understand, having this on V4L2 would be better. As far as I worked on, strobe light seems to be more easy to control over ioctl than CID. Since we need to check its status (like not charged, turned off etc..). v4l2 controls can be used also to read. You may even group several different controls into one get or set request. But here is the thing. Is that really worthy of occupying an ioctl number for v4l2? Can I use extra ioctl numbers as many as I like for v4l2 if It is reasonable? Can I have a rule if there is a rule for that? There's no rule, but we generally try to avoid creating newer ioctls. It is not forbidden to create, but we need to take some care with. Cheers, Mauro -- Dong Soo, Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
[linux-v4l] Some questions about v4l2 exposure control on camera device
Hello V4L2 people. I'm working on camera device drivers over 5M pixel and made drivers based on V4L2 API. Actually I'm still working on it. By the way, I have some questions in exposure control. If my guess is right, V4L2_CID_EXPOSURE_* CIDs are what I'm looking for. Control factors that I intend to handle for exposure are like following. 1. Shutter speed 2. Iris (F-number) 3. ISO(sensor gain) And found out using V4L2_CID_EXPOSURE_AUTO I could change exposure mode. But here is the thing. What should I supposed to do if I need to control iris F-number when I set V4L2_EXPOSURE_MANUAL or V4L2_EXPOSURE_APARTURE_PRIORITY? I see that it is possible to control shutter speed using V4L2_CID_EXPOSURE_ABSOLUTE but what can I do for iris? cannot find out. And one more thing. If I set exposure mode to V4L2_EXPOSURE_MANUAL, it means that it is necessary to control in manual iris, shutter, and even ISO sometimes. According to videodev2.h I guess we have only V4L2_CID_EXPOSURE_ABSOLUTE to control shutter speed. Is there any cool way to set in manual way with shutter speed, iris, and even ISO at once? If there is no way, how about making a new API for that? At any rate, I need an API for exposure (a exposure like a real camera...shutter, iris things) so... I think I've gotta make something for that. If somebody is working on it, can we discuss together about this issue? If you don't mind. Regards, Nate -- Dong Soo, Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com Anycall : 010-9530-0296 Homepage : http://www.kdsoo.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
