| Message ID | 20250211075813.970579-1-y-abhilashchandra@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Ryan Eatmon |
| Headers | show |
| Series | [meta-arago,master/scarthgap] meta-arago-extras: v4l-utils: Add recipe for v1.28.1 | expand |
On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra via lists.yoctoproject.org wrote: > An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer > for scarthgap. > > TI's 6.12 based kernel has backported multistream routing APIs from > upstream kernel, which requires v4l-utils to be the latest released > version (v1.28.1). > > Thus we override the recipe in this layer to the latest release of > v4l-utils. There are few issues with this... Do you really need to override the entire recipe? The old .bbappend was applying a patch already - can you add a new patch to that and bump SRCREV? If you do need to override the entire recipe, then you first need to clearly articulate your reason in the commit log - wanting a newer commit isn't such a reason Then you need to do it in 2 steps/patches - first you copy over the existing recipe verbatim w/o any modifications, and in a separate step make your modifications Also, having own copy of an upstream recipe requires special attention to not violate the Yocto Project Compatible guidelines. I've explained this recently in another thread here on the list
On 12/02/25 02:21, Denys Dmytriyenko wrote: > On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra via lists.yoctoproject.org wrote: >> An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer >> for scarthgap. >> >> TI's 6.12 based kernel has backported multistream routing APIs from >> upstream kernel, which requires v4l-utils to be the latest released >> version (v1.28.1). >> >> Thus we override the recipe in this layer to the latest release of >> v4l-utils. > > There are few issues with this... > > Do you really need to override the entire recipe? The old .bbappend was > applying a patch already - can you add a new patch to that and bump SRCREV? > We are not only updating the SRCREV, but also moving to a newer branch (stable-1.28), which is why we considered overriding the entire recipe. This approach aligns with how we have handled previously, including 6.1 timeline, where we followed a similar process.[1] Given that the original recipe package still references an older version, do you suggest that we update the branch in the existing .bbappend, even though the base recipe remains on an older version? Please let me know if you want me to do that way. [1]: https://lore.kernel.org/all/20230525104036.2050245-1-j-luthra@ti.com/ Thanks, Yemike Abhilash Chandra > If you do need to override the entire recipe, then you first need to clearly > articulate your reason in the commit log - wanting a newer commit isn't such > a reason > > Then you need to do it in 2 steps/patches - first you copy over the existing > recipe verbatim w/o any modifications, and in a separate step make your > modifications > > Also, having own copy of an upstream recipe requires special attention to not > violate the Yocto Project Compatible guidelines. I've explained this recently > in another thread here on the list >
Hello everyone, I have provided my response regarding the concerns raised. Since I haven’t heard back, I wanted to check if you had any further thoughts. Please let me know how you'd like to proceed. Thanks and Regards, Yemike Abhilash Chandra. On 12/02/25 13:46, Yemike Abhilash Chandra wrote: > > > On 12/02/25 02:21, Denys Dmytriyenko wrote: >> On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra via >> lists.yoctoproject.org wrote: >>> An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer >>> for scarthgap. >>> >>> TI's 6.12 based kernel has backported multistream routing APIs from >>> upstream kernel, which requires v4l-utils to be the latest released >>> version (v1.28.1). >>> >>> Thus we override the recipe in this layer to the latest release of >>> v4l-utils. >> >> There are few issues with this... >> >> Do you really need to override the entire recipe? The old .bbappend was >> applying a patch already - can you add a new patch to that and bump >> SRCREV? >> > > We are not only updating the SRCREV, but also moving to a newer branch > (stable-1.28), which is why we considered overriding the entire recipe. > This approach aligns with how we have handled previously, including > 6.1 timeline, where we followed a similar process.[1] > > Given that the original recipe package still references an older version, > do you suggest that we update the branch in the existing .bbappend, > even though the base recipe remains on an older version? > > Please let me know if you want me to do that way. > > [1]: https://lore.kernel.org/all/20230525104036.2050245-1-j-luthra@ti.com/ > > Thanks, > Yemike Abhilash Chandra > >> If you do need to override the entire recipe, then you first need to >> clearly >> articulate your reason in the commit log - wanting a newer commit >> isn't such >> a reason >> >> Then you need to do it in 2 steps/patches - first you copy over the >> existing >> recipe verbatim w/o any modifications, and in a separate step make your >> modifications >> >> Also, having own copy of an upstream recipe requires special attention >> to not >> violate the Yocto Project Compatible guidelines. I've explained this >> recently >> in another thread here on the list >>
On 2/16/2025 11:48 PM, Yemike Abhilash Chandra wrote: > Hello everyone, > > I have provided my response regarding the concerns raised. > Since I haven’t heard back, I wanted to check if you had > any further thoughts. > > Please let me know how you'd like to proceed. One final question... You said that this patch is for master as well, but I'm seeing a collision between this and the same recipe from meta-openembedded on master. Should this patch be applied to master? Or is the meta-openembedded version good enough? > Thanks and Regards, > Yemike Abhilash Chandra. > > On 12/02/25 13:46, Yemike Abhilash Chandra wrote: >> >> >> On 12/02/25 02:21, Denys Dmytriyenko wrote: >>> On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra via >>> lists.yoctoproject.org wrote: >>>> An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer >>>> for scarthgap. >>>> >>>> TI's 6.12 based kernel has backported multistream routing APIs from >>>> upstream kernel, which requires v4l-utils to be the latest released >>>> version (v1.28.1). >>>> >>>> Thus we override the recipe in this layer to the latest release of >>>> v4l-utils. >>> >>> There are few issues with this... >>> >>> Do you really need to override the entire recipe? The old .bbappend was >>> applying a patch already - can you add a new patch to that and bump >>> SRCREV? >>> >> >> We are not only updating the SRCREV, but also moving to a newer branch >> (stable-1.28), which is why we considered overriding the entire recipe. >> This approach aligns with how we have handled previously, including >> 6.1 timeline, where we followed a similar process.[1] >> >> Given that the original recipe package still references an older version, >> do you suggest that we update the branch in the existing .bbappend, >> even though the base recipe remains on an older version? >> >> Please let me know if you want me to do that way. >> >> [1]: >> https://lore.kernel.org/all/20230525104036.2050245-1-j-luthra@ti.com/ >> >> Thanks, >> Yemike Abhilash Chandra >> >>> If you do need to override the entire recipe, then you first need to >>> clearly >>> articulate your reason in the commit log - wanting a newer commit >>> isn't such >>> a reason >>> >>> Then you need to do it in 2 steps/patches - first you copy over the >>> existing >>> recipe verbatim w/o any modifications, and in a separate step make your >>> modifications >>> >>> Also, having own copy of an upstream recipe requires special >>> attention to not >>> violate the Yocto Project Compatible guidelines. I've explained this >>> recently >>> in another thread here on the list >>>
Hi Ryan, On 26/02/25 21:04, Ryan Eatmon wrote: > > > On 2/16/2025 11:48 PM, Yemike Abhilash Chandra wrote: >> Hello everyone, >> >> I have provided my response regarding the concerns raised. >> Since I haven’t heard back, I wanted to check if you had >> any further thoughts. >> >> Please let me know how you'd like to proceed. > > One final question... You said that this patch is for master as well, > but I'm seeing a collision between this and the same recipe from > meta-openembedded on master. Should this patch be applied to master? Or > is the meta-openembedded version good enough? > Yes, the master branch of meta-openembedded has the latest version. Please skip this patch for the master branch. The meta-openembedded version is good enough. Thanks and Regards Yemike Abhilash Chandra > > >> Thanks and Regards, >> Yemike Abhilash Chandra. >> >> On 12/02/25 13:46, Yemike Abhilash Chandra wrote: >>> >>> >>> On 12/02/25 02:21, Denys Dmytriyenko wrote: >>>> On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra >>>> via lists.yoctoproject.org wrote: >>>>> An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer >>>>> for scarthgap. >>>>> >>>>> TI's 6.12 based kernel has backported multistream routing APIs from >>>>> upstream kernel, which requires v4l-utils to be the latest released >>>>> version (v1.28.1). >>>>> >>>>> Thus we override the recipe in this layer to the latest release of >>>>> v4l-utils. >>>> >>>> There are few issues with this... >>>> >>>> Do you really need to override the entire recipe? The old .bbappend was >>>> applying a patch already - can you add a new patch to that and bump >>>> SRCREV? >>>> >>> >>> We are not only updating the SRCREV, but also moving to a newer branch >>> (stable-1.28), which is why we considered overriding the entire recipe. >>> This approach aligns with how we have handled previously, including >>> 6.1 timeline, where we followed a similar process.[1] >>> >>> Given that the original recipe package still references an older >>> version, >>> do you suggest that we update the branch in the existing .bbappend, >>> even though the base recipe remains on an older version? >>> >>> Please let me know if you want me to do that way. >>> >>> [1]: >>> https://lore.kernel.org/all/20230525104036.2050245-1-j-luthra@ti.com/ >>> >>> Thanks, >>> Yemike Abhilash Chandra >>> >>>> If you do need to override the entire recipe, then you first need to >>>> clearly >>>> articulate your reason in the commit log - wanting a newer commit >>>> isn't such >>>> a reason >>>> >>>> Then you need to do it in 2 steps/patches - first you copy over the >>>> existing >>>> recipe verbatim w/o any modifications, and in a separate step make your >>>> modifications >>>> >>>> Also, having own copy of an upstream recipe requires special >>>> attention to not >>>> violate the Yocto Project Compatible guidelines. I've explained this >>>> recently >>>> in another thread here on the list >>>> >
On Wed, Feb 12, 2025 at 01:46:48PM +0530, Yemike Abhilash Chandra wrote: > > > On 12/02/25 02:21, Denys Dmytriyenko wrote: > >On Tue, Feb 11, 2025 at 01:28:13PM +0530, Yemike Abhilash Chandra via lists.yoctoproject.org wrote: > >>An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer > >>for scarthgap. > >> > >>TI's 6.12 based kernel has backported multistream routing APIs from > >>upstream kernel, which requires v4l-utils to be the latest released > >>version (v1.28.1). > >> > >>Thus we override the recipe in this layer to the latest release of > >>v4l-utils. > > > >There are few issues with this... > > > >Do you really need to override the entire recipe? The old .bbappend was > >applying a patch already - can you add a new patch to that and bump SRCREV? > > > > We are not only updating the SRCREV, but also moving to a newer branch > (stable-1.28), which is why we considered overriding the entire recipe. > This approach aligns with how we have handled previously, including > 6.1 timeline, where we followed a similar process.[1] No, that's not the same - the previous change you linked in [1] also switched from git to a tarball release. Sure, that one could have been a .bbappend as well. You can also change the branch in SRC_URI with a Python .replace() function inside your .bbappend. > Given that the original recipe package still references an older version, > do you suggest that we update the branch in the existing .bbappend, > even though the base recipe remains on an older version? > > Please let me know if you want me to do that way. > > [1]: https://lore.kernel.org/all/20230525104036.2050245-1-j-luthra@ti.com/ > > Thanks, > Yemike Abhilash Chandra > > >If you do need to override the entire recipe, then you first need to clearly > >articulate your reason in the commit log - wanting a newer commit isn't such > >a reason > > > >Then you need to do it in 2 steps/patches - first you copy over the existing > >recipe verbatim w/o any modifications, and in a separate step make your > >modifications > > > >Also, having own copy of an upstream recipe requires special attention to not > >violate the Yocto Project Compatible guidelines. I've explained this recently > >in another thread here on the list > >
diff --git a/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-Install-media-ctl-header-and-library-files.patch b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-Install-media-ctl-header-and-library-files.patch new file mode 100644 index 00000000..6c946d8c --- /dev/null +++ b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-Install-media-ctl-header-and-library-files.patch @@ -0,0 +1,78 @@ +From 3867fcfa4389c7fa271705f1fd1d4bfb74bc1bd1 Mon Sep 17 00:00:00 2001 +From: Neel Gandhi <neel.gandhi@amd.com> +Date: Wed, 5 Jun 2024 13:51:36 +0530 +Subject: [PATCH] media-ctl: Install media-ctl header and library files + +Install mediactl and v4l2subdev header and library +files, which may be required by 3rd party applications +to populate and control v4l2subdev device node tree + +Install of these files was removed in upstream commit +0911dce53b08b0df3066be2c75f67e8a314d8729. + +Upstream-Status: Denied + +v4l-utils maintainers do not promise a stable API for this library, and +do not currently have the time to do so. So exporting the API in this +way is fine, as long as we understand that it will change and users of +the API will need to adapt over time. + +Signed-off-by: Neel Gandhi <neel.gandhi@amd.com> +Signed-off-by: Mark Hatle <mark.hatle@amd.com> +--- + utils/media-ctl/meson.build | 28 +++++++++++++++++++++------- + 1 file changed, 21 insertions(+), 7 deletions(-) + +diff --git a/utils/media-ctl/meson.build b/utils/media-ctl/meson.build +index 3a7b0c9a..40669b4c 100644 +--- a/utils/media-ctl/meson.build ++++ b/utils/media-ctl/meson.build +@@ -3,14 +3,24 @@ libmediactl_sources = files( + 'mediactl-priv.h', + ) + ++libmediactl_api = files( ++ 'mediactl.h', ++ 'v4l2subdev.h', ++) ++ ++install_headers(libmediactl_api, subdir: 'mediactl') ++ + libmediactl_deps = [ + dep_libudev, + ] + +-libmediactl = static_library('mediactl', +- libmediactl_sources, +- dependencies : libmediactl_deps, +- include_directories : v4l2_utils_incdir) ++libmediactl = library('mediactl', ++ libmediactl_sources, ++ soversion: '0', ++ version: '0.0.0', ++ install : true, ++ dependencies : libmediactl_deps, ++ include_directories : v4l2_utils_incdir) + + dep_libmediactl = declare_dependency(link_with : libmediactl) + +@@ -18,9 +28,13 @@ libv4l2subdev_sources = files('libv4l2subdev.c') + libv4l2subdev_sources += media_bus_format_names_h + libv4l2subdev_sources += media_bus_format_codes_h + +-libv4l2subdev = static_library('v4l2subdev', +- libv4l2subdev_sources, +- include_directories : v4l2_utils_incdir) ++libv4l2subdev = library('v4l2subdev', ++ libv4l2subdev_sources, ++ soversion: '0', ++ version: '0.0.0', ++ install : true, ++ dependencies : dep_libmediactl, ++ include_directories : v4l2_utils_incdir) + + dep_libv4l2subdev = declare_dependency(link_with : libv4l2subdev) + +-- +2.34.1 + diff --git a/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-add-support-for-RGBIr-bayer-formats.patch b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0002-media-ctl-add-support-for-RGBIr-bayer-formats.patch similarity index 100% rename from meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-add-support-for-RGBIr-bayer-formats.patch rename to meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0002-media-ctl-add-support-for-RGBIr-bayer-formats.patch diff --git a/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_%.bbappend b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_%.bbappend deleted file mode 100644 index 9b74dc7c..00000000 --- a/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_%.bbappend +++ /dev/null @@ -1,7 +0,0 @@ -FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" - -SRC_URI:append = " \ - file://0001-media-ctl-add-support-for-RGBIr-bayer-formats.patch \ -" - -PR:append = ".arago0" diff --git a/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_1.28.1.bb b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_1.28.1.bb new file mode 100644 index 00000000..6f5707da --- /dev/null +++ b/meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_1.28.1.bb @@ -0,0 +1,86 @@ +SUMMARY = "v4l2 and IR applications" +LICENSE = "GPL-2.0-only & LGPL-2.1-only" +LIC_FILES_CHKSUM = "file://COPYING;md5=48da9957849056017dc568bbc43d8975 \ + file://COPYING.libv4l;md5=d749e86a105281d7a44c2328acebc4b0" +PROVIDES = "libv4l media-ctl" + +DEPENDS = "jpeg \ + ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11', '', d)} \ + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \ + ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa-lib', '', d)} \ + ${@bb.utils.contains_any('PACKAGECONFIG', 'qv4l2 qvidcap', 'qtbase qtbase-native', '', d)}" + +DEPENDS:append:libc-musl = " argp-standalone" +DEPENDS:append:class-target = " udev" +LDFLAGS:append = " -pthread" +# v4l2 explicitly sets _FILE_OFFSET_BITS=32 to get access to +# both 32 and 64 bit file APIs. But it does not handle the time side? +# Needs further investigation +GLIBC_64BIT_TIME_FLAGS = "" + +inherit meson gettext pkgconfig + +PACKAGECONFIG ??= "" +PACKAGECONFIG[qv4l2] = ",-Dqv4l2=disabled" +PACKAGECONFIG[qvidcap] = ",-Dqvidcap=disabled" +PACKAGECONFIG[v4l2-tracer] = ",-Dv4l2-tracer=disabled,json-c" + +SRC_URI = "\ + git://git.linuxtv.org/v4l-utils.git;protocol=https;branch=stable-1.28 \ + file://0001-media-ctl-Install-media-ctl-header-and-library-files.patch \ + file://0002-media-ctl-add-support-for-RGBIr-bayer-formats.patch \ +" + +SRCREV = "757acdaec187d51803c2957d36df3d717a3529da" + +PV .= "+git" + +S = "${WORKDIR}/git" + +EXTRA_OEMESON = "-Dudevdir=${base_libdir}/udev -Dv4l2-compliance-32=false -Dv4l2-ctl-32=false" + +# Disable the erroneous installation of gconv-modules that would break glib +# like it is done in Debian and ArchLinux. +EXTRA_OEMESON += "-Dgconv=disabled" + +VIRTUAL-RUNTIME_ir-keytable-keymaps ?= "rc-keymaps" + +PACKAGES =+ "media-ctl ir-keytable rc-keymaps libv4l libv4l-dev qv4l2 qvidcap" + +RPROVIDES:${PN}-dbg += "libv4l-dbg" + +FILES:media-ctl = "${bindir}/media-ctl ${libdir}/libmediactl.so.*" +FILES:qv4l2 = "\ + ${bindir}/qv4l2 \ + ${datadir}/applications/qv4l2.desktop \ + ${datadir}/icons/hicolor/*/apps/qv4l2.* \ +" +FILES:qvidcap = "\ + ${bindir}/qvidcap \ + ${datadir}/applications/qvidcap.desktop \ + ${datadir}/icons/hicolor/*/apps/qvidcap.* \ +" + +FILES:ir-keytable = "${bindir}/ir-keytable ${base_libdir}/udev/rules.d/*-infrared.rules" +RDEPENDS:ir-keytable += "${VIRTUAL-RUNTIME_ir-keytable-keymaps}" +RDEPENDS:qv4l2 += "\ + ${@bb.utils.contains('PACKAGECONFIG', 'qv4l2', 'qtbase', '', d)}" +RDEPENDS:qvidcap += "\ + ${@bb.utils.contains('PACKAGECONFIG', 'qvidcap', 'qtbase', '', d)}" + +FILES:rc-keymaps = "${sysconfdir}/rc* ${base_libdir}/udev/rc*" + +FILES:${PN} = "${bindir} ${sbindir}" + +FILES:libv4l += "${libdir}/libv4l*${SOLIBS} ${libdir}/libv4l/*.so ${libdir}/libv4l/plugins/*.so \ + ${libdir}/libdvbv5*${SOLIBS} \ + ${libdir}/libv4l/*-decomp \ + ${libdir}/libv4l2tracer.so \ +" + +FILES:libv4l-dev += "${includedir} ${libdir}/pkgconfig \ + ${libdir}/libv4l*${SOLIBSDEV} ${libdir}/*.la \ + ${libdir}/v4l*${SOLIBSDEV} ${libdir}/libv4l/*.la ${libdir}/libv4l/plugins/*.la" + +PARALLEL_MAKE:class-native = "" +BBCLASSEXTEND = "native"
An older recipe of v4l-utils (v1.26.1) is present in the meta-oe layer for scarthgap. TI's 6.12 based kernel has backported multistream routing APIs from upstream kernel, which requires v4l-utils to be the latest released version (v1.28.1). Thus we override the recipe in this layer to the latest release of v4l-utils. Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> --- Single camera setup logs: http://serenity.dal.design.ti.com:7777/ohidowecig.yaml Multi camera setup logs: http://serenity.dal.design.ti.com:7777/oqowimumeh.yaml ...l-media-ctl-header-and-library-files.patch | 78 +++++++++++++++++ ...add-support-for-RGBIr-bayer-formats.patch} | 0 .../v4l2apps/v4l-utils_%.bbappend | 7 -- .../v4l2apps/v4l-utils_1.28.1.bb | 86 +++++++++++++++++++ 4 files changed, 164 insertions(+), 7 deletions(-) create mode 100644 meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/0001-media-ctl-Install-media-ctl-header-and-library-files.patch rename meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils/{0001-media-ctl-add-support-for-RGBIr-bayer-formats.patch => 0002-media-ctl-add-support-for-RGBIr-bayer-formats.patch} (100%) delete mode 100644 meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_%.bbappend create mode 100644 meta-arago-extras/recipes-multimedia/v4l2apps/v4l-utils_1.28.1.bb