Hi Tuukka,

I understand that it is a huge thing to support VIDIOC_S_INPUT.
But without that, we don't have any proper "V4L2" api to get
information about how many devices are attached to camera interface,
and names of input devices...and so on. Because VIDIOC_ENUMINPUT and
VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can refer
to sysfs, but using only single set of APIs like V4L2 looks more
decent.

What do you think about this?
If you think that it is a big burden, can I make a patch for this?
Cheers,

Nate

On Mon, Feb 23, 2009 at 5:50 PM, Tuukka.O Toivonen
<tuukka.o.toivo...@nokia.com> wrote:
> On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim wrote:
>> So, logically it does not make sense with making device nodes of every
>> single slave attached with OMAP3camera interface. Because they can't
>> be opened at the same time,even if it is possible it should not work
>> properly.
>>
>> So.. how about making only single device node like /dev/video0 for
>> OMAP3 camera interface and make it switchable through V4L2 API. Like
>> VIDIOC_S_INPUT?
>
> You are right that if the OMAP3 has several camera sensors attached
> to its camera interface, generally just one can be used at once.
>
> However, from user's perspective those are still distinct
> cameras. Many v4l2 applications don't support VIDIOC_S_INPUT
> or at least it will be more difficult to use than just pointing
> an app to the correct video device. Logically they are two
> independent cameras, which can't be used simultaneously
> due to HW restrictions.
>
> - Tuukka
>



-- 
========================================================
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo....@gmail.com
          dongsoo45....@samsung.com
========================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to