Thread (12 messages) 12 messages, 6 authors, 2011-09-28

[PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

From: Gary Thomas <hidden>
Date: 2011-09-27 22:49:26
Also in: linux-media, linux-omap, lkml

On 2011-09-27 16:31, Mauro Carvalho Chehab wrote:
Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu:
quoted
quoted
-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
Sent: Friday, September 16, 2011 6:36 PM
To: Ravi, Deepthy
Cc: linux-media at vger.kernel.org; tony at atomide.com; linux at arm.linux.org.uk;
linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
kernel at vger.kernel.org; mchehab at infradead.org; g.liakhovetski at gmx.de;
Hiremath, Vaibhav
Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

Hi Deepthy,

On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
quoted
On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
quoted
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
quoted
From: Vaibhav Hiremath<redacted>

In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Why so ? Shouldn't it be queried on the subdev output pad directly ?
Because standard v4l2 application for analog devices will call these std
ioctls on the streaming device node. So it's done on /dev/video to make
the
quoted
existing apllication work.
Existing applications can't work with the OMAP3 ISP (and similar complex
embedded devices) without userspace support anyway, either in the form of
a
GStreamer element or a libv4l plugin. I still believe that analog video
standard operations should be added to the subdev pad operations and
exposed
through subdev device nodes, exactly as done with formats.
[Hiremath, Vaibhav] Laurent,

I completely agree with your point that, existing application will not work without setting links properly.
But I believe the assumption here is, media-controller should set the links (along with pad formants) and
all existing application should work as is. Isn't it?
Yes.
quoted
The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming...
Yes.
quoted
I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node.
Agreed. Standards selection should be done at device node, just like any other
device.
So how do you handle a part like the TVP5150 that is standard agnostic?
That device can sense the standard from the input signal and sets the
result appropriately.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help