Re: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 26 July 2010 18:12:55 Laurent Pinchart wrote:
> On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote:
> > Laurent,
> > 
> > Could you explain the probe and active usage using an example such as
> > below?
> > 
> >             Link1    Link2
> > input sensor -> ccdc -> video node.
> > 
> > Assume Link2 we can have either format 1 or format 2 for capture.
> 
> Sure.
> 
> The probe and active formats are used to probe supported formats and 
> getting/setting active formats.

Just to verify: we are dealing with mediabus formats here, right?

One thing that I don't like is the name 'probe'. I would prefer the name
'proposed'. You propose an input format and based on that you can enumerate
a list of proposed output format. I think that name fits better than 'probe'
which I find confusing in this context.

> 
> * Enumerating supported formats on the CCDC input and output would be done 
> with the following calls
> 
> ENUM_FMT(CCDC input pad)
> 
> for the input, and
> 
> S_FMT(PROBE, CCDC input pad, format)
> ENUM_FMT(CCDC output pad)
> 
> for the output.

How does ENUM_FMT know if it has to use the proposed or actual input formats?
Or is it supposed to always act on proposed formats?

> 
> Setting the probe format on the input pad is required, as the format on an 
> output pad usually depends on the format on input pads.
> 
> * Trying a format on the CCDC input and output would be done with
> 
> S_FMT(PROBE, CCDC input pad, format)
> 
> for the input, and
> 
> S_FMT(PROBE, CCDC input pad, format)
> S_FMT(PROBE, CCDC output pad, format)
> 
> on the output. The S_FMT call will mangle the format given format if it can't 
> be supported exactly, so there's no need to call G_FMT after S_FMT (a G_FMT 
> call following a S_FMT call will return the same format as the S_FMT call).
> 
> * Setting the active format is done with
> 
> S_FMT(ACTIVE, CCDC input pad, format)
> S_FMT(ACTIVE, CCDC output pad, format)
> 
> The formats will be applied to the hardware (possibly with a delay, drivers 
> can delay register writes until STREAMON for instance).
> 
> Probe formats are stored in the subdev file handles, so two applications 
> trying formats at the same time will not interfere with each other. Active 
> formats are stored in the device structure, so modifications done by an 
> application are visible to other applications.
> 
> Hope this helps clarifying the API.

You know that I have never been happy with this approach, but I also have to
admit that I haven't found a better way of doing it.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux