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.kim@xxxxxxxxx>: > > 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 <hverkuil@xxxxxxxxx> 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
