Hi Pavel,

On Tuesday 14 Mar 2017 19:26:35 Pavel Machek wrote:

Hi!

quoted

quoted

Mid-layer is difficult... there are _hundreds_ of possible
pipeline setups. If it should live in kernel or in userspace is a
question... but I don't think having it in kernel helps in any way.

Mid-layer is difficult, because we either need to feed some
library with knowledge for all kernel drivers or we need to improve
the MC API to provide more details.

For example, several drivers used to expose entities via the
generic MEDIA_ENT_T_DEVNODE to represent entities of different

types. See, for example, entities 1, 5 and 7 (and others) at:

quoted

https://mchehab.fedorapeople.org/mc-next-gen/igepv2_omap3isp.png

Well... we provide enough information, so that device-specific code
does not have to be in kernel.

There are few types of ENT_T_DEVNODE there. "ISP CCP2" does not really
provide any functionality to the user. It just has to be there,
because the pipeline needs to be connected. "ISP Preview" provides
format conversion. "ISP Resizer" provides rescaling.

I'm not sure if it ever makes sense to use "ISP Preview
output". Normally you take data for display from "ISP Resizer
output". (Would there be some power advantage from that?)

There was a bug on the preview engine to resizer hardware bus in OMAP34xx that 
required capturing data from the preview engine output and performing the 
scaling in memory-to-memory mode in some cases. You can also capture at the 
preview engine output if you don't need scaling, or if you want to render on 
the image before scaling (to draw pieces of a GUI for instance). There could 
be other use cases.

quoted

A device-specific code could either be hardcoding the entity number
or checking for the entity strings to add some logic to setup
controls on those "unknown" entities, a generic app won't be able
to do anything with them, as it doesn't know what function(s) such
entity provide.

Generic app should know if it wants RGGB10 data, then it can use "ISP
CCDC output", or if it wants "cooked" data suitable for display, then
it wants to use "ISP Resizer output". Once application knows what
output it wants, there's just one path through the system. So being
able to tell the ENT_T_DEVNODEs apart does not seem to be critical.

OTOH, for useful camera application, different paths are needed at
different phases.

-- 
Regards,

Laurent Pinchart