Skip to content

Conversation

@gkhose-qipl
Copy link
Contributor

@gkhose-qipl gkhose-qipl commented Nov 20, 2025

The camx-common package provides foundational utility libraries that are shared across all components of the Qualcomm Camera X (CamX)
This package is separated from the main camx library as these utilities are required by both the core camx driver,
the CHI (Camera Hardware Interface) CDK framework, and various camera library components during their build process.
It includes three essential components: a settings manager for runtime configuration management, common utility functions for memory management and logging, and a hierarchical settings framework that combines platform-specific configs with common default configurations

Copy link
Contributor

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed the first recipe. Please apply that to all recipes in the PR

@@ -0,0 +1,21 @@
SUMMARY = "Qualcomm camera core driver and pipeline related libraries"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please write a proper commit message. Describe your design decisions, issues, etc. It should be a text, rather than a bullet list.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is still not addressed.

@@ -0,0 +1,21 @@
SUMMARY = "Qualcomm camera core driver and pipeline related libraries"
DESCRIPTION = "Collection of prebuilt libraries to support camera downstream functionality."
LICENSE = "CLOSED"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a proper license. It should actual use and distribution terms.

SRC_URI = "https://qartifactory-edge.qualcomm.com/artifactory/qsc_releases/software/chip/component/camx.qclinux.0.0/251120/prebuilt_yocto/${BPN}_${PV}_armv8-2a.tar.gz;subdir=${BPN}-${PV}"
SRC_URI[sha256sum] = "c0b2f23c0c87df6b113466b83948cf2baf80b38492e1899984193108a0bab8e3"

DEPENDS += "camxfirmware fastrpc protobuf-native protobuf protobuf-native libxml2 virtual/egl virtual/libgles2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, libs don't depend on the firmware. Especially not at the build time.

@ricardosalveti
Copy link
Contributor

Please break into more commits, one single commit adding a bunch of recipes is not ideal.

@gkhose-qipl gkhose-qipl force-pushed the camx_downstream branch 2 times, most recently from 64768be to 78cfd3c Compare November 20, 2025 20:39
@@ -0,0 +1,18 @@
SUMMARY = "Qualcomm camera development related libraries, binary"
DESCRIPTION = "Collection of prebuilt libraries to support camera downstream functionality."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary and description for most recipes are quite similar here, you should make it cover just this component (explain why it exists).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like, what chicdk even means?

@@ -0,0 +1,18 @@
SUMMARY = "Qualcomm camera development related libraries, binary"
DESCRIPTION = "Collection of prebuilt libraries to support camera downstream functionality."
LICENSE = "CLOSED"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need proper license.

Also add NOTICE (from the tarball) in LIC_FILES_CHKSUM.

@lumag
Copy link
Contributor

lumag commented Nov 21, 2025

Please. Test your changes before sending the PR. Building camxlib package fails with a lot of QA errors. I don't want to review nor test the half-backed solutions.

@lumag
Copy link
Contributor

lumag commented Nov 21, 2025

Also, please fix your build system:

..... in package camxlib doesn't have GNU_HASH

Copy link
Contributor

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On top of everything. Please rename the packages in a sensible way.
Instead of -kt use -kodiak. Likewise add sensible suffix to qcs9100-related packages.

@@ -0,0 +1,19 @@
SUMMARY = "Qualcomm camera common utility API used by camera driver"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This package includes files under /usr/lib/qcs9100/. Why are they a part of this package? Why is it split from camxlib?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we are definitely going to have several other versions of camx-something. Please name all packages according to platforms they support.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These comments were totally ignored.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still being ignored

@gkhose-qipl gkhose-qipl changed the title camx: add camera userspace libs camxcommon: package provide common utility API used by all CamX components Nov 22, 2025
@lumag
Copy link
Contributor

lumag commented Nov 26, 2025

  • package provide common utility API used by all CamX components
  • Contains shared utilities and helper code used across multiple CamX modules.
  • Provides common functionality such as logging, basic data structures, and configuration handling.
  • Helps reduce duplication by centralizing generic logic that does not belong to any single feature.
  • Offers small, focused components that can be reused without pulling in heavy dependencies.

Commit message, commit subject, package name, summary, description... Nothing changes, no improvememtns. Could you please fix those items for once?
For the commit subject. Does 'foo: add foo' sound good to you? I'd say, too many 'camxcommon' in one line.

We have tried to provide more descriptive commit messages. The discussion about the package name is still ongoing. I have added the summary and description, but could you clarify what exactly is expected for the summary and description?

Commit subject: what actually happens. `camxcommon: add libs common to foo, bar and baz'. Or 'used by foo, bar and baz'. Commit message: English text. Not a bullet list. Not a list of changes in the commit, we can read patches. Describe why it needs to be done and why it needs to be done this particular way.
Summary. It should be a one-line description of the package. Let's see "Qualcomm camera common utility API used by all CamX components". What does it tell me? Used by which components? Is it only for the Lemans or will it be common between the platforms? Again, why is it not a part of the main camx package? What's the difference? But okay, it is more of the topic for the description. This text (i.e. several sentences) should provide a more detailed description of the package. How does one tell, which CamX packages to install? Which recipes to use? Here it would be nice to explain what it is and why it is separated from the main camx lib package.

@gkhose-qipl
Copy link
Contributor Author

Of course not. What do v1, v2, v3 mean? Some virtual internal branches. So, no, it's not acceptable.

so what can be good way to name recipe. camx-kodiak, camx-talos , camx-lemans-monaco?
if we have x,y,z target and all are binary compatible recipe name should be camx-x-y-z?

@gkhose-qipl
Copy link
Contributor Author

Of course not. What do v1, v2, v3 mean? Some virtual internal branches. So, no, it's not acceptable.

so what can be good way to name recipe. camx-kodiak, camx-talos , camx-lemans-monaco? if we have x,y,z target and all are binary compatible recipe name should be camx-x-y-z?

if we need to use RPROVIDES , what should be recipe name ?
camx-lemans-monaco_1.0.1.bb
RPROVIDES:${PN} += "camx-qcs8100 camx-qcs9100"

@lumag
Copy link
Contributor

lumag commented Nov 28, 2025

Of course not. What do v1, v2, v3 mean? Some virtual internal branches. So, no, it's not acceptable.

so what can be good way to name recipe. camx-kodiak, camx-talos , camx-lemans-monaco? if we have x,y,z target and all are binary compatible recipe name should be camx-x-y-z?

if we need to use RPROVIDES , what should be recipe name ? camx-lemans-monaco_1.0.1.bb RPROVIDES:${PN} += "camx-qcs8100 camx-qcs9100"

camx-lemans_1.0.1.bb, RPROVIDES:${PN} = "camx-monaco"

@lumag
Copy link
Contributor

lumag commented Nov 28, 2025

As a side note I'll probably ask to use codenames for SoC subdirs. We have had enough troubles and confusion about qcs6490 vs qcs6490 vs sc7280, qrb5165 vs sm8250, etc. Using the codenames removes the topic as it points out that this CamX works for all kodiak instances, no matter if it is compute, mobile, IoT or something else.

@gkhose-qipl
Copy link
Contributor Author

As a side note I'll probably ask to use codenames for SoC subdirs. We have had enough troubles and confusion about qcs6490 vs qcs6490 vs sc7280, qrb5165 vs sm8250, etc. Using the codenames removes the topic as it points out that this CamX works for all kodiak instances, no matter if it is compute, mobile, IoT or something else.

Is the expectation described below correct, or do I need to update the approach?

  1. Recipe names: camx-kodiak, camx-lemans, camx-talos
  2. Installation paths: /usr/lib/qcm6490, /usr/lib/qcs9100, /usr/lib/qcs615
  3. The binary compatible libraries will be camx-lemans_1.0.1.bb, with RPROVIDES:${PN} = "camx-monaco", and since it's a virtual package, the libraries used will come from /usr/lib/qcs9100.

Copy link
Contributor

@lumag lumag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which cirtular dependnecies? Which compilation?? We are not building anything here.
CamX driver (aka DLKM) doesn't depend on any userspace components, so the commit message is not correct.
Last, but not least, please wrap your commit messages sensibly, at 72-75 chars boundary. If you are using ViM it does that for you. If you are using any other editor, please fix its configuration.

@lumag
Copy link
Contributor

lumag commented Dec 8, 2025

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

@gkhose-qipl
Copy link
Contributor Author

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

done, updated to 1.0.3 as last version was 1.0.2

@lumag
Copy link
Contributor

lumag commented Dec 9, 2025

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

done, updated to 1.0.3 as last version was 1.0.2

That's not an answer to the 'Why?' question.

@gkhose-qipl
Copy link
Contributor Author

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

done, updated to 1.0.3 as last version was 1.0.2

That's not an answer to the 'Why?' question.

@lumag ,
we initially kept the version as 1.0.0 to maintain a proper version history information. However, as per our discussion, updating the version to 1.0.3.
In HWE, we have the camx version as 1.0.0, and there are currently no recipes hosted in meta-qcom. Now that we've renamed the recipes in meta-qcom, we're starting the version from 1.0.3,

@lumag
Copy link
Contributor

lumag commented Dec 9, 2025

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

done, updated to 1.0.3 as last version was 1.0.2

That's not an answer to the 'Why?' question.

@lumag , we initially kept the version as 1.0.0 to maintain a proper version history information. However, as per our discussion, updating the version to 1.0.3. In HWE, we have the camx version as 1.0.0, and there are currently no recipes hosted in meta-qcom. Now that we've renamed the recipes in meta-qcom, we're starting the version from 1.0.3,

Why are you again talking about recipes? The question is about release versions.

@gkhose-qipl
Copy link
Contributor Author

Colleagues. I'm starting to be really angry. Why did the version go BACKWARDS??

done, updated to 1.0.3 as last version was 1.0.2

That's not an answer to the 'Why?' question.

@lumag , we initially kept the version as 1.0.0 to maintain a proper version history information. However, as per our discussion, updating the version to 1.0.3. In HWE, we have the camx version as 1.0.0, and there are currently no recipes hosted in meta-qcom. Now that we've renamed the recipes in meta-qcom, we're starting the version from 1.0.3,

Why are you again talking about recipes? The question is about release versions.

release version for all QLI release was 1.0.0 in hwe.

@github-actions
Copy link

github-actions bot commented Dec 9, 2025

Test run workflow

Test jobs for commit 57d0c52

@gkhose-qipl
Copy link
Contributor Author

@lumag / @ricardosalveti / @koenkooi ,
can you please help to review PR, we have address comments.

This package provides the foundational utility libraries shared across all \
components of the Qualcomm Camera X (CamX). It is separated \
from the main qcom-camx package to resolve build dependencies, as these \
utilities are required by camx, chi-cdk, and camx-lib during compilation."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, this doesn't make sense. We don't perform builds here.

It might help if you explain, what are the components. What is chi-cdk? Who uses it? What is the difference between camx and camx-lib? Doesn't camx depend on camx-lib? Does chi-cdk depend on camx? On camx-lib?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, explain here, in the comment (or in the commit message). Not in the package description.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, explain here, in the comment (or in the commit message). Not in the package description.

I'd say even the description here should be something that people with little background can understand when looking at just the description embedded in package, so no short forms if possible like chi-cdk.

Copy link
Contributor Author

@gkhose-qipl gkhose-qipl Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, this doesn't make sense. We don't perform builds here.

It might help if you explain, what are the components. What is chi-cdk? Who uses it? What is the difference between camx and camx-lib? Doesn't camx depend on camx-lib? Does chi-cdk depend on camx? On camx-lib?

Dependency flow.
camxcommon
camxlib (depends on camxcommon)
camx (depends on camxlib)
chicdk (depnds on camx)

chi-cdk:- (Camera Hardware Interface Customization Development Kit).

did not get "Who uses it? " can you please elaborate

from the main qcom-camx package as these utilities are required by camx, \
chi-cdk, and camx-lib during compilation."
LICENSE = "LICENSE.qcom-2"
LIC_FILES_CHKSUM = "file://${UNPACKDIR}/usr/share/doc/${BPN}/NO.LOGIN.BINARY.LICENSE.QTI.pdf;md5=7a5da794b857d786888bbf2b7b7529c8"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop the file://${UNPACKDIR}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure will update with below, is that fine ?
LIC_FILES_CHKSUM = "file://usr/share/doc/${BPN}/NO.LOGIN.BINARY.LICENSE.QTI.pdf;md5=7a5da794b857d786888bbf2b7b7529c8"

@github-actions
Copy link

Test run workflow

Test jobs for commit 5dafec0

The camx-common package provides foundational utility libraries that are
 shared across all components of the Qualcomm Camera X (CamX)
This package is separated from the main camx library as these utilities
 are required by both the core camx driver,
 the CHI (Camera Hardware Interface) CDK framework, and various camera
 library components during their build process.
It includes three essential components: a settings manager for runtime
 configuration management, common utility functions for memory management
 and logging, and a hierarchical settings framework that combines
 platform-specific configs with common default configurations.

Signed-off-by: Ganesh Khose <[email protected]>
@github-actions
Copy link

Test run workflow

Test jobs for commit b6d1da7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants