Location: Add header-only recipes by quic-vthuniki · Pull Request #2277 · qualcomm-linux/meta-qcom

quic-vthuniki · 2026-05-24T16:57:58Z

Add initial header-only recipes (loc-pla-hdr and location-api-iface) for the location module.
These are added first so that subsequent recipes can include them as dependencies.

Add initial header-only recipes for location module Signed-off-by: Vamana Murthi <vthuniki@qti.qualcomm.com>

lumag

It's recipes-navigation rather than recipes-location.
What are the users for these headers?

lumag · 2026-05-24T17:08:49Z

+# Common bitbake recipe information for location meta layer.
+# Below are common values, statements and functions.
+
+PACKAGE_ARCH    ?= "${TUNE_PKGARCH}"


This is definitely not worth having a separate include. Fold it in annd provide an explanation, why it is required. BTW, why?

why?

This seem redundant, I will fix it.
From my initial experiments, PACKAGE_ARCH was influencing the naming of the generated tar files for proprietary modules. I was informed that the tar artifacts needed to be aligned with the armv8 architecture. Hence i explicitly set PACKAGE_ARCH to ${TUNE_PKGARCH}.

However, after further validation, I confirmed that when not explicitly set, the default PACKAGE_ARCH already resolves to the appropriate armv8 value. So this assignment is redundant, and I’ll remove it in the next update.

definitely not worth having a separate include

My baseline code is common between Android and LE.
In my follow-on PRs, there are recipes where we need to define a few CFLAGS that are used in the source code to differentiate parts of the code between Android and LE, and to enable some inlines/macros specific to the LE baseline. For that, we are using this .inc file to define those configurations.

example:
EXTRA_OECONF = " --with-glib"
code ref:
https://git.codelinaro.org/clo/le/platform/hardware/qcom/gps/-/blob/location.lnx.0.0/utils/log_util.h?ref_type=heads#L78

Without the GLIB macro defined, I ran into an undefined macro error for ALOGE.

# compiler flag to identify QClinux target CFLAGS:append = " -DLOC_QCLINUX_TARGET " CPPFLAGS:append = " -DLOC_QCLINUX_TARGET "

There are some code compile decisions based on these CFLAGS.
https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/location/-/blob/location.lnx.8.5.r1-rel/client_api_testapp/main.cpp?ref_type=heads#L2655

Hence, I wanted to retain this file in the initial phase.

No. Add that file when actually necessary rather than when thinking that it will be necessary in future (which might never come). Also be sure that you correctly split flags between CFLAGS and CPPFLAGS. Having the same flag in both is a definite mistake. CFLAGS should be used for the flags specific to the C compiler. All preprocessor options (-I, -D, etc.) should go to CPPFLAGS.

lumag · 2026-05-24T17:10:48Z

@@ -0,0 +1,3 @@
+# include for recipe files which require BSD-3-Clause license
+LICENSE = "BSD-3-Clause-Clear"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/BSD-3-Clause-Clear;md5=7a434440b651f4a472ca93716d01033a"


NAK. Inline it and checksum the actual license file in the source tree.

I checked how this is handled in other modules (e.g., recipes-multimedia/camx/camx-dlkm) and will update this accordingly.
My only concern is that github repository is currently undergoing LOST scanning, and it may take some time before the repo is created and license file can be added to the source tree.
In the meantime, I would appreciate your guidance on how you would prefer me to proceed, so that the follow-on recipes can continue to be reviewed without delay.

Rewrite SRC_URI to inline format to align with Yocto style guidelines and improve readability Signed-off-by: Vamana Murthi <vthuniki@qti.qualcomm.com>

github-actions · 2026-05-24T20:22:43Z

Test run workflow

Test jobs for commit `1a34110`

qcom-distro
Pass: 252 | Fail: 2 | Total: 278

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 223 | Fail: 3 | Total: 244

test-reporting-app · 2026-05-24T20:23:19Z

Test Results

103 files ±0 634 suites +2 6h 56m 45s ⏱️ + 8m 5s
132 tests +3 101 ✅ +1 2 💤 +2 29 ❌ ±0
6 011 runs +3 5 929 ✅ +3 46 💤 - 1 36 ❌ +1

