Re: About VIDIOC_G_OUTPUT/S_OUTPUT ?
Hello Hans, I took a look into ivtv driver but the VIDEO_SELECT_SOURCE doesn't fit in the feature that I was explaining. ivtv_passthrough_mode seems to be all about selecting input source not output. Am I right? But in my case, I have (1)external camera, (2)memory for input source and (1)memory, (2)LCD FIFO(like overlay) for output. It means that use case can be established like this: (A) using external camera for input and memory for output = memcpy the memory to framebuffer to display preview (B) using external camera for input and memory for output = memcpy the memory and save as a file (recording or snapshot). maybe the same case as (A) (C) using external camera for input and LCD FIFO for output = turn on the camera and will se preview with doing nothing further in userspace (like memcpy) (D) using memory for input source and memory for output = actually in this case we can use rotator feature of camera interface. so let the multimedia file go through the camera interface and rotate orientation. (E) using memory for input source and LCD FIFO for output = rotate multimedia file and display direct to LCD. So in this case, should I use VIDIOC_S_INPUT to select input and VIDIOC_S_OUTPUT to select output device? or I got in the wrong way in the first place(if VIDEO_SELECT_SOURCE is the right one for me) If the concept above fits in VIDIOC_S_OUTPUT then I think we need more type define because I think any of type defined is not matching feature of output to memory. Cheers, Nate 2009/5/22 Dongsoo Kim dongsoo@gmail.com: 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
Re: About VIDIOC_G_OUTPUT/S_OUTPUT ?
Thank you Hans, Thanks to you I got the point of selecting input and output is that only physical connection can make it. It is really helping. BTW, more I work on v4l2 more I need for decent documentation. I should rather make some porting guide and technical documents for other developers. Actually V4L2 specification should be serving more detailed information indeed. When I see some sort of [?] things in the API specification document, thousands of question marks starts floating in my brain ;-O Cheers, Nate 2009/5/26 Hans Verkuil hverk...@xs4all.nl: On Tuesday 26 May 2009 08:32:00 Dongsoo, Nathaniel Kim wrote: Hello Hans, I took a look into ivtv driver but the VIDEO_SELECT_SOURCE doesn't fit in the feature that I was explaining. ivtv_passthrough_mode seems to be all about selecting input source not output. Am I right? But in my case, I have (1)external camera, (2)memory for input source and (1)memory, (2)LCD FIFO(like overlay) for output. It means that use case can be established like this: (A) using external camera for input and memory for output = memcpy the memory to framebuffer to display preview (B) using external camera for input and memory for output = memcpy the memory and save as a file (recording or snapshot). maybe the same case as (A) This is the same as A. (C) using external camera for input and LCD FIFO for output = turn on the camera and will se preview with doing nothing further in userspace (like memcpy) For this you need VIDEO_SELECT_SOURCE. (D) using memory for input source and memory for output = actually in this case we can use rotator feature of camera interface. so let the multimedia file go through the camera interface and rotate orientation. (E) using memory for input source and LCD FIFO for output = rotate multimedia file and display direct to LCD. Do D and E both go through the rotator feature of the camera interface? Anyway D sounds more like the proposed omap scaler device: basically a codec device. Anyway, based on this description S_INPUT has only one input: the camera. And S_OUTPUT has only the LCD as it's output. Those are the only physical connections. VIDEO_SELECT_SOURCE allows you to shortcut the two. It does not have anything to do with selecting the input or output. It just tells the driver to not use memory as its source/destination (which is the default behavior at all times), but connect the input and output together internally. Hope this helps. Regards, Hans So in this case, should I use VIDIOC_S_INPUT to select input and VIDIOC_S_OUTPUT to select output device? or I got in the wrong way in the first place(if VIDEO_SELECT_SOURCE is the right one for me) If the concept above fits in VIDIOC_S_OUTPUT then I think we need more type define because I think any of type defined is not matching feature of output to memory. Cheers, Nate 2009/5/22 Dongsoo Kim dongsoo@gmail.com: 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.
Re: About VIDIOC_G_OUTPUT/S_OUTPUT ?
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. 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. 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: 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: About VIDIOC_G_OUTPUT/S_OUTPUT ?
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? 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. 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. 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. 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: About VIDIOC_G_OUTPUT/S_OUTPUT ?
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? 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. 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. 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. Cheers, Nate 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
About VIDIOC_G_OUTPUT/S_OUTPUT ?
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... Cheers, Nate -- = 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
