On Fri, 17 Apr 2009, Dongsoo, Nathaniel Kim wrote: > Hi Guennadi, > > > On Fri, Apr 17, 2009 at 4:58 AM, Guennadi Liakhovetski > <g.liakhovetski@xxxxxx> wrote: > > > > Ok, now I understand your comments to my soc-camera thread better. Now, > > what about making one (or more) video devices with V4L2_CAP_VIDEO_CAPTURE > > type and one with V4L2_CAP_VIDEO_OUTPUT? Then you can use your capture > > type devices to switch between cameras and to configure input, and your > > output device to configure preview? Then you can use soc-camera to control > > your capture devices (if you want to of course) and implement an output > > device directly. It should be a much simpler device, because it will not > > be communicating with the cameras and only modify various preview > > parameters. > > > > It's a cool idea! Adding my understanding to your comment, > > 1. make preview device a video output > => it makes sense. but codec path also has dedicated DMA to frame buffer. > What should we do with that? I have no idea by now. Add a V4L2_CAP_VIDEO_OVERLAY capability and if the user requests V4L2_BUF_TYPE_VIDEO_OVERLAY - configure direct output to framebuffer? > 2. preview device can have two inputs > a) input from camera device : ok it's an ordinary way > b) input from MSDMA : we can give RGB data upto 720P to preview > device with rotating and resizing supported > > Does it sound ok? Yes, looks good to me:-) > BTW, OMAP3 has similar feature with this. omap vout something? > And by now I'm gonna make my driver with soc camera subsystem without > VIDIOC_S_INPUT/G_INPUT, but I'm still desperate for that. Don't dispair - better send a patch when good times return (i.e., when we are fully with v4l2-subdev):-) 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