For more details on these failures, see this check.

Results for commit 1a34110. ± Comparison against base commit c66b499.

anujm1 · 2026-05-25T01:19:34Z

+require include/common-location-defines.inc
+require include/location-license-bsd3-clause.inc
+
+DESCRIPTION = "GPS Loc Platform Library Abstraction"


Please provide a proper SUMMARY and DESCRIPTION in both recipes.

Sure, i will update it

anujm1 · 2026-05-25T01:21:49Z

+DESCRIPTION = "GPS Loc Platform Library Abstraction"
+
+SRC_URI = "git://git.codelinaro.org/clo/le/platform/hardware/qcom/gps.git;protocol=https;branch=location.lnx.0.0;destsuffix=hardware/qcom/gps"
+SRCREV  = "18cec4cd877f758292f5252d47c755b50f2838b3"


What is the version here?

I had taken these recipes as base from QLI 1.0. If the suggestion is to avoid revision based repo clone and always work on tip, we are okay.
Please help confirm if we need to always work on tip of the repo?

The suggestion is to have tags, organizing the repo contents and repo changes.

anujm1 · 2026-05-25T01:23:10Z

+
+DESCRIPTION = "GPS Loc Platform Library Abstraction"
+
+SRC_URI = "git://git.codelinaro.org/clo/le/platform/hardware/qcom/gps.git;protocol=https;branch=location.lnx.0.0;destsuffix=hardware/qcom/gps"


Why do we need to clone to destsuffix here if it's a separate recipe?

This was added mainly for readability and to follow a consistent convention. If you prefer to avoid it, I can remove it. Alternatively, can i take this up as part of a separate cleanup activity as all of our recipes have the similiar pattern

Please avoid the destdir unless required.

anujm1 · 2026-05-25T01:29:21Z

+
+DESCRIPTION = "location api interface"
+
+SRC_URI = "git://git.codelinaro.org/clo/le/platform/hardware/qcom/gps.git;protocol=https;branch=location.lnx.0.0;destsuffix=hardware/qcom/gps"


Why do we need two recipes for packing headers for this same project? Why do we need to manually copy them?

Reason for having separate recipe files comes from the Android build system, which was used as a reference in our legacy code. The same approach has been carried forward by the team into LE as well.
I agree that we can consolidate some of these and reduce the number of recipe files overall. However, I would prefer to take that up as a follow-up improvement/optimization.
For now, the goal is to enable the baseline with minimal changes to the existing recipe structure.

prefer to take that up as a follow-up improvement/optimization.

Why? Please make it good from the beginning.

Sure, we are looking at the options to reduce the number of recipes which are header only and combine them into a single recipe. I will get back with proposal

lumag · 2026-05-25T09:08:41Z

The major question from my side would be, why are we bring the whole HAL from Android? Can't we use a native implementation in style of https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-navigation/gpsd/gpsd/0001-Introduce-Qualcomm-PDS-service-support.patch ?

quic-vthuniki · 2026-05-25T11:20:28Z

The major question from my side would be, why are we bring the whole HAL from Android

The HAL repository is a common codebase shared between Android and LE, and we have maintained it this way to maximize code reuse across different software platforms.
While the QLI repo itself is not currently shared with Android, its baseline is derived from a common branch that supports both Android and LE.
From a source code perspective, the repository is not strictly Android-specific—it contains a significant amount of native code. For LE, we selectively build only the required modules from this repository.

Can't we use a native implementation in style of https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-navigation/gpsd/gpsd/0001-Introduce-Qualcomm-PDS-service-support.patch

The referenced approach appears to use the QRTR module directly. However, we have certain proprietary features that depend on shared modules from the HAL. These features cannot be supported purely using QRTR- or QMI-based implementations alone.

lumag · 2026-05-25T11:30:35Z

Can't we use a native implementation in style of https://github.com/qualcomm-linux/meta-qcom/blob/master/dynamic-layers/openembedded-layer/recipes-navigation/gpsd/gpsd/0001-Introduce-Qualcomm-PDS-service-support.patch

The referenced approach appears to use the QRTR module directly. However, we have certain proprietary features that depend on shared modules from the HAL. These features cannot be supported purely using QRTR- or QMI-based implementations alone.

Features, such as...? How are they controlled / implemented? Can they be supported separately? Why do they depend on HAL modules?

quic-vthuniki · 2026-05-26T08:25:17Z

It's recipes-navigation rather than recipes-location.
What are the users for these headers?

GPSd is part of recipes-navigation.
In contrast, recipes-location brings in the LCA(Location Client API) SDK, which offers a parallel interface for location capabilities, similar to GPSd.

Features, such as...? How are they controlled / implemented? Can they be supported separately? Why do they depend on HAL modules?

These are some of the high-level features supported through the LCA SDK:

GNSS assistance data download (proprietary feature)
Multiplexing of multiple client requests
Location batching
Geofencing
Network-based positioning^
ATL call bring-up for AGPS^

^these features are not part of the current POR. However, we do receive PdM/customer requests to enable them, and we plan to bring in only the required modules accordingly.

Although both GPSd(with 0001-Introduce-Qualcomm-PDS-service-support.patch) and LCA use QMI interface, our exisiting customers currently rely on the LCA SDK. Therefore, we are prioritizing LCA enablement in QLI 2.0.

Support for applicable features through GPSd is also planned, but will be handled as a separate effort.

lumag · 2026-05-27T08:45:37Z

It's recipes-navigation rather than recipes-location.
What are the users for these headers?

GPSd is part of recipes-navigation. In contrast, recipes-location brings in the LCA(Location Client API) SDK, which offers a parallel interface for location capabilities, similar to GPSd.

It's still navigation. As such, use recipes-navigation subdir.

Features, such as...? How are they controlled / implemented? Can they be supported separately? Why do they depend on HAL modules?

These are some of the high-level features supported through the LCA SDK:

GNSS assistance data download (proprietary feature)

It's implemented in other software tools too.

Multiplexing of multiple client requests

Gpsd provides broadcasting of the NMEA data to multiple clients, if that's what you mean here.

Location batching

Geofencing

Network-based positioning^

ATL call bring-up for AGPS^

^these features are not part of the current POR. However, we do receive PdM/customer requests to enable them, and we plan to bring in only the required modules accordingly.

Although both GPSd(with 0001-Introduce-Qualcomm-PDS-service-support.patch) and LCA use QMI interface, our exisiting customers currently rely on the LCA SDK. Therefore, we are prioritizing LCA enablement in QLI 2.0.

Support for applicable features through GPSd is also planned, but will be handled as a separate effort.

Let's schedule a meeting, discussing possible development plans and pitfalls.

Location: Add header-only recipes

dcaefb6

Add initial header-only recipes for location module Signed-off-by: Vamana Murthi <vthuniki@qti.qualcomm.com>

quic-vthuniki requested review from anujm1, koenkooi, lumag, ndechesne, ricardosalveti, sbanerjeeqc and vkraleti as code owners May 24, 2026 16:57

lumag requested changes May 24, 2026

View reviewed changes

Rewrite SRC_URI to inline format

1a34110

Rewrite SRC_URI to inline format to align with Yocto style guidelines and improve readability Signed-off-by: Vamana Murthi <vthuniki@qti.qualcomm.com>

anujm1 reviewed May 25, 2026

View reviewed changes


		DESCRIPTION = "GPS Loc Platform Library Abstraction"

		SRC_URI = "git://git.codelinaro.org/clo/le/platform/hardware/qcom/gps.git;protocol=https;branch=location.lnx.0.0;destsuffix=hardware/qcom/gps"


		DESCRIPTION = "location api interface"

		SRC_URI = "git://git.codelinaro.org/clo/le/platform/hardware/qcom/gps.git;protocol=https;branch=location.lnx.0.0;destsuffix=hardware/qcom/gps"

Conversation

quic-vthuniki commented May 24, 2026

Uh oh!

lumag left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 24, 2026

Test run workflow

Test jobs for commit 1a34110

Uh oh!

test-reporting-app Bot commented May 24, 2026

Test Results

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumag commented May 25, 2026

Uh oh!

quic-vthuniki commented May 25, 2026

Uh oh!

lumag commented May 25, 2026

Uh oh!

quic-vthuniki commented May 26, 2026

Uh oh!

lumag commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Test jobs for commit `1a34110`