Request to accept camera recipes in meta-qcom

[gkhose-qipl]

To enable GST camera functionality, camera recipes need to be included in meta-qcom, as GST depends on the camera. For GST to access all developer touch point APIs of the camera, meta-qcom should have the camera recipes. camera recipes cannot be validated using other upstream camera frameworks. Please assist in accepting the camera recipes as part of meta-qcom without validation through any upstream application. Camera recipes are tested using an internal proprietary app to ensure camera functionality, so GST will not encounter issues related to camera pipelines or features.

[lumag]

I assume you are talking about CamX. Please provide a testing app that can be executed as a part of the CI (later) or that can be executed by the devlopers in order to test CamX functionality.

Note: there are usual requirements that we discussed before. R/O rootfs should work with your modules, The qcom-armv8a platform should work, etc. The modules and userspace for various platforms should be able to coexist, etc.

[ricardosalveti]

We need to have a way to validate the camera recipes in public, as we need any developer to be able to perform such validation by using meta-qcom.

[sbanerjee-quic]

@gkhose-qipl as discussed
how does a user test camx standalone when building from meta-qcom? Can you provide a test app which helps capture preview and capture use cases?

• Idea if this test app can be a gst based app

[sgujje-qipl]

For Camera, developer touch point is GST on top of QMMF camera service which will be delivered in November .
Once this changes are available in meta-qcom camx recipes can be tested with GST.
Providing another test app on top of camx will open another touchpoint which we want to avoid

[lumag]

Then why do you want to get it in before it is useful to anybody?

[sgujje-qipl]

For time being we want to ship proprietary NHX binary and once GST is enabled we want remove NHX binary is this approach works ?

• Now: NHX binary only
• Later: GST app
• Further ahead: retire NHX

[ndechesne]

What are the timelines for the GST app to be available?

[sgujje-qipl]

As per GST team Nov end is the time line

[lumag]

I don't know what NHX means, but why can't we provide it as an open-source example and retain it even after getting the Gstreamer plugins?

[sgujje-qipl]

NHX is Native Hal test app which is for internal app to validate camx stack , for the end user this is not a touch point. Actual touch point is GST app.

[lumag]

I don't get the definition of the 'touch point'. But especially if it is a test app, we should open source it. People will use it when porting to a new device in order to check that cameras are working. Gstreamer might be too high-level for that task.

[sgujje-qipl]

NHX is above camx HAL layer , Its internal test app and this is not the one which we are exposing to the customer .

[lumag]

There were no "customers" in my sentence. A DIY engineer enabling new sensor on a UNO Q board is a use case to keep in mind.

[gkhose-qipl]

For sensor driver development, we need CHICKDK in source form, which is only available for FRU (Fully Registered User). Therefore. DIY engineers will need to collaborate with a Qualcomm approved sensor partner.

[lumag]

The sensor partner can provide config/library/data/etc. for the sensor. However the DIY engineer still performs the final hardware and software integration. This includes testing and solving the isuses. Gstreamer might be too high level for that.

Also, I think that not letting users to create their own sensor setup is a significant mistake. We should let our users to integrate the sensors of their choice.