* [PATCH 1/3] matrix-gui-browser: port from arago overlay
@ 2012-01-26 18:46 Chase Maupin
2012-01-26 18:46 ` [PATCH 2/3] refresh-screen: add package from arago Chase Maupin
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Chase Maupin @ 2012-01-26 18:46 UTC (permalink / raw)
To: meta-ti
* This package adds a simple web browser GUI application with
no decorations used to display matrix on the local display.
* Ported from arago overlay
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
---
recipes-ti/matrix/matrix-gui-browser_2.0.bb | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 recipes-ti/matrix/matrix-gui-browser_2.0.bb
diff --git a/recipes-ti/matrix/matrix-gui-browser_2.0.bb b/recipes-ti/matrix/matrix-gui-browser_2.0.bb
new file mode 100644
index 0000000..602487b
--- /dev/null
+++ b/recipes-ti/matrix/matrix-gui-browser_2.0.bb
@@ -0,0 +1,25 @@
+DESCRIPTION = "Simple Qt web display using webkit"
+HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix_browser"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://main.cpp;beginline=9;endline=37;md5=884b90f5bf0d711fe32c4f04b5276496"
+SECTION = "multimedia"
+PRIORITY = "optional"
+
+# Make sure that QT font libraries have been installed
+RDEPENDS += "qt4-embedded-fonts"
+
+PR = "r0"
+
+SRCREV = "db2e6b10e5a14358b6120a4a28de2f9d591bc55c"
+BRANCH ?= "master"
+
+SRC_URI = "git://gitorious.org/matrix-gui-v2/matrix_browser.git;protocol=git;branch=${BRANCH}"
+
+S = "${WORKDIR}/git"
+
+inherit qt4e
+
+do_install() {
+ install -d ${D}/${bindir}
+ install -m 0755 ${S}/matrix_browser ${D}/${bindir}
+}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 45+ messages in thread* [PATCH 2/3] refresh-screen: add package from arago 2012-01-26 18:46 [PATCH 1/3] matrix-gui-browser: port from arago overlay Chase Maupin @ 2012-01-26 18:46 ` Chase Maupin 2012-01-26 18:46 ` [PATCH 3/3] matrix-gui: update to latest version Chase Maupin 2012-01-26 22:44 ` [PATCH 1/3] matrix-gui-browser: port from arago overlay William Mills 2 siblings, 0 replies; 45+ messages in thread From: Chase Maupin @ 2012-01-26 18:46 UTC (permalink / raw) To: meta-ti * This package adds a utility to force a screen refresh after graphics applications are executed. This is to prevent left over graphics artifacts from being displayed in matrix. * Ported from arago overlay Signed-off-by: Chase Maupin <Chase.Maupin@ti.com> --- ...ix-gui-browser_2.0.bb => refresh-screen_2.0.bb} | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) copy recipes-ti/matrix/{matrix-gui-browser_2.0.bb => refresh-screen_2.0.bb} (52%) diff --git a/recipes-ti/matrix/matrix-gui-browser_2.0.bb b/recipes-ti/matrix/refresh-screen_2.0.bb similarity index 52% copy from recipes-ti/matrix/matrix-gui-browser_2.0.bb copy to recipes-ti/matrix/refresh-screen_2.0.bb index 602487b..3a3ad5e 100644 --- a/recipes-ti/matrix/matrix-gui-browser_2.0.bb +++ b/recipes-ti/matrix/refresh-screen_2.0.bb @@ -1,5 +1,5 @@ -DESCRIPTION = "Simple Qt web display using webkit" -HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix_browser" +DESCRIPTION = "Simple Application to force a screen refresh" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/refresh-screen" LICENSE = "BSD" LIC_FILES_CHKSUM = "file://main.cpp;beginline=9;endline=37;md5=884b90f5bf0d711fe32c4f04b5276496" SECTION = "multimedia" @@ -10,16 +10,16 @@ RDEPENDS += "qt4-embedded-fonts" PR = "r0" -SRCREV = "db2e6b10e5a14358b6120a4a28de2f9d591bc55c" +SRCREV = "ba27273f0d61dd71589db380f785f091b7ad3efe" BRANCH ?= "master" -SRC_URI = "git://gitorious.org/matrix-gui-v2/matrix_browser.git;protocol=git;branch=${BRANCH}" +SRC_URI = "git://gitorious.org/matrix-gui-v2/refresh-screen.git;protocol=git;branch=${BRANCH}" S = "${WORKDIR}/git" inherit qt4e do_install() { - install -d ${D}/${bindir} - install -m 0755 ${S}/matrix_browser ${D}/${bindir} + install -d ${D}/${bindir} + install -m 0755 ${S}/refresh_screen ${D}/${bindir} } -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH 3/3] matrix-gui: update to latest version 2012-01-26 18:46 [PATCH 1/3] matrix-gui-browser: port from arago overlay Chase Maupin 2012-01-26 18:46 ` [PATCH 2/3] refresh-screen: add package from arago Chase Maupin @ 2012-01-26 18:46 ` Chase Maupin 2012-01-26 22:44 ` [PATCH 1/3] matrix-gui-browser: port from arago overlay William Mills 2 siblings, 0 replies; 45+ messages in thread From: Chase Maupin @ 2012-01-26 18:46 UTC (permalink / raw) To: meta-ti * Update to the latest version of matrix-gui and the matrix-gui supporting recipes. These use a git repository instead of tarballs for the submenu and demo description files. * This support was ported from the arago project overlay Signed-off-by: Chase Maupin <Chase.Maupin@ti.com> --- recipes-ti/matrix/matrix-gui-3d-demos_1.0.bb | 18 ---- recipes-ti/matrix/matrix-gui-3d-demos_2.0.bb | 22 ++++ recipes-ti/matrix/matrix-gui-apps-git.inc | 10 ++ recipes-ti/matrix/matrix-gui-apps-images_2.0.bb | 20 ++++ .../matrix/matrix-gui-armbenchmarks-demos_2.0.bb | 17 +++ .../matrix/matrix-gui-camera-loopback_2.0.bb | 18 ++++ ...-gui-clocks_1.1.bb => matrix-gui-clocks_2.0.bb} | 18 ++-- recipes-ti/matrix/matrix-gui-coming-soon_1.0.bb | 17 --- recipes-ti/matrix/matrix-gui-crypto-demos_1.2.bb | 19 ---- recipes-ti/matrix/matrix-gui-crypto-demos_2.0.bb | 17 +++ .../matrix/matrix-gui-display-control_1.0.bb | 21 ---- .../matrix/matrix-gui-display-control_2.0.bb | 18 ++++ .../matrix/matrix-gui-multimedia-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-oprofile-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-pm-demos_1.0.bb | 21 ---- recipes-ti/matrix/matrix-gui-pm-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-pru-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-qt4-demos_1.0.bb | 20 ---- recipes-ti/matrix/matrix-gui-qt4-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-settings-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-submenus_1.0.bb | 105 -------------------- recipes-ti/matrix/matrix-gui-submenus_2.0.bb | 50 +++++++++ recipes-ti/matrix/matrix-gui-usb-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-v4l2-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui-wifi-demos_1.1.bb | 19 ---- recipes-ti/matrix/matrix-gui-wifi-demos_2.0.bb | 17 +++ recipes-ti/matrix/matrix-gui/init | 57 ++++++++--- recipes-ti/matrix/matrix-gui_2.0.bb | 39 ++++++- 28 files changed, 406 insertions(+), 273 deletions(-) delete mode 100644 recipes-ti/matrix/matrix-gui-3d-demos_1.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-3d-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-apps-git.inc create mode 100644 recipes-ti/matrix/matrix-gui-apps-images_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-armbenchmarks-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-camera-loopback_2.0.bb rename recipes-ti/matrix/{matrix-gui-clocks_1.1.bb => matrix-gui-clocks_2.0.bb} (66%) delete mode 100644 recipes-ti/matrix/matrix-gui-coming-soon_1.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-crypto-demos_1.2.bb create mode 100644 recipes-ti/matrix/matrix-gui-crypto-demos_2.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-display-control_1.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-display-control_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-multimedia-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-oprofile-demos_2.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-pm-demos_1.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-pm-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-pru-demos_2.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-qt4-demos_1.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-qt4-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-settings-demos_2.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-submenus_1.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-submenus_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-usb-demos_2.0.bb create mode 100644 recipes-ti/matrix/matrix-gui-v4l2-demos_2.0.bb delete mode 100644 recipes-ti/matrix/matrix-gui-wifi-demos_1.1.bb create mode 100644 recipes-ti/matrix/matrix-gui-wifi-demos_2.0.bb diff --git a/recipes-ti/matrix/matrix-gui-3d-demos_1.0.bb b/recipes-ti/matrix/matrix-gui-3d-demos_1.0.bb deleted file mode 100644 index ece9b2e..0000000 --- a/recipes-ti/matrix/matrix-gui-3d-demos_1.0.bb +++ /dev/null @@ -1,18 +0,0 @@ -DESCRIPTION = "3D demo descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/603/5030/3ddemos_1.0.tar.gz" - -S = ${WORKDIR}/3ddemos - -require matrix-gui-apps.inc - -# Make sure 3D submenu has been installed -RDEPENDS += matrix-gui-submenus-3d - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "998363dbabea3724c4c3283a480cdb60" -SRC_URI[sha256sum] = "aab5890dffe4e9f36f78a64ec16e7221649bb61ef1ceee2e1246cd666d197268" diff --git a/recipes-ti/matrix/matrix-gui-3d-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-3d-demos_2.0.bb new file mode 100644 index 0000000..c1e79b1 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-3d-demos_2.0.bb @@ -0,0 +1,22 @@ +DESCRIPTION = "3D demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +S = ${WORKDIR}/git/3d_apps + +# Make sure 3D submenu has been installed and app images has been installed + +# TODO: in the future we may want to consider putting this into the libgles +# recipe directly. Requires broad acceptance of matrix v2 though due +# to the matrix-gui-submenus-3d dependency. So if matrix v2 moves +# into the same layer as libgles this may be acceptable, or perhaps +# we can use an RRECOMMENDS instead. +RDEPENDS += "matrix-gui-apps-images matrix-gui-submenus-3d libgles-omap3-rawdemos" + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" + diff --git a/recipes-ti/matrix/matrix-gui-apps-git.inc b/recipes-ti/matrix/matrix-gui-apps-git.inc new file mode 100644 index 0000000..c5d81c3 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-apps-git.inc @@ -0,0 +1,10 @@ +LICENSE = "CC-BY-SA" +LIC_FILES_CHKSUM = "file://../LICENSE;md5=6e0ae7214f6c74c149cb25f373057fa9" + +SRC_URI = "git://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps.git;protocol=git;branch=${BRANCH}" +SRCREV = "27e8eb76f4a405c123a9f816b1b389e20b06f30c" +BRANCH = "master" +INC_PR = "r0" + +# Pull in the base package for installing matrix applications +require matrix-gui-apps.inc diff --git a/recipes-ti/matrix/matrix-gui-apps-images_2.0.bb b/recipes-ti/matrix/matrix-gui-apps-images_2.0.bb new file mode 100644 index 0000000..311d3a7 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-apps-images_2.0.bb @@ -0,0 +1,20 @@ +DESCRIPTION = "Image package for Matrix GUI v2 Applications" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc +require matrix-gui-paths.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = "${WORKDIR}/git/images" + +do_install(){ + install -d ${D}${MATRIX_APP_DIR} + cp -rf ${S}/ ${D}${MATRIX_APP_DIR} +} + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-armbenchmarks-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-armbenchmarks-demos_2.0.bb new file mode 100644 index 0000000..8b758df --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-armbenchmarks-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Arm Benchmarks Applications for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/arm_apps + +# Make sure arm submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-arm + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-camera-loopback_2.0.bb b/recipes-ti/matrix/matrix-gui-camera-loopback_2.0.bb new file mode 100644 index 0000000..698b3d7 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-camera-loopback_2.0.bb @@ -0,0 +1,18 @@ +DESCRIPTION = "Camera loopback application for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +S = ${WORKDIR}/git/cameraloopback_apps + +# Make sure loopback application is compiled and app images has been installed +RDEPENDS += "matrix-gui-apps-images av-examples" + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" + + + diff --git a/recipes-ti/matrix/matrix-gui-clocks_1.1.bb b/recipes-ti/matrix/matrix-gui-clocks_2.0.bb similarity index 66% rename from recipes-ti/matrix/matrix-gui-clocks_1.1.bb rename to recipes-ti/matrix/matrix-gui-clocks_2.0.bb index 2fb7d1d..282bd9c 100644 --- a/recipes-ti/matrix/matrix-gui-clocks_1.1.bb +++ b/recipes-ti/matrix/matrix-gui-clocks_2.0.bb @@ -1,17 +1,18 @@ DESCRIPTION = "Clock setting descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" LICENSE = "CC-BY-SA" +PRIORITY = "optional" -inherit allarch +require matrix-gui-apps-git.inc -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/673/5096/clocks_1.1.tar.gz" +PR = "${INC_PR}.0" -S = ${WORKDIR}/clocks +inherit allarch -require matrix-gui-apps.inc +S = ${WORKDIR}/git/clocks_apps -# Make sure power submenu has been installed -RDEPENDS += matrix-gui-submenus-power +# Make sure power submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-power # Break out the individual files into separate packages. That way only the # clocks supported for each device can be installed. Prepend the list so @@ -29,6 +30,3 @@ FILES_${PN}-300mhz += "${bindir}/setopp2.sh" FILES_${PN}-600mhz += "${bindir}/setopp3.sh" FILES_${PN}-800mhz += "${bindir}/setopp4.sh" FILES_${PN}-1ghz += "${bindir}/setopp1.sh" - -SRC_URI[md5sum] = "6d50592e364f39d7ed3b2805e6c227cb" -SRC_URI[sha256sum] = "ab51df1651a391e3f6a947faccf45354ef187508c65cb3de92cc9fef88206e65" diff --git a/recipes-ti/matrix/matrix-gui-coming-soon_1.0.bb b/recipes-ti/matrix/matrix-gui-coming-soon_1.0.bb deleted file mode 100644 index 500eee4..0000000 --- a/recipes-ti/matrix/matrix-gui-coming-soon_1.0.bb +++ /dev/null @@ -1,17 +0,0 @@ -DESCRIPTION = "coming soon descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" -LIC_FILES_CHKSUM = "file://comingsoon/comingsoon.desktop;md5=01ebad171fad40705288fcabccc770a2" - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/616/5029/comingsoon_1.0.tar.gz" - -S = "${WORKDIR}" - -require matrix-gui-apps.inc - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "04076ed62be226ffee3f3960237c47f8" -SRC_URI[sha256sum] = "f00d24a506f39b92ba335479f902bdb97680df3502f81343be5baab45fd2bc95" diff --git a/recipes-ti/matrix/matrix-gui-crypto-demos_1.2.bb b/recipes-ti/matrix/matrix-gui-crypto-demos_1.2.bb deleted file mode 100644 index dfc3a93..0000000 --- a/recipes-ti/matrix/matrix-gui-crypto-demos_1.2.bb +++ /dev/null @@ -1,19 +0,0 @@ -DESCRIPTION = "Cryptography demo descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/688/5114/cryptodemos_1.2.tar.gz" - -S = ${WORKDIR}/cryptodemos - -require matrix-gui-apps.inc - -# Make sure crypto submenu has been installed and openssl is available -RDEPENDS += "matrix-gui-submenus-cryptos openssl" - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "dfab3e918fee165fb24e00cba5db8918" -SRC_URI[sha256sum] = "44fa00ce999279c10a51718298157d3006afb018f6f327f1803006b5e7068c8c" diff --git a/recipes-ti/matrix/matrix-gui-crypto-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-crypto-demos_2.0.bb new file mode 100644 index 0000000..6ac9d45 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-crypto-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Cryptography demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/cryptos_apps + +# Make sure crypto submenu and app images has been installed. Also make sure openssl is available +RDEPENDS += "matrix-gui-apps-images matrix-gui-submenus-cryptos openssl" + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-display-control_1.0.bb b/recipes-ti/matrix/matrix-gui-display-control_1.0.bb deleted file mode 100644 index 09b68b3..0000000 --- a/recipes-ti/matrix/matrix-gui-display-control_1.0.bb +++ /dev/null @@ -1,21 +0,0 @@ -DESCRIPTION = "Display control descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - -PR = "r1" - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/674/5097/displaycontrol_1.1.tar.gz" - -S = ${WORKDIR}/displaycontrol - -require matrix-gui-apps.inc - -# Make sure display submenu has been installed -RDEPENDS += matrix-gui-submenus-display - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "1032490affff638b993367ce5a451298" -SRC_URI[sha256sum] = "78d3a6e1e74acb55a927cc7e087cd15c33767cfaf9458200aa863025cee32f2e" diff --git a/recipes-ti/matrix/matrix-gui-display-control_2.0.bb b/recipes-ti/matrix/matrix-gui-display-control_2.0.bb new file mode 100644 index 0000000..963e906 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-display-control_2.0.bb @@ -0,0 +1,18 @@ +DESCRIPTION = "Display control descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/displaycontrol_apps + +# Make sure display submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-display + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" + diff --git a/recipes-ti/matrix/matrix-gui-multimedia-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-multimedia-demos_2.0.bb new file mode 100644 index 0000000..bbfefd3 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-multimedia-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Multimedia demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/multimedia_apps + +# Make sure multimedia submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-multimedia + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-oprofile-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-oprofile-demos_2.0.bb new file mode 100644 index 0000000..af5a760 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-oprofile-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Oprofile demo applications for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/oprofile_apps + +# Make sure profiling submenu and app images has been installed +RDEPENDS += "matrix-gui-apps-images matrix-gui-submenus-oprofile" + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-pm-demos_1.0.bb b/recipes-ti/matrix/matrix-gui-pm-demos_1.0.bb deleted file mode 100644 index 70e72f9..0000000 --- a/recipes-ti/matrix/matrix-gui-pm-demos_1.0.bb +++ /dev/null @@ -1,21 +0,0 @@ -DESCRIPTION = "Power management demo descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - -PR = "r1" - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/676/5099/pmdemos_1.1.tar.gz" - -S = ${WORKDIR}/pmdemos - -require matrix-gui-apps.inc - -# Make sure power submenu has been installed -RDEPENDS += matrix-gui-submenus-power - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "f996f9754c3d140e95501d8b4134f21c" -SRC_URI[sha256sum] = "229579b71439c0ad4cff60d7ebb4065f6871db57dd5baa4a5983c9f7804655ab" diff --git a/recipes-ti/matrix/matrix-gui-pm-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-pm-demos_2.0.bb new file mode 100644 index 0000000..a9ae00b --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-pm-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Power management demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/power_apps + +# Make sure power submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-power + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-pru-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-pru-demos_2.0.bb new file mode 100644 index 0000000..d4feca4 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-pru-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "PRU demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/pru_apps + +# Make sure pru submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-pru + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-qt4-demos_1.0.bb b/recipes-ti/matrix/matrix-gui-qt4-demos_1.0.bb deleted file mode 100644 index e4e43c7..0000000 --- a/recipes-ti/matrix/matrix-gui-qt4-demos_1.0.bb +++ /dev/null @@ -1,20 +0,0 @@ -DESCRIPTION = "Qt4 demo descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/608/5036/qt4demos_1.0.tar.gz" - -S = ${WORKDIR}/qt4demos - -require matrix-gui-apps.inc - -# Make sure qt4 submenu has been installed -RDEPENDS += matrix-gui-submenus-qt4 - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "49b65c4af67117ba70e0ddabfe486abe" -SRC_URI[sha256sum] = "8367c539caf6902961db4b8f38b0fb1f05b7b105d5e7fd143c9503ca0c8a1df2" diff --git a/recipes-ti/matrix/matrix-gui-qt4-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-qt4-demos_2.0.bb new file mode 100644 index 0000000..36b805d --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-qt4-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Qt4 demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/qt4_apps + +# Make sure qt4 submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-qt4 + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-settings-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-settings-demos_2.0.bb new file mode 100644 index 0000000..429b074 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-settings-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Settings demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/settings_apps + +# Make sure setting submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-settings + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-submenus_1.0.bb b/recipes-ti/matrix/matrix-gui-submenus_1.0.bb deleted file mode 100644 index 83bd18e..0000000 --- a/recipes-ti/matrix/matrix-gui-submenus_1.0.bb +++ /dev/null @@ -1,105 +0,0 @@ -DESCRIPTION = "Submenu packages for Matrix GUI v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" -LIC_FILES_CHKSUM = "file://settings/settings.desktop;md5=bbd663594c3e13b280ff5fffaddca672" - -PR = "r7" - -require matrix-gui-paths.inc - -# These packages make submenus in matrix and are not architecture specific -inherit allarch - -# List of submenu tarballs to use. Each tarball contains a desktop file -# and PNG graphic file for the submenu. -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/699/5133/arm_1.1.tar.gz;name=armtarball \ - https://gforge.ti.com/gf/download/frsrelease/698/5134/3d_1.1.tar.gz;name=3dtarball \ - https://gforge.ti.com/gf/download/frsrelease/700/5135/cryptos_1.1.tar.gz;name=cryptostarball \ - https://gforge.ti.com/gf/download/frsrelease/693/5120/display_1.2.tar.gz;name=displaytarball \ - https://gforge.ti.com/gf/download/frsrelease/692/5119/ethernet_1.4.tar.gz;name=ethernettarball \ - https://gforge.ti.com/gf/download/frsrelease/701/5136/multimedia_1.1.tar.gz;name=multimediatarball \ - https://gforge.ti.com/gf/download/frsrelease/702/5137/power_1.1.tar.gz;name=powertarball \ - https://gforge.ti.com/gf/download/frsrelease/704/5139/pru_1.1.tar.gz;name=prutarball \ - https://gforge.ti.com/gf/download/frsrelease/705/5140/qt4_1.1.tar.gz;name=qt4tarball \ - https://gforge.ti.com/gf/download/frsrelease/694/5121/settings_1.2.tar.gz;name=settingstarball \ - https://gforge.ti.com/gf/download/frsrelease/695/5122/usb_1.2.tar.gz;name=usbtarball \ - https://gforge.ti.com/gf/download/frsrelease/697/5124/wifi_1.2.tar.gz;name=wifitarball \ - https://gforge.ti.com/gf/download/frsrelease/703/5138/oprofile_1.1.tar.gz;name=oprofiletarball \ -" - -S = ${WORKDIR} - -# List of submenus to build packages for -SUBMENUS = "arm 3d cryptos display ethernet multimedia power pru qt4 settings usb wifi oprofile" - -do_install(){ - install -d ${D}${MATRIX_APP_DIR} - - for x in ${SUBMENUS} - do - cp -rf ${S}/$x ${D}${MATRIX_APP_DIR}/ - done -} - -PACKAGES += "${PN}-arm ${PN}-3d ${PN}-cryptos ${PN}-display ${PN}-ethernet ${PN}-multimedia ${PN}-power ${PN}-pru ${PN}-qt4 ${PN}-settings ${PN}-usb ${PN}-wifi ${PN}-oprofile" - -# This should be automatic, but isn't :( -PROVIDES += "${PACKAGES}" - -# All submenu packages should depend on matrix-gui being installed -RDEPENDS += matrix-gui - -# Add the files for each submenu package -FILES_${PN}-arm = "${MATRIX_APP_DIR}/arm/*" -FILES_${PN}-3d = "${MATRIX_APP_DIR}/3d/*" -FILES_${PN}-cryptos = "${MATRIX_APP_DIR}/cryptos/*" -FILES_${PN}-display = "${MATRIX_APP_DIR}/display/*" -FILES_${PN}-ethernet = "${MATRIX_APP_DIR}/ethernet/*" -FILES_${PN}-multimedia = "${MATRIX_APP_DIR}/multimedia/*" -FILES_${PN}-power = "${MATRIX_APP_DIR}/power/*" -FILES_${PN}-pru = "${MATRIX_APP_DIR}/pru/*" -FILES_${PN}-qt4 = "${MATRIX_APP_DIR}/qt4/*" -FILES_${PN}-settings = "${MATRIX_APP_DIR}/settings/*" -FILES_${PN}-usb = "${MATRIX_APP_DIR}/usb/*" -FILES_${PN}-wifi = "${MATRIX_APP_DIR}/wifi/*" -FILES_${PN}-oprofile = "${MATRIX_APP_DIR}/oprofile/*" - -# checksums for the submenu tarballs -SRC_URI[armtarball.md5sum] = "e43585674dac2d6d6860a26c2de5332c" -SRC_URI[armtarball.sha256um] = "270f82b09fcdc3d1a08570d30ff2a9085e7b61a0f6890f734c658cd6408de155" - -SRC_URI[3dtarball.md5sum] = "1cabbb75849e892a5fc7322159750f8a" -SRC_URI[3dtarball.sha256um] = "df4983c0722a9427584497f737af57c8401a6b3898f71c994a0cfe97e5ade01a" - -SRC_URI[cryptostarball.md5sum] = "88d4ece28e75eb28358b43729022c91a" -SRC_URI[cryptostarball.sha256um] = "7999b2e06d27c30294c104418db79a1f9652a07a066242120cb32d3f86706538" - -SRC_URI[displaytarball.md5sum] = "eff9c5ab6667525ab0c452a6319cc5d8" -SRC_URI[displaytarball.sha256sum] = "834f22c4439bdd97c04160b9e002abcddf22188a01488476b604259324ea09af" - -SRC_URI[ethernettarball.md5sum] = "ff82b9a0ce5bbf7b7672073147f415c9" -SRC_URI[ethernettarball.sha256sum] = "28e74cd7e30fff3c7cb6ac284fb39b98e73ecefa0182ab900f64d293845d51eb" - -SRC_URI[multimediatarball.md5sum] = "21064503fc26611cfedf093e478440b3" -SRC_URI[multimediatarball.sha256sum] = "039d2f7fbbd29b31601cf6596268a5a43f9dd7e86ff888a9ef45515479797d3d" - -SRC_URI[powertarball.md5sum] = "406a838e12d7f83bc5a004e748ceb660" -SRC_URI[powertarball.sha256sum] = "d6c0bc690c1f45cc81fa1673dad08bea03f799adb929e5a3ec3fe4ebda60fca8" - -SRC_URI[prutarball.md5sum] = "b0eca67cdc45db2b9aa14987b4761068" -SRC_URI[prutarball.sha256sum] = "06d3acf5ba2e4d5ff796625b07b470e5cea945700c9571878b8f4ba6f171d2de" - -SRC_URI[qt4tarball.md5sum] = "3576ad6bc96fceb18d4d8b0850bf559d" -SRC_URI[qt4tarball.sha256sum] = "11fd5ca37d72b7129035b7f6101b4b06ac2b69d53abcd6a2751d3e9c7000dec0" - -SRC_URI[settingstarball.md5sum] = "f2634670768860954cc63309d1f4f37e" -SRC_URI[settingstarball.sha256sum] = "fb96e6e4107445e4d5d65e2475513a62e0cf5b52734c9f93e918715abcc09265" - -SRC_URI[usbtarball.md5sum] = "63cebc3422af0f09f3eaa0a65b25bcde" -SRC_URI[usbtarball.sha256sum] = "7178afea3b5b2926ddbf80766f1d457d7a31704869bce62ffc8db4b3d6e063e7" - -SRC_URI[wifitarball.md5sum] = "c8ae4df2521276b5b83294153825acf4" -SRC_URI[wifitarball.sha256sum] = "430f4c161eaf5dc28d524fbf4903274817023414154b2074a0b948e50724a6ff" - -SRC_URI[oprofiletarball.md5sum] = "02d0c9eb9fed014170f57ad30f2a5c85" -SRC_URI[oprofiletarball.sha256sum] = "ebad9018c0bd37f075a248d60e6e5520824d09afd03e71395cfc9949747e33ac" diff --git a/recipes-ti/matrix/matrix-gui-submenus_2.0.bb b/recipes-ti/matrix/matrix-gui-submenus_2.0.bb new file mode 100644 index 0000000..e391143 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-submenus_2.0.bb @@ -0,0 +1,50 @@ +DESCRIPTION = "Submenu packages for Matrix GUI v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc +require matrix-gui-paths.inc + +# This package does not use a subdirectory as ${S} so we need to +# reset the LIC_FILES_CHKSUM setting from the matrix-gui-apps-git.inc file +LIC_FILES_CHKSUM = "file://LICENSE;md5=6e0ae7214f6c74c149cb25f373057fa9" + +PR = "${INC_PR}.8" + +# These packages make submenus in matrix and are not architecture specific +inherit allarch + +S = "${WORKDIR}/git" + +# List of submenus to build packages for +SUBMENUS = "arm_submenu 3d_submenu cryptos_submenu display_submenu ethernet_submenu multimedia_submenu power_submenu pru_submenu qt4_submenu settings_submenu usb_submenu wifi_submenu oprofile_submenu" + +do_install(){ + install -d ${D}${MATRIX_APP_DIR} + + for x in ${SUBMENUS} + do + cp -rf ${S}/$x ${D}${MATRIX_APP_DIR}/ + done +} + +PACKAGES += "${PN}-arm ${PN}-3d ${PN}-cryptos ${PN}-display ${PN}-ethernet ${PN}-multimedia ${PN}-power ${PN}-pru ${PN}-qt4 ${PN}-settings ${PN}-usb ${PN}-wifi ${PN}-oprofile" + +# Make sure app images has been installed +RDEPENDS += matrix-gui-apps-images + +# Add the files for each submenu package +FILES_${PN}-arm = "${MATRIX_APP_DIR}/arm_submenu/*" +FILES_${PN}-3d = "${MATRIX_APP_DIR}/3d_submenu/*" +FILES_${PN}-cryptos = "${MATRIX_APP_DIR}/cryptos_submenu/*" +FILES_${PN}-display = "${MATRIX_APP_DIR}/display_submenu/*" +FILES_${PN}-ethernet = "${MATRIX_APP_DIR}/ethernet_submenu/*" +FILES_${PN}-multimedia = "${MATRIX_APP_DIR}/multimedia_submenu/*" +FILES_${PN}-power = "${MATRIX_APP_DIR}/power_submenu/*" +FILES_${PN}-pru = "${MATRIX_APP_DIR}/pru_submenu/*" +FILES_${PN}-qt4 = "${MATRIX_APP_DIR}/qt4_submenu/*" +FILES_${PN}-settings = "${MATRIX_APP_DIR}/settings_submenu/*" +FILES_${PN}-usb = "${MATRIX_APP_DIR}/usb_submenu/*" +FILES_${PN}-wifi = "${MATRIX_APP_DIR}/wifi_submenu/*" +FILES_${PN}-oprofile = "${MATRIX_APP_DIR}/oprofile_submenu/*" diff --git a/recipes-ti/matrix/matrix-gui-usb-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-usb-demos_2.0.bb new file mode 100644 index 0000000..3801358 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-usb-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "USB demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/usb_apps + +# Make sure usb submenu and app images has been installed +RDEPENDS += "matrix-gui-apps-images matrix-gui-submenus-usb bonnie++" + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-v4l2-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-v4l2-demos_2.0.bb new file mode 100644 index 0000000..687c9f8 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-v4l2-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "V4l2 demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/v4l2_apps + +# Make sure display submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-display + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui-wifi-demos_1.1.bb b/recipes-ti/matrix/matrix-gui-wifi-demos_1.1.bb deleted file mode 100644 index be79356..0000000 --- a/recipes-ti/matrix/matrix-gui-wifi-demos_1.1.bb +++ /dev/null @@ -1,19 +0,0 @@ -DESCRIPTION = "Wifi demo descriptions for Matrix v2" -HOMEPAGE = "https://gforge.ti.com/gf/project/matrixguiv2apps/" -LICENSE = "CC-BY-SA" - -inherit allarch - -SRC_URI = "https://gforge.ti.com/gf/download/frsrelease/678/5101/wifidemos_1.1.tar.gz" - -S = ${WORKDIR}/wifidemos - -require matrix-gui-apps.inc - -# Make sure wifi submenu has been installed -RDEPENDS += matrix-gui-submenus-wifi - -FILES_${PN} += "${MATRIX_BASE_DIR}/*" - -SRC_URI[md5sum] = "60d85261bcad85da7ecd024613343068" -SRC_URI[sha256sum] = "36fe8bbc461e157b00ebf8f9deab1e5c83eef2f618bc98f2956d974e76534c56" diff --git a/recipes-ti/matrix/matrix-gui-wifi-demos_2.0.bb b/recipes-ti/matrix/matrix-gui-wifi-demos_2.0.bb new file mode 100644 index 0000000..bc02c25 --- /dev/null +++ b/recipes-ti/matrix/matrix-gui-wifi-demos_2.0.bb @@ -0,0 +1,17 @@ +DESCRIPTION = "Wifi demo descriptions for Matrix v2" +HOMEPAGE = "https://gitorious.org/matrix-gui-v2/matrix-gui-v2-apps" +LICENSE = "CC-BY-SA" +PRIORITY = "optional" + +require matrix-gui-apps-git.inc + +PR = "${INC_PR}.0" + +inherit allarch + +S = ${WORKDIR}/git/wifi_apps + +# Make sure wifi submenu and app images has been installed +RDEPENDS += matrix-gui-apps-images matrix-gui-submenus-wifi + +FILES_${PN} += "${MATRIX_BASE_DIR}/*" diff --git a/recipes-ti/matrix/matrix-gui/init b/recipes-ti/matrix/matrix-gui/init index c9253d4..349da53 100644 --- a/recipes-ti/matrix/matrix-gui/init +++ b/recipes-ti/matrix/matrix-gui/init @@ -1,35 +1,63 @@ #! /bin/sh -matrixgui="/usr/bin/qtopia/demos/browser/browser" -GUI_OPTS="-qws -nogui http://localhost:8080/index.html" +matrixgui="/usr/bin/matrix_browser" +ROTATION=__MATRIX_ROT__ +GUI_OPTS="-qws $ROTATION http://localhost:8080/" PIDFILE="/var/run/matrix-gui-2.0.pid" test -x "$matrixgui" || exit 0 export TSLIB_TSDEVICE=/dev/input/touchscreen0 -export QWS_MOUSE_PROTO=Tslib:/dev/input/touchscreen0 +export QWS_MOUSE_PROTO=Auto +tsfile=/etc/pointercal case "$1" in start) chvt 4 - # Temporarily create the /dev/input/touchscreen0 symlink if it is - # not already present. On devices like am335x the driver does not - # report the right string in /sys/devices/platform/tsc/input/input0/modalias - # to match the regular expression in /etc/udev/rules.d/local.rules - # to have this symlink created automatically. - if [ -e /dev/input/event0 ] + # ARM9 devices get a lot of alignment trap errors with the current + # version of Qt (4.7.2) that we use. The printing of these messages + # is causing a severe slowdown with matrix and other Qt applications + # that matrix launches. The root cause is under investigation and an + # issue is being filed in the Qt JIRA tracker. For now using the + # following command will do a software fixup of the alignment trap errors + # in the kernel. This should have no impact on cortex-A8 devices. + echo 2 > /proc/cpu/alignment + + # Do not try to calibrate the touchscreen if it doesn't exist. + if [ -e /dev/input/touchscreen0 ] then - # assume we are going to use event0 - ln -s /dev/input/event0 /dev/input/touchscreen0 + export QWS_MOUSE_PROTO=Tslib:/dev/input/touchscreen0 + # Check if the SD card is mounted and the first partition is + # vfat. If so let's write the pointercal file there so that if + # someone messes up calibration they can just delete the file from + # any system and reboot the board. + mount | grep /media/mmcblk0p1 | grep vfat > /dev/null 2>&1 + if [ "$?" = "0" ] + then + tsfile=/media/mmcblk0p1/pointercal + export TSLIB_CALIBFILE=$tsfile + fi - if [ ! -f /etc/pointercal ] ; then + if [ ! -f $tsfile ] ; then echo -n "Calibrating touchscreen (first time only)" ts_calibrate echo "." + # If we create a pointercal file and it was not in /etc/pointercal + # let's copy it there as well if it does not already exist. + if [ ! -f /etc/pointercal -a -f $tsfile ] + then + cp $tsfile /etc/pointercal + fi fi fi + #Clear out the the tmp and lock directory + cd __MATRIX_WEB_DIR__ + rm -rf tmp/* + rm -rf lock/* + cd - + if [ -e $PIDFILE ]; then PIDDIR=/proc/$(cat $PIDFILE) if [ -d ${PIDDIR} -a "$(readlink -f ${PIDDIR}/exe)" = "${matrixgui}" ]; then @@ -41,11 +69,6 @@ case "$1" in fi echo -n "Starting Matrix GUI application" - cd __MATRIX_BASE_DIR__ - start-stop-daemon --start --quiet --background --exec node -- server.js - # Need to investigate how to make the second start-stop command wait - # until the start of node is done. - sleep 5 start-stop-daemon --start --quiet --background --exec $matrixgui -- $GUI_OPTS pidof ${matrixgui} > $PIDFILE echo "." diff --git a/recipes-ti/matrix/matrix-gui_2.0.bb b/recipes-ti/matrix/matrix-gui_2.0.bb index 94a05b4..604101b 100644 --- a/recipes-ti/matrix/matrix-gui_2.0.bb +++ b/recipes-ti/matrix/matrix-gui_2.0.bb @@ -1,25 +1,40 @@ DESCRIPTION = "Matrix GUI Application launcher" HOMEPAGE = "https://gforge.ti.com/gf/project/matrix-gui-v2/" -LICENSE = "BSD MIT Apache" -LIC_FILES_CHKSUM = "file://javascript/jquery-latest.js;md5=9118381924c51c89d9414a311ec9c97f" +LICENSE = "BSD MIT" +LIC_FILES_CHKSUM = "file://LICENSE;md5=a886c9ef769b2d8271115d2502512e5d" SECTION = "multimedia" -PR = "r6" +PR = "r7" -inherit allarch +INITSCRIPT_NAME = "matrix-gui-2.0" +INITSCRIPT_PARAMS = "defaults 97" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +inherit update-rc.d BRANCH ?= "master" -SRCREV = "8e2bd5ffdded23bb662476fcd2490fa1526801f8" +SRCREV = "3a84b47505bf2be27fbcf30933f1261ed031ea9a" SRC_URI = "git://gitorious.org/matrix-gui-v2/matrix-gui-v2.git;protocol=git;branch=${BRANCH} \ + file://init \ file://php.ini" require matrix-gui-paths.inc S = "${WORKDIR}/git" +MATRIX_CONFIG = "800x480_config.ini" +MATRIX_CONFIG_am3517-evm = "480x272_config.ini" +MATRIX_CONFIG_am180x-evm = "480x272_config.ini" +MATRIX_CONFIG_am37x-evm = "640x480_config.ini" +MATRIX_CONFIG_beagleboard = "640x480_config.ini" + +MATRIX_ROT = "" +MATRIX_ROT_am37x-evm = "-display transformed:Rot90" + do_install(){ install -d ${D}${MATRIX_BASE_DIR} install -d ${D}${MATRIX_WEB_DIR} @@ -27,8 +42,20 @@ do_install(){ # Install our php.ini file install -m 0644 ${WORKDIR}/php.ini ${D}${MATRIX_BASE_DIR}/ + + # Set the proper path in the init script + sed -i -e s=__MATRIX_WEB_DIR__=${MATRIX_WEB_DIR}= ${WORKDIR}/init + sed -i -e "s/__MATRIX_ROT__/\"${MATRIX_ROT}\"/" ${WORKDIR}/init + + # Install the init script + # TODO: replace init script with systemd files + install -d ${D}${sysconfdir}/init.d + install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/matrix-gui-2.0 + + # Install the matrix config file to configure the screen resolution + install -m 0644 ${S}/matrix_config/${MATRIX_CONFIG} ${D}${MATRIX_WEB_DIR}/matrix_config.ini } -RDEPENDS_${PN} += "matrix-lighttpd-config lighttpd lighttpd-module-cgi lighttpd-module-compress lighttpd-module-expire php php-cgi php-cli" +RDEPENDS_${PN} += "matrix-lighttpd-config lighttpd lighttpd-module-cgi lighttpd-module-compress lighttpd-module-expire php php-cgi php-cli matrix-gui-browser refresh-screen" FILES_${PN} += "${MATRIX_BASE_DIR}/*" -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-26 18:46 [PATCH 1/3] matrix-gui-browser: port from arago overlay Chase Maupin 2012-01-26 18:46 ` [PATCH 2/3] refresh-screen: add package from arago Chase Maupin 2012-01-26 18:46 ` [PATCH 3/3] matrix-gui: update to latest version Chase Maupin @ 2012-01-26 22:44 ` William Mills 2012-01-27 11:50 ` Koen Kooi 2 siblings, 1 reply; 45+ messages in thread From: William Mills @ 2012-01-26 22:44 UTC (permalink / raw) To: Chase Maupin; +Cc: meta-ti On 01/26/2012 01:46 PM, Chase Maupin wrote: > * This package adds a simple web browser GUI application with > no decorations used to display matrix on the local display. > * Ported from arago overlay > Sorry for hijacking your patch Chase but I have serious big picture questions about all this stuff going into meta-ti and especially all into one layer. meta-ti is suppose to be the TI specific stuff people need to support their platforms regardless of what layer stack they are using. I understand we are not layer stack independent yet but that needs to be the goal. Certainly adding a whole bunch of non-HW related stuff into the same layer is not going to move us any closer. When we talked about where matrix belonged before there was debate about meta-oe or meta-arago. When did I miss the memo that put it into meta-ti?? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-26 22:44 ` [PATCH 1/3] matrix-gui-browser: port from arago overlay William Mills @ 2012-01-27 11:50 ` Koen Kooi 2012-01-27 12:09 ` Andreas Müller ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Koen Kooi @ 2012-01-27 11:50 UTC (permalink / raw) To: meta-ti Op 26 jan. 2012, om 23:44 heeft William Mills het volgende geschreven: > On 01/26/2012 01:46 PM, Chase Maupin wrote: >> * This package adds a simple web browser GUI application with >> no decorations used to display matrix on the local display. >> * Ported from arago overlay >> > > Sorry for hijacking your patch Chase but I have serious big picture questions about all this stuff going into meta-ti and especially all into one layer. > > meta-ti is suppose to be the TI specific stuff people need to support their platforms regardless of what layer stack they are using. I understand we are not layer stack independent yet but that needs to be the goal. Certainly adding a whole bunch of non-HW related stuff into the same layer is not going to move us any closer. > > When we talked about where matrix belonged before there was debate about meta-oe or meta-arago. When did I miss the memo that put it into meta-ti?? Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation. regards, Koen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 11:50 ` Koen Kooi @ 2012-01-27 12:09 ` Andreas Müller 2012-01-27 12:24 ` Koen Kooi 2012-01-27 13:50 ` Maupin, Chase 2012-01-27 17:30 ` William Mills 2 siblings, 1 reply; 45+ messages in thread From: Andreas Müller @ 2012-01-27 12:09 UTC (permalink / raw) To: meta-ti On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: > Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). > The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation. > I think splitting out BSP into an own layer is a good idea and sorry for another hijacking: This would be a good chance to make it independent of angstrom ( e.g ti-hw-bringup ). Andreas ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 12:09 ` Andreas Müller @ 2012-01-27 12:24 ` Koen Kooi 2012-01-27 17:38 ` William Mills 2012-01-27 19:39 ` Denys Dmytriyenko 0 siblings, 2 replies; 45+ messages in thread From: Koen Kooi @ 2012-01-27 12:24 UTC (permalink / raw) To: meta-ti Op 27 jan. 2012, om 13:09 heeft Andreas Müller het volgende geschreven: > On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). >> The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation. >> > I think splitting out BSP into an own layer is a good idea and sorry > for another hijacking: This would be a good chance to make it > independent of angstrom ( e.g ti-hw-bringup ). Image reuse is the least of the issues, SOC_FAMILY is a much larger one. regards, Koen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 12:24 ` Koen Kooi @ 2012-01-27 17:38 ` William Mills 2012-01-27 19:39 ` Denys Dmytriyenko 1 sibling, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 17:38 UTC (permalink / raw) To: Koen Kooi; +Cc: meta-ti On 01/27/2012 07:24 AM, Koen Kooi wrote: > > Op 27 jan. 2012, om 13:09 heeft Andreas Müller het volgende geschreven: > >> On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi<koen@dominion.thruhere.net> wrote: >>> Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). >>> The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation. >>> >> I think splitting out BSP into an own layer is a good idea and sorry >> for another hijacking: This would be a good chance to make it >> independent of angstrom ( e.g ti-hw-bringup ). > > Image reuse is the least of the issues, SOC_FAMILY is a much larger one. > Andreas: Yes, this is the layer stack independence that meta-ti is suppose to have and currently does not. When meta-ti is "done" it is suppose to work in: core layer stack: oe-core + meta-ti yocto layer stack: poky + meta-ti angstrom layer stack: oe-core + meta-oe + meta-angstrom + meta-ti + many more) arago layer stack: TBD but at least oe-core + meta-oe + meta-ti + meta-arago) As Koen points out we have a good many hurdles to get to the above. Stay tuned. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 12:24 ` Koen Kooi 2012-01-27 17:38 ` William Mills @ 2012-01-27 19:39 ` Denys Dmytriyenko 2012-01-27 19:47 ` Koen Kooi 1 sibling, 1 reply; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 19:39 UTC (permalink / raw) To: Koen Kooi; +Cc: meta-ti On Fri, Jan 27, 2012 at 01:24:14PM +0100, Koen Kooi wrote: > > Op 27 jan. 2012, om 13:09 heeft Andreas M?ller het volgende geschreven: > > > On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi <koen@dominion.thruhere.net> > > wrote: > >> Since meta-arago is supposed to be as empty as possible and matrix > >> doesn't play well with others it's a bad fit for both meta-arago and > >> meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for > >> BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). > >> The idea is to keep reusable TI deliverables together without forcing > >> people to use arago. Putting matrix in meta-arago would mean you can only > >> use it with DISTRO=arago, which is a huge step backwards from the current > >> situation. > > > > I think splitting out BSP into an own layer is a good idea and sorry > > for another hijacking: This would be a good chance to make it > > independent of angstrom ( e.g ti-hw-bringup ). > > Image reuse is the least of the issues, SOC_FAMILY is a much larger one. Koen, Can you please elaborate on the SOC_FAMILY issue you mentioned? Thanks. -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 19:39 ` Denys Dmytriyenko @ 2012-01-27 19:47 ` Koen Kooi 2012-01-27 20:09 ` Denys Dmytriyenko 0 siblings, 1 reply; 45+ messages in thread From: Koen Kooi @ 2012-01-27 19:47 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti Op 27 jan. 2012, om 20:39 heeft Denys Dmytriyenko het volgende geschreven: > On Fri, Jan 27, 2012 at 01:24:14PM +0100, Koen Kooi wrote: >> >> Op 27 jan. 2012, om 13:09 heeft Andreas M?ller het volgende geschreven: >> >>> On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi <koen@dominion.thruhere.net> >>> wrote: >>>> Since meta-arago is supposed to be as empty as possible and matrix >>>> doesn't play well with others it's a bad fit for both meta-arago and >>>> meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for >>>> BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). >>>> The idea is to keep reusable TI deliverables together without forcing >>>> people to use arago. Putting matrix in meta-arago would mean you can only >>>> use it with DISTRO=arago, which is a huge step backwards from the current >>>> situation. >>> >>> I think splitting out BSP into an own layer is a good idea and sorry >>> for another hijacking: This would be a good chance to make it >>> independent of angstrom ( e.g ti-hw-bringup ). >> >> Image reuse is the least of the issues, SOC_FAMILY is a much larger one. > > Koen, > > Can you please elaborate on the SOC_FAMILY issue you mentioned? Thanks. We need support for it, only angstrom does at the moment. The big problem is that the solution can't be layer-local since other layers will use it as well. Having duplicates in OVERRIDES is a nightmare. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 19:47 ` Koen Kooi @ 2012-01-27 20:09 ` Denys Dmytriyenko 0 siblings, 0 replies; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:09 UTC (permalink / raw) To: Koen Kooi; +Cc: meta-ti On Fri, Jan 27, 2012 at 08:47:29PM +0100, Koen Kooi wrote: > > Op 27 jan. 2012, om 20:39 heeft Denys Dmytriyenko het volgende geschreven: > > > On Fri, Jan 27, 2012 at 01:24:14PM +0100, Koen Kooi wrote: > >> > >> Op 27 jan. 2012, om 13:09 heeft Andreas M?ller het volgende geschreven: > >> > >>> On Fri, Jan 27, 2012 at 12:50 PM, Koen Kooi <koen@dominion.thruhere.net> > >>> wrote: > >>>> Since meta-arago is supposed to be as empty as possible and matrix > >>>> doesn't play well with others it's a bad fit for both meta-arago and > >>>> meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for > >>>> BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). > >>>> The idea is to keep reusable TI deliverables together without forcing > >>>> people to use arago. Putting matrix in meta-arago would mean you can only > >>>> use it with DISTRO=arago, which is a huge step backwards from the current > >>>> situation. > >>> > >>> I think splitting out BSP into an own layer is a good idea and sorry > >>> for another hijacking: This would be a good chance to make it > >>> independent of angstrom ( e.g ti-hw-bringup ). > >> > >> Image reuse is the least of the issues, SOC_FAMILY is a much larger one. > > > > Koen, > > > > Can you please elaborate on the SOC_FAMILY issue you mentioned? Thanks. > > We need support for it, only angstrom does at the moment. The big problem is > that the solution can't be layer-local since other layers will use it as > well. Having duplicates in OVERRIDES is a nightmare. Adding SOC_FAMILY into MACHINEOVERRIDES portion of OVERRIDES and making sure sstate recognizes it... Why not push this change to OE-Core? -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 11:50 ` Koen Kooi 2012-01-27 12:09 ` Andreas Müller @ 2012-01-27 13:50 ` Maupin, Chase 2012-01-27 14:54 ` Philip Balister 2012-01-27 17:51 ` William Mills 2012-01-27 17:30 ` William Mills 2 siblings, 2 replies; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 13:50 UTC (permalink / raw) To: Koen Kooi, meta-ti@yoctoproject.org > -----Original Message----- > From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti- > bounces@yoctoproject.org] On Behalf Of Koen Kooi > Sent: Friday, January 27, 2012 5:51 AM > To: meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > > Op 26 jan. 2012, om 23:44 heeft William Mills het volgende > geschreven: > > > On 01/26/2012 01:46 PM, Chase Maupin wrote: > >> * This package adds a simple web browser GUI application with > >> no decorations used to display matrix on the local display. > >> * Ported from arago overlay > >> > > > > Sorry for hijacking your patch Chase but I have serious big > picture questions about all this stuff going into meta-ti and > especially all into one layer. > > > > meta-ti is suppose to be the TI specific stuff people need to > support their platforms regardless of what layer stack they are > using. I understand we are not layer stack independent yet but > that needs to be the goal. Certainly adding a whole bunch of non- > HW related stuff into the same layer is not going to move us any > closer. > > > > When we talked about where matrix belonged before there was > debate about meta-oe or meta-arago. When did I miss the memo that > put it into meta-ti?? > > Since meta-arago is supposed to be as empty as possible and matrix > doesn't play well with others it's a bad fit for both meta-arago > and meta-oe. Maybe we should split the meta-ti repo into 2 layers: > one for BSP things (including sgx, dsp, etc) and one for 'sdk' > things (matrix). > The idea is to keep reusable TI deliverables together without > forcing people to use arago. Putting matrix in meta-arago would > mean you can only use it with DISTRO=arago, which is a huge step > backwards from the current situation. I think Koen got it right here. We can split meta-ti, but I definitely don’t think matrix belongs in meta-arago. As for meta-oe my thoughts are: 1. As of now matrix is only maintained by TI and used by TI (and Koen to some extent) on our products. So I would put this in a layer that we maintain because it would seem strange to me to have to go through another set of maintainers to update the SRCREV of the package we are developing. Particularly if no one is using it. 2. If people wanted matrix they could still include our layer to get it. If we see that happening a lot a there is a request from a group of people to have this then we could push it lower, but if we are the only ones using it and who care about it then I don't see the reason to move this lower in the layer stack. > > regards, > > Koen > _______________________________________________ > meta-ti mailing list > meta-ti@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-ti ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 13:50 ` Maupin, Chase @ 2012-01-27 14:54 ` Philip Balister 2012-01-27 15:19 ` Maupin, Chase 2012-01-27 17:51 ` William Mills 1 sibling, 1 reply; 45+ messages in thread From: Philip Balister @ 2012-01-27 14:54 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 08:50 AM, Maupin, Chase wrote: >> -----Original Message----- >> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti- >> bounces@yoctoproject.org] On Behalf Of Koen Kooi >> Sent: Friday, January 27, 2012 5:51 AM >> To: meta-ti@yoctoproject.org >> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from >> arago overlay >> >> >> Op 26 jan. 2012, om 23:44 heeft William Mills het volgende >> geschreven: >> >>> On 01/26/2012 01:46 PM, Chase Maupin wrote: >>>> * This package adds a simple web browser GUI application with >>>> no decorations used to display matrix on the local display. >>>> * Ported from arago overlay >>>> >>> >>> Sorry for hijacking your patch Chase but I have serious big >> picture questions about all this stuff going into meta-ti and >> especially all into one layer. >>> >>> meta-ti is suppose to be the TI specific stuff people need to >> support their platforms regardless of what layer stack they are >> using. I understand we are not layer stack independent yet but >> that needs to be the goal. Certainly adding a whole bunch of non- >> HW related stuff into the same layer is not going to move us any >> closer. >>> >>> When we talked about where matrix belonged before there was >> debate about meta-oe or meta-arago. When did I miss the memo that >> put it into meta-ti?? >> >> Since meta-arago is supposed to be as empty as possible and matrix >> doesn't play well with others it's a bad fit for both meta-arago >> and meta-oe. Maybe we should split the meta-ti repo into 2 layers: >> one for BSP things (including sgx, dsp, etc) and one for 'sdk' >> things (matrix). >> The idea is to keep reusable TI deliverables together without >> forcing people to use arago. Putting matrix in meta-arago would >> mean you can only use it with DISTRO=arago, which is a huge step >> backwards from the current situation. > > I think Koen got it right here. We can split meta-ti, but I definitely don’t think matrix belongs in meta-arago. As for meta-oe my thoughts are: > > 1. As of now matrix is only maintained by TI and used by TI (and Koen to some extent) on our products. So I would put this in a layer that we maintain because it would seem strange to me to have to go through another set of maintainers to update the SRCREV of the package we are developing. Particularly if no one is using it. > 2. If people wanted matrix they could still include our layer to get it. If we see that happening a lot a there is a request from a group of people to have this then we could push it lower, but if we are the only ones using it and who care about it then I don't see the reason to move this lower in the layer stack. What do the programs in question do? Philip > >> >> regards, >> >> Koen >> _______________________________________________ >> meta-ti mailing list >> meta-ti@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-ti > _______________________________________________ > meta-ti mailing list > meta-ti@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-ti > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 14:54 ` Philip Balister @ 2012-01-27 15:19 ` Maupin, Chase 0 siblings, 0 replies; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 15:19 UTC (permalink / raw) To: Philip Balister; +Cc: meta-ti@yoctoproject.org > -----Original Message----- > From: Philip Balister [mailto:philip@balister.org] > Sent: Friday, January 27, 2012 8:54 AM > To: Maupin, Chase > Cc: Koen Kooi; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > On 01/27/2012 08:50 AM, Maupin, Chase wrote: > >> -----Original Message----- > >> From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti- > >> bounces@yoctoproject.org] On Behalf Of Koen Kooi > >> Sent: Friday, January 27, 2012 5:51 AM > >> To: meta-ti@yoctoproject.org > >> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > >> arago overlay > >> > >> > >> Op 26 jan. 2012, om 23:44 heeft William Mills het volgende > >> geschreven: > >> > >>> On 01/26/2012 01:46 PM, Chase Maupin wrote: > >>>> * This package adds a simple web browser GUI application with > >>>> no decorations used to display matrix on the local display. > >>>> * Ported from arago overlay > >>>> > >>> > >>> Sorry for hijacking your patch Chase but I have serious big > >> picture questions about all this stuff going into meta-ti and > >> especially all into one layer. > >>> > >>> meta-ti is suppose to be the TI specific stuff people need to > >> support their platforms regardless of what layer stack they are > >> using. I understand we are not layer stack independent yet but > >> that needs to be the goal. Certainly adding a whole bunch of > non- > >> HW related stuff into the same layer is not going to move us any > >> closer. > >>> > >>> When we talked about where matrix belonged before there was > >> debate about meta-oe or meta-arago. When did I miss the memo > that > >> put it into meta-ti?? > >> > >> Since meta-arago is supposed to be as empty as possible and > matrix > >> doesn't play well with others it's a bad fit for both meta-arago > >> and meta-oe. Maybe we should split the meta-ti repo into 2 > layers: > >> one for BSP things (including sgx, dsp, etc) and one for 'sdk' > >> things (matrix). > >> The idea is to keep reusable TI deliverables together without > >> forcing people to use arago. Putting matrix in meta-arago would > >> mean you can only use it with DISTRO=arago, which is a huge step > >> backwards from the current situation. > > > > I think Koen got it right here. We can split meta-ti, but I > definitely don’t think matrix belongs in meta-arago. As for meta- > oe my thoughts are: > > > > 1. As of now matrix is only maintained by TI and used by TI (and > Koen to some extent) on our products. So I would put this in a > layer that we maintain because it would seem strange to me to have > to go through another set of maintainers to update the SRCREV of > the package we are developing. Particularly if no one is using it. > > 2. If people wanted matrix they could still include our layer to > get it. If we see that happening a lot a there is a request from a > group of people to have this then we could push it lower, but if we > are the only ones using it and who care about it then I don't see > the reason to move this lower in the layer stack. > > What do the programs in question do? Matrix is an application launcher that reads .desktop files and presents icons to the screen (or any remote browser) to launch the applications. We use it for our out-of-box demo to give customers an easy way to evaluate functionality on our devices. You can find out more at http://processors.wiki.ti.com/index.php/Matrix_Users_Guide The .desktop files use some custom fields as well but we used standard fields where possible. > > Philip > > > > > >> > >> regards, > >> > >> Koen > >> _______________________________________________ > >> meta-ti mailing list > >> meta-ti@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/meta-ti > > _______________________________________________ > > meta-ti mailing list > > meta-ti@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/meta-ti > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 13:50 ` Maupin, Chase 2012-01-27 14:54 ` Philip Balister @ 2012-01-27 17:51 ` William Mills 2012-01-27 19:46 ` Maupin, Chase 1 sibling, 1 reply; 45+ messages in thread From: William Mills @ 2012-01-27 17:51 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 08:50 AM, Maupin, Chase wrote: > but I definitely don’t think matrix belongs in meta-arago Why, justify. Yes matrix needs to be different than the distro definition on arago but As you point out below the only people using Matrix are Arago and Koen in Angstrom. I think this comes down to not wanting the word "arago" occurring in the Angstrom layer stack. meta-ti should be about using TI chips. Matrix and other demo programs we put together for our demo distro are not essential to using TI chips. > > 1. As of now matrix is only maintained by TI and used by TI (and Koen to some extent) on our products. So I would put this in a layer that we maintain because it would seem strange to me to have to go through another set of maintainers to update the SRCREV of the package we are developing. Particularly if no one is using it. > 2. If people wanted matrix they could still include our layer to get it. If we see that happening a lot a there is a request from a group of people to have this then we could push it lower, but if we are the only ones using it and who care about it then I don't see the reason to move this lower in the layer stack. > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 17:51 ` William Mills @ 2012-01-27 19:46 ` Maupin, Chase 2012-01-27 20:03 ` William Mills 2012-01-27 20:11 ` William Mills 0 siblings, 2 replies; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 19:46 UTC (permalink / raw) To: Mills, William; +Cc: meta-ti@yoctoproject.org > -----Original Message----- > From: Mills, William > Sent: Friday, January 27, 2012 11:51 AM > To: Maupin, Chase > Cc: Koen Kooi; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > On 01/27/2012 08:50 AM, Maupin, Chase wrote: > > > but I definitely don’t think matrix belongs in meta-arago > > Why, justify. Yes matrix needs to be different than the distro > definition on arago but As you point out below the only people > using > Matrix are Arago and Koen in Angstrom. I think this comes down to > not > wanting the word "arago" occurring in the Angstrom layer stack. > > meta-ti should be about using TI chips. Matrix and other demo > programs > we put together for our demo distro are not essential to using TI > chips. I guess we have a difference of opinion on how we see meta-arago. I don’t separate that layer into distro and non-distro. I was really planning on meta-arago being all the stuff related to the arago/SDK distribution. Meta-ti is for TI packages that can be used by other distros. That being said I'm OK with meta-ti being split into a BSP layer and everthing else, but I don't know exactly what that buys us. Does it particularly hurt someone that pulls in meta-ti to have access to matrix if they don't use it? I pull in things from meta-oe or oe-core that I don’t "need" but they are there anyway. > > > > > 1. As of now matrix is only maintained by TI and used by TI (and > Koen to some extent) on our products. So I would put this in a > layer that we maintain because it would seem strange to me to have > to go through another set of maintainers to update the SRCREV of > the package we are developing. Particularly if no one is using it. > > 2. If people wanted matrix they could still include our layer to > get it. If we see that happening a lot a there is a request from a > group of people to have this then we could push it lower, but if we > are the only ones using it and who care about it then I don't see > the reason to move this lower in the layer stack. > > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 19:46 ` Maupin, Chase @ 2012-01-27 20:03 ` William Mills 2012-01-27 20:05 ` William Mills 2012-01-27 20:10 ` Tom Rini 2012-01-27 20:11 ` William Mills 1 sibling, 2 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:03 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org OK this part is off list. Go look at meta-intel and then look at the meta-ti your guys are purposing. Now, your an engineer in a hurry and you need to choose between intel ATOM and TI ARM. Which one looks simpler, clearer, and well organized. Which do you want to use? We are already way behind on simplicity of message. We need to keep as much stuff out of here as we can. On 01/27/2012 02:46 PM, Maupin, Chase wrote: >> -----Original Message----- >> From: Mills, William >> Sent: Friday, January 27, 2012 11:51 AM >> To: Maupin, Chase >> Cc: Koen Kooi; meta-ti@yoctoproject.org >> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from >> arago overlay >> >> On 01/27/2012 08:50 AM, Maupin, Chase wrote: >> >> > but I definitely don’t think matrix belongs in meta-arago >> >> Why, justify. Yes matrix needs to be different than the distro >> definition on arago but As you point out below the only people >> using >> Matrix are Arago and Koen in Angstrom. I think this comes down to >> not >> wanting the word "arago" occurring in the Angstrom layer stack. >> >> meta-ti should be about using TI chips. Matrix and other demo >> programs >> we put together for our demo distro are not essential to using TI >> chips. > I guess we have a difference of opinion on how we see meta-arago. I don’t separate that layer into distro and non-distro. I was really planning on meta-arago being all the stuff related to the arago/SDK distribution. Meta-ti is for TI packages that can be used by other distros. That being said I'm OK with meta-ti being split into a BSP layer and everthing else, but I don't know exactly what that buys us. Does it particularly hurt someone that pulls in meta-ti to have access to matrix if they don't use it? I pull in things from meta-oe or oe-core that I don’t "need" but they are there anyway. > >>> 1. As of now matrix is only maintained by TI and used by TI (and >> Koen to some extent) on our products. So I would put this in a >> layer that we maintain because it would seem strange to me to have >> to go through another set of maintainers to update the SRCREV of >> the package we are developing. Particularly if no one is using it. >>> 2. If people wanted matrix they could still include our layer to >> get it. If we see that happening a lot a there is a request from a >> group of people to have this then we could push it lower, but if we >> are the only ones using it and who care about it then I don't see >> the reason to move this lower in the layer stack. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:03 ` William Mills @ 2012-01-27 20:05 ` William Mills 2012-01-27 20:10 ` Tom Rini 1 sibling, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:05 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:03 PM, William Mills wrote: > OK this part is off list. > Or not. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:03 ` William Mills 2012-01-27 20:05 ` William Mills @ 2012-01-27 20:10 ` Tom Rini 2012-01-27 20:11 ` Denys Dmytriyenko 1 sibling, 1 reply; 45+ messages in thread From: Tom Rini @ 2012-01-27 20:10 UTC (permalink / raw) To: William Mills; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 1:03 PM, William Mills <wmills@ti.com> wrote: > OK this part is off list. > > Go look at meta-intel and then look at the meta-ti your guys are purposing. > Now, your an engineer in a hurry and you need to choose between intel ATOM > and TI ARM. Which one looks simpler, clearer, and well organized. Which do > you want to use? The problem we have here is that one of them (meta-intel) is "just use poky and this" and one of them is "just use angstrom and meta-oe and this". And we need to figure out which use cases we want to support, and how. -- Tom ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:10 ` Tom Rini @ 2012-01-27 20:11 ` Denys Dmytriyenko 2012-01-27 20:19 ` Philip Balister 2012-01-27 20:20 ` William Mills 0 siblings, 2 replies; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:11 UTC (permalink / raw) To: Tom Rini; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 01:10:22PM -0700, Tom Rini wrote: > On Fri, Jan 27, 2012 at 1:03 PM, William Mills <wmills@ti.com> wrote: > > OK this part is off list. > > > > Go look at meta-intel and then look at the meta-ti your guys are purposing. > > Now, your an engineer in a hurry and you need to choose between intel ATOM > > and TI ARM. Which one looks simpler, clearer, and well organized. Which do > > you want to use? > > The problem we have here is that one of them (meta-intel) is "just use > poky and this" and one of them is "just use angstrom and meta-oe and > this". And we need to figure out which use cases we want to support, > and how. "Just use poky and this" is also a valid use case for us. -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:11 ` Denys Dmytriyenko @ 2012-01-27 20:19 ` Philip Balister 2012-01-27 20:24 ` Denys Dmytriyenko 2012-01-27 20:20 ` William Mills 1 sibling, 1 reply; 45+ messages in thread From: Philip Balister @ 2012-01-27 20:19 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:11 PM, Denys Dmytriyenko wrote: > On Fri, Jan 27, 2012 at 01:10:22PM -0700, Tom Rini wrote: >> On Fri, Jan 27, 2012 at 1:03 PM, William Mills <wmills@ti.com> wrote: >>> OK this part is off list. >>> >>> Go look at meta-intel and then look at the meta-ti your guys are purposing. >>> Now, your an engineer in a hurry and you need to choose between intel ATOM >>> and TI ARM. Which one looks simpler, clearer, and well organized. Which do >>> you want to use? >> >> The problem we have here is that one of them (meta-intel) is "just use >> poky and this" and one of them is "just use angstrom and meta-oe and >> this". And we need to figure out which use cases we want to support, >> and how. > > "Just use poky and this" is also a valid use case for us. > But not for me. I need recipes from meta-oe to ship USRP-E100's and it is nice having binary feeds available for customer use. (Angstrom adds binary feeds to the mix). Philip ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:19 ` Philip Balister @ 2012-01-27 20:24 ` Denys Dmytriyenko 0 siblings, 0 replies; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:24 UTC (permalink / raw) To: Philip Balister; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 03:19:52PM -0500, Philip Balister wrote: > On 01/27/2012 03:11 PM, Denys Dmytriyenko wrote: > > On Fri, Jan 27, 2012 at 01:10:22PM -0700, Tom Rini wrote: > >> On Fri, Jan 27, 2012 at 1:03 PM, William Mills <wmills@ti.com> wrote: > >>> OK this part is off list. > >>> > >>> Go look at meta-intel and then look at the meta-ti your guys are purposing. > >>> Now, your an engineer in a hurry and you need to choose between intel ATOM > >>> and TI ARM. Which one looks simpler, clearer, and well organized. Which do > >>> you want to use? > >> > >> The problem we have here is that one of them (meta-intel) is "just use > >> poky and this" and one of them is "just use angstrom and meta-oe and > >> this". And we need to figure out which use cases we want to support, > >> and how. > > > > "Just use poky and this" is also a valid use case for us. > > > > But not for me. I need recipes from meta-oe to ship USRP-E100's and it > is nice having binary feeds available for customer use. (Angstrom adds > binary feeds to the mix). It always possible to add-on stuff. But it's not so easy to remove. Remember how awfully huge and messy Classic OE was... Layers were supposed to fix that! -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:11 ` Denys Dmytriyenko 2012-01-27 20:19 ` Philip Balister @ 2012-01-27 20:20 ` William Mills 1 sibling, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:20 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org, Darren Hart On 01/27/2012 03:11 PM, Denys Dmytriyenko wrote: > On Fri, Jan 27, 2012 at 01:10:22PM -0700, Tom Rini wrote: >> On Fri, Jan 27, 2012 at 1:03 PM, William Mills<wmills@ti.com> wrote: >>> OK this part is off list. >>> >>> Go look at meta-intel and then look at the meta-ti your guys are purposing. >>> Now, your an engineer in a hurry and you need to choose between intel ATOM >>> and TI ARM. Which one looks simpler, clearer, and well organized. Which do >>> you want to use? >> The problem we have here is that one of them (meta-intel) is "just use >> poky and this" and one of them is "just use angstrom and meta-oe and >> this". And we need to figure out which use cases we want to support, >> and how. > "Just use poky and this" is also a valid use case for us. Yes, but Tom has a point. I was hoping meta-ti could be an example of how a Si vendor could publish their stuff for the OE ecosystem in general w/o a poky, angstrom, etc bias. Maybe convince the intel guys they should look at doing the same. The more stuff we pile into this the harder it is to see that message. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 19:46 ` Maupin, Chase 2012-01-27 20:03 ` William Mills @ 2012-01-27 20:11 ` William Mills 2012-01-27 20:17 ` Maupin, Chase 1 sibling, 1 reply; 45+ messages in thread From: William Mills @ 2012-01-27 20:11 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 02:46 PM, Maupin, Chase wrote: > I guess we have a difference of opinion on how we see meta-arago. I > don’t separate that layer into distro and non-distro. I was really > planning on meta-arago being all the stuff related to the arago/SDK > distribution. Meta-ti is for TI packages that can be used by other > distros. That being said I'm OK with meta-ti being split into a BSP > layer and everthing else, but I don't know exactly what that buys us. > Does it particularly hurt someone that pulls in meta-ti to have access > to matrix if they don't use it? I pull in things from meta-oe or > oe-core that I don’t "need" but they are there anyway. Do you know that everything you are putting in meta-ti today only depends on oe-core? I don't think you do as we are not testing that today. Yes, in the old days a recipie collection had tons of stuff that would be present but just fail if you actually tried to use it. The point of layers was to clean that up. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:11 ` William Mills @ 2012-01-27 20:17 ` Maupin, Chase 2012-01-27 20:21 ` Denys Dmytriyenko 0 siblings, 1 reply; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 20:17 UTC (permalink / raw) To: Mills, William; +Cc: meta-ti@yoctoproject.org > -----Original Message----- > From: Mills, William > Sent: Friday, January 27, 2012 2:11 PM > To: Maupin, Chase > Cc: Koen Kooi; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > > On 01/27/2012 02:46 PM, Maupin, Chase wrote: > > I guess we have a difference of opinion on how we see meta-arago. > I > > don’t separate that layer into distro and non-distro. I was > really > > planning on meta-arago being all the stuff related to the > arago/SDK > > distribution. Meta-ti is for TI packages that can be used by > other > > distros. That being said I'm OK with meta-ti being split into a > BSP > > layer and everthing else, but I don't know exactly what that buys > us. > > Does it particularly hurt someone that pulls in meta-ti to have > access > > to matrix if they don't use it? I pull in things from meta-oe or > > oe-core that I don’t "need" but they are there anyway. > > Do you know that everything you are putting in meta-ti today only > depends on oe-core? I don't think you do as we are not testing > that > today. Yes, in the old days a recipie collection had tons of stuff > that > would be present but just fail if you actually tried to use it. > The > point of layers was to clean that up. Not sure what your comment about only needing oe-core is. For example I use lmbench but I don’t see that in oe-core. I get that from meta-oe. I can agree to spliting meta-ti into two layers, a HW layer for our devices and a layer containing all of the TI recipes. But if we wanted to match the meta-intel layer way would you also propose making a layer per device? I personally find that more confusing. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:17 ` Maupin, Chase @ 2012-01-27 20:21 ` Denys Dmytriyenko 2012-01-27 20:24 ` William Mills 2012-01-27 20:53 ` Koen Kooi 0 siblings, 2 replies; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:21 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: > > -----Original Message----- > > From: Mills, William > > Sent: Friday, January 27, 2012 2:11 PM > > To: Maupin, Chase > > Cc: Koen Kooi; meta-ti@yoctoproject.org > > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > > arago overlay > > > > > > On 01/27/2012 02:46 PM, Maupin, Chase wrote: > > > I guess we have a difference of opinion on how we see meta-arago. > > I > > > don?t separate that layer into distro and non-distro. I was > > really > > > planning on meta-arago being all the stuff related to the > > arago/SDK > > > distribution. Meta-ti is for TI packages that can be used by > > other > > > distros. That being said I'm OK with meta-ti being split into a > > BSP > > > layer and everthing else, but I don't know exactly what that buys > > us. > > > Does it particularly hurt someone that pulls in meta-ti to have > > access > > > to matrix if they don't use it? I pull in things from meta-oe or > > > oe-core that I don?t "need" but they are there anyway. > > > > Do you know that everything you are putting in meta-ti today only > > depends on oe-core? I don't think you do as we are not testing > > that > > today. Yes, in the old days a recipie collection had tons of stuff > > that > > would be present but just fail if you actually tried to use it. > > The > > point of layers was to clean that up. > > Not sure what your comment about only needing oe-core is. For example I use > lmbench but I don?t see that in oe-core. I get that from meta-oe. I can > agree to spliting meta-ti into two layers, a HW layer for our devices and a > layer containing all of the TI recipes. > > But if we wanted to match the meta-intel layer way would you also propose > making a layer per device? I personally find that more confusing. I don't think that was Bill's message. It was simplicity. BSP only layer, no supplemental apps, if not absolutely required. Your example with lmbench is not correct - BSP layer should be simple enough to be used with OE-Core alone to produce a console rootfs image with nothing but busybox. How about splitting meta-ti into: * BSP only * SGX graphics * DSP tools * WiFi etc. And then splitting meta-arago into: * Arago distro for TI SDKs * Supplemental apps -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:21 ` Denys Dmytriyenko @ 2012-01-27 20:24 ` William Mills 2012-01-27 20:29 ` Maupin, Chase 2012-01-27 20:50 ` Philip Balister 2012-01-27 20:53 ` Koen Kooi 1 sibling, 2 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:24 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:21 PM, Denys Dmytriyenko wrote: > On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: >>> -----Original Message----- >>> From: Mills, William >>> Sent: Friday, January 27, 2012 2:11 PM >>> To: Maupin, Chase >>> Cc: Koen Kooi; meta-ti@yoctoproject.org >>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from >>> arago overlay >>> >>> >>> On 01/27/2012 02:46 PM, Maupin, Chase wrote: >>>> I guess we have a difference of opinion on how we see meta-arago. >>> I >>>> don?t separate that layer into distro and non-distro. I was >>> really >>>> planning on meta-arago being all the stuff related to the >>> arago/SDK >>>> distribution. Meta-ti is for TI packages that can be used by >>> other >>>> distros. That being said I'm OK with meta-ti being split into a >>> BSP >>>> layer and everthing else, but I don't know exactly what that buys >>> us. >>>> Does it particularly hurt someone that pulls in meta-ti to have >>> access >>>> to matrix if they don't use it? I pull in things from meta-oe or >>>> oe-core that I don?t "need" but they are there anyway. >>> Do you know that everything you are putting in meta-ti today only >>> depends on oe-core? I don't think you do as we are not testing >>> that >>> today. Yes, in the old days a recipie collection had tons of stuff >>> that >>> would be present but just fail if you actually tried to use it. >>> The >>> point of layers was to clean that up. >> Not sure what your comment about only needing oe-core is. For example I use >> lmbench but I don?t see that in oe-core. I get that from meta-oe. I can >> agree to spliting meta-ti into two layers, a HW layer for our devices and a >> layer containing all of the TI recipes. >> >> But if we wanted to match the meta-intel layer way would you also propose >> making a layer per device? I personally find that more confusing. > I don't think that was Bill's message. It was simplicity. BSP only layer, no > supplemental apps, if not absolutely required. > > Your example with lmbench is not correct - BSP layer should be simple enough > to be used with OE-Core alone to produce a console rootfs image with nothing > but busybox. > > How about splitting meta-ti into: > * BSP only > * SGX graphics > * DSP tools > * WiFi etc. > > And then splitting meta-arago into: > * Arago distro for TI SDKs > * Supplemental apps > Need to get my "YES!" in here before everyone barfs all over the proposal :) Chase: your right. I do not want to follow intel's example of layer per BSP. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:24 ` William Mills @ 2012-01-27 20:29 ` Maupin, Chase 2012-01-27 20:34 ` Denys Dmytriyenko 2012-01-27 20:34 ` William Mills 2012-01-27 20:50 ` Philip Balister 1 sibling, 2 replies; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 20:29 UTC (permalink / raw) To: Mills, William, Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org > -----Original Message----- > From: Mills, William > Sent: Friday, January 27, 2012 2:25 PM > To: Denys Dmytriyenko > Cc: Maupin, Chase; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > > > On 01/27/2012 03:21 PM, Denys Dmytriyenko wrote: > > On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: > >>> -----Original Message----- > >>> From: Mills, William > >>> Sent: Friday, January 27, 2012 2:11 PM > >>> To: Maupin, Chase > >>> Cc: Koen Kooi; meta-ti@yoctoproject.org > >>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port > from > >>> arago overlay > >>> > >>> > >>> On 01/27/2012 02:46 PM, Maupin, Chase wrote: > >>>> I guess we have a difference of opinion on how we see meta- > arago. > >>> I > >>>> don?t separate that layer into distro and non-distro. I was > >>> really > >>>> planning on meta-arago being all the stuff related to the > >>> arago/SDK > >>>> distribution. Meta-ti is for TI packages that can be used by > >>> other > >>>> distros. That being said I'm OK with meta-ti being split into > a > >>> BSP > >>>> layer and everthing else, but I don't know exactly what that > buys > >>> us. > >>>> Does it particularly hurt someone that pulls in meta-ti to > have > >>> access > >>>> to matrix if they don't use it? I pull in things from meta-oe > or > >>>> oe-core that I don?t "need" but they are there anyway. > >>> Do you know that everything you are putting in meta-ti today > only > >>> depends on oe-core? I don't think you do as we are not testing > >>> that > >>> today. Yes, in the old days a recipie collection had tons of > stuff > >>> that > >>> would be present but just fail if you actually tried to use it. > >>> The > >>> point of layers was to clean that up. > >> Not sure what your comment about only needing oe-core is. For > example I use > >> lmbench but I don?t see that in oe-core. I get that from meta- > oe. I can > >> agree to spliting meta-ti into two layers, a HW layer for our > devices and a > >> layer containing all of the TI recipes. > >> > >> But if we wanted to match the meta-intel layer way would you > also propose > >> making a layer per device? I personally find that more > confusing. > > I don't think that was Bill's message. It was simplicity. BSP > only layer, no > > supplemental apps, if not absolutely required. > > > > Your example with lmbench is not correct - BSP layer should be > simple enough > > to be used with OE-Core alone to produce a console rootfs image > with nothing > > but busybox. > > > > How about splitting meta-ti into: > > * BSP only > > * SGX graphics > > * DSP tools > > * WiFi etc. > > > > And then splitting meta-arago into: > > * Arago distro for TI SDKs > > * Supplemental apps > > > > Need to get my "YES!" in here before everyone barfs all over the > proposal :) I'm good with this. I was also planning in meta-arago to at least put all bbappends in a recipes-appends directory so it was easy to track the things we are "tweaking" vs. the recipes. Arago today is too much of a mix between amends and recipes in my opinion. I would even say that Tom's proposal (from IRC) of splitting the arago distro and supplemental apps into two layers would be a good idea so that other distros can pull our supplemental apps if they want pretty easily. And that way we don’t keep adding more repos to manage. > > Chase: your right. I do not want to follow intel's example of > layer per > BSP. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:29 ` Maupin, Chase @ 2012-01-27 20:34 ` Denys Dmytriyenko 2012-01-27 20:39 ` Maupin, Chase 2012-01-27 20:34 ` William Mills 1 sibling, 1 reply; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:34 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 08:29:42PM +0000, Maupin, Chase wrote: > > > I don't think that was Bill's message. It was simplicity. BSP > > only layer, no > > > supplemental apps, if not absolutely required. > > > > > > Your example with lmbench is not correct - BSP layer should be > > simple enough > > > to be used with OE-Core alone to produce a console rootfs image > > with nothing > > > but busybox. > > > > > > How about splitting meta-ti into: > > > * BSP only > > > * SGX graphics > > > * DSP tools > > > * WiFi etc. > > > > > > And then splitting meta-arago into: > > > * Arago distro for TI SDKs > > > * Supplemental apps > > > > > > > Need to get my "YES!" in here before everyone barfs all over the > > proposal :) > > I'm good with this. I was also planning in meta-arago to at least put all > bbappends in a recipes-appends directory so it was easy to track the things > we are "tweaking" vs. the recipes. Arago today is too much of a mix between > amends and recipes in my opinion. I would even say that Tom's proposal > (from IRC) of splitting the arago distro and supplemental apps into two > layers would be a good idea so that other distros can pull our supplemental > apps if they want pretty easily. And that way we don?t keep adding more > repos to manage. Actually that was my proposal (and Bill's offline), but never mind :) As of today's state of Arago - if you don't count recipes/ti, which was "untouchable" for some special reasons, everything else is quite clean with using amends everywhere possible! And our of all the people you should know this better. -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:34 ` Denys Dmytriyenko @ 2012-01-27 20:39 ` Maupin, Chase 2012-01-27 20:42 ` William Mills 0 siblings, 1 reply; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 20:39 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org > -----Original Message----- > From: Denys Dmytriyenko [mailto:denis@denix.org] > Sent: Friday, January 27, 2012 2:35 PM > To: Maupin, Chase > Cc: Mills, William; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > On Fri, Jan 27, 2012 at 08:29:42PM +0000, Maupin, Chase wrote: > > > > I don't think that was Bill's message. It was simplicity. BSP > > > only layer, no > > > > supplemental apps, if not absolutely required. > > > > > > > > Your example with lmbench is not correct - BSP layer should > be > > > simple enough > > > > to be used with OE-Core alone to produce a console rootfs > image > > > with nothing > > > > but busybox. > > > > > > > > How about splitting meta-ti into: > > > > * BSP only > > > > * SGX graphics > > > > * DSP tools > > > > * WiFi etc. > > > > > > > > And then splitting meta-arago into: > > > > * Arago distro for TI SDKs > > > > * Supplemental apps > > > > > > > > > > Need to get my "YES!" in here before everyone barfs all over > the > > > proposal :) > > > > I'm good with this. I was also planning in meta-arago to at > least put all > > bbappends in a recipes-appends directory so it was easy to track > the things > > we are "tweaking" vs. the recipes. Arago today is too much of a > mix between > > amends and recipes in my opinion. I would even say that Tom's > proposal > > (from IRC) of splitting the arago distro and supplemental apps > into two > > layers would be a good idea so that other distros can pull our > supplemental > > apps if they want pretty easily. And that way we don?t keep > adding more > > repos to manage. > > Actually that was my proposal (and Bill's offline), but never mind > :) > > As of today's state of Arago - if you don't count recipes/ti, which > was > "untouchable" for some special reasons, everything else is quite > clean with > using amends everywhere possible! And our of all the people you > should know > this better. There are plenty of recipes in arago outside of the ti directory that are not just amends. What I am saying is that I would like to split the bbappends into their own directory so that we can more easily track what we are appending and ideally find ways to drive those changes into lower common layers (not that we always can) > > -- > Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:39 ` Maupin, Chase @ 2012-01-27 20:42 ` William Mills 2012-01-27 20:44 ` Maupin, Chase 0 siblings, 1 reply; 45+ messages in thread From: William Mills @ 2012-01-27 20:42 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:39 PM, Maupin, Chase wrote: >> >> -----Original Message----- >> From: Denys Dmytriyenko [mailto:denis@denix.org] >> As of today's state of Arago - if you don't count recipes/ti, which >> was >> "untouchable" for some special reasons, everything else is quite >> clean with >> using amends everywhere possible! And our of all the people you >> should know >> this better. > There are plenty of recipes in arago outside of the ti directory that are not just amends. What I am saying is that I would like to split the bbappends into their own directory so that we can more easily track what we are appending and ideally find ways to drive those changes into lower common layers (not that we always can) > So it can be even clearer and cleaner than it is today. Great. Sounds like a good task for a meta-arago owner. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:42 ` William Mills @ 2012-01-27 20:44 ` Maupin, Chase 2012-01-27 20:48 ` William Mills 0 siblings, 1 reply; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 20:44 UTC (permalink / raw) To: Mills, William; +Cc: meta-ti@yoctoproject.org That is what I was planning to do with the bbappends for qt. Sincerely, Chase Maupin Software Applications ARM MPU e-mail: chase.maupin@ti.com phone: (214) 567-2950 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -----Original Message----- > From: Mills, William > Sent: Friday, January 27, 2012 2:43 PM > To: Maupin, Chase > Cc: Denys Dmytriyenko; meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > > On 01/27/2012 03:39 PM, Maupin, Chase wrote: > >> > >> -----Original Message----- > >> From: Denys Dmytriyenko [mailto:denis@denix.org] > >> As of today's state of Arago - if you don't count recipes/ti, > which > >> was > >> "untouchable" for some special reasons, everything else is quite > >> clean with > >> using amends everywhere possible! And our of all the people you > >> should know > >> this better. > > There are plenty of recipes in arago outside of the ti directory > that are not just amends. What I am saying is that I would like to > split the bbappends into their own directory so that we can more > easily track what we are appending and ideally find ways to drive > those changes into lower common layers (not that we always can) > > > > So it can be even clearer and cleaner than it is today. Great. > Sounds > like a good task for a meta-arago owner. > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:44 ` Maupin, Chase @ 2012-01-27 20:48 ` William Mills 0 siblings, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:48 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org So ... When I hijack a thread I do it pretty well. Any comments of PATCH 2/3 ?? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:29 ` Maupin, Chase 2012-01-27 20:34 ` Denys Dmytriyenko @ 2012-01-27 20:34 ` William Mills 1 sibling, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 20:34 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:29 PM, Maupin, Chase wrote: >> On 01/27/2012 03:21 PM, Denys Dmytriyenko wrote: >> How about splitting meta-ti into: >>> * BSP only >>> * SGX graphics >>> * DSP tools >>> * WiFi etc. >>> >>> And then splitting meta-arago into: >>> * Arago distro for TI SDKs >>> * Supplemental apps >>> >> Need to get my "YES!" in here before everyone barfs all over the >> proposal :) > I'm good with this. I was also planning in meta-arago to at least put all bbappends in a recipes-appends directory so it was easy to track the things we are "tweaking" vs. the recipes. Arago today is too much of a mix between amends and recipes in my opinion. I would even say that Tom's proposal (from IRC) of splitting the arago distro and supplemental apps into two layers would be a good idea so that other distros can pull our supplemental apps if they want pretty easily. And that way we don’t keep adding more repos to manage. Yes, this is what I was talking about all along. Sorry if I was not clear. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:24 ` William Mills 2012-01-27 20:29 ` Maupin, Chase @ 2012-01-27 20:50 ` Philip Balister 2012-01-27 20:54 ` Koen Kooi 2012-01-27 20:57 ` Denys Dmytriyenko 1 sibling, 2 replies; 45+ messages in thread From: Philip Balister @ 2012-01-27 20:50 UTC (permalink / raw) To: William Mills; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:24 PM, William Mills wrote: > ..... >>> can >>> agree to spliting meta-ti into two layers, a HW layer for our devices >>> and a >>> layer containing all of the TI recipes. >>> >>> But if we wanted to match the meta-intel layer way would you also >>> propose >>> making a layer per device? I personally find that more confusing. >> I don't think that was Bill's message. It was simplicity. BSP only >> layer, no >> supplemental apps, if not absolutely required. >> >> Your example with lmbench is not correct - BSP layer should be simple >> enough >> to be used with OE-Core alone to produce a console rootfs image with >> nothing >> but busybox. >> >> How about splitting meta-ti into: >> * BSP only >> * SGX graphics >> * DSP tools >> * WiFi etc. >> >> And then splitting meta-arago into: >> * Arago distro for TI SDKs >> * Supplemental apps >> > > Need to get my "YES!" in here before everyone barfs all over the > proposal :) > > Chase: your right. I do not want to follow intel's example of layer per > BSP. I build stuff for the USRP E100 (based on a gumstic overo). I use my own later for BSP that provides kernel, u-boot, and image recipes. I still need a TI BSP layer for DSP stuff (we do not care about SGX, although it is possible customers could). Do forget your customers using all this to ship products. Philip ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:50 ` Philip Balister @ 2012-01-27 20:54 ` Koen Kooi 2012-01-27 20:57 ` Denys Dmytriyenko 1 sibling, 0 replies; 45+ messages in thread From: Koen Kooi @ 2012-01-27 20:54 UTC (permalink / raw) To: meta-ti Op 27 jan. 2012, om 21:50 heeft Philip Balister het volgende geschreven: > On 01/27/2012 03:24 PM, William Mills wrote: >> > ..... > > >>>> can >>>> agree to spliting meta-ti into two layers, a HW layer for our devices >>>> and a >>>> layer containing all of the TI recipes. >>>> >>>> But if we wanted to match the meta-intel layer way would you also >>>> propose >>>> making a layer per device? I personally find that more confusing. >>> I don't think that was Bill's message. It was simplicity. BSP only >>> layer, no >>> supplemental apps, if not absolutely required. >>> >>> Your example with lmbench is not correct - BSP layer should be simple >>> enough >>> to be used with OE-Core alone to produce a console rootfs image with >>> nothing >>> but busybox. >>> >>> How about splitting meta-ti into: >>> * BSP only >>> * SGX graphics >>> * DSP tools >>> * WiFi etc. >>> >>> And then splitting meta-arago into: >>> * Arago distro for TI SDKs >>> * Supplemental apps >>> >> >> Need to get my "YES!" in here before everyone barfs all over the >> proposal :) >> >> Chase: your right. I do not want to follow intel's example of layer per >> BSP. > > I build stuff for the USRP E100 (based on a gumstic overo). I use my own > later for BSP that provides kernel, u-boot, and image recipes. > > I still need a TI BSP layer for DSP stuff (we do not care about SGX, > although it is possible customers could). > > Do forget your customers using all this to ship products. OK, I will forget it promptly :) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:50 ` Philip Balister 2012-01-27 20:54 ` Koen Kooi @ 2012-01-27 20:57 ` Denys Dmytriyenko 2012-01-27 22:40 ` Philip Balister 1 sibling, 1 reply; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 20:57 UTC (permalink / raw) To: Philip Balister; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 03:50:41PM -0500, Philip Balister wrote: > On 01/27/2012 03:24 PM, William Mills wrote: > > > ..... > > > >>> can > >>> agree to spliting meta-ti into two layers, a HW layer for our devices > >>> and a > >>> layer containing all of the TI recipes. > >>> > >>> But if we wanted to match the meta-intel layer way would you also > >>> propose > >>> making a layer per device? I personally find that more confusing. > >> I don't think that was Bill's message. It was simplicity. BSP only > >> layer, no > >> supplemental apps, if not absolutely required. > >> > >> Your example with lmbench is not correct - BSP layer should be simple > >> enough > >> to be used with OE-Core alone to produce a console rootfs image with > >> nothing > >> but busybox. > >> > >> How about splitting meta-ti into: > >> * BSP only > >> * SGX graphics > >> * DSP tools > >> * WiFi etc. > >> > >> And then splitting meta-arago into: > >> * Arago distro for TI SDKs > >> * Supplemental apps > >> > > > > Need to get my "YES!" in here before everyone barfs all over the > > proposal :) > > > > Chase: your right. I do not want to follow intel's example of layer per > > BSP. > > I build stuff for the USRP E100 (based on a gumstic overo). I use my own > later for BSP that provides kernel, u-boot, and image recipes. > > I still need a TI BSP layer for DSP stuff (we do not care about SGX, > although it is possible customers could). > > Do forget your customers using all this to ship products. > Philip, I don't understand what you are arguing here about or against? :) It won't change much for you, maybe just setup step a little. The proposal above is to split meta-ti and meta-arago repositories into multiple layers inside those repositories, like meta-oe already does. Your example above is a good one - having BSP, DSP and SGX in 3 separate layers allows you to enable first two w/o the need to get the second one parsed or used. -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:57 ` Denys Dmytriyenko @ 2012-01-27 22:40 ` Philip Balister 2012-01-27 23:39 ` Denys Dmytriyenko 0 siblings, 1 reply; 45+ messages in thread From: Philip Balister @ 2012-01-27 22:40 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:57 PM, Denys Dmytriyenko wrote: > On Fri, Jan 27, 2012 at 03:50:41PM -0500, Philip Balister wrote: >> On 01/27/2012 03:24 PM, William Mills wrote: .... >>> Chase: your right. I do not want to follow intel's example of layer per >>> BSP. >> >> I build stuff for the USRP E100 (based on a gumstic overo). I use my own >> later for BSP that provides kernel, u-boot, and image recipes. >> >> I still need a TI BSP layer for DSP stuff (we do not care about SGX, >> although it is possible customers could). >> >> Do forget your customers using all this to ship products. >> > Philip, > > I don't understand what you are arguing here about or against? :) > > It won't change much for you, maybe just setup step a little. > > The proposal above is to split meta-ti and meta-arago repositories into > multiple layers inside those repositories, like meta-oe already does. > > Your example above is a good one - having BSP, DSP and SGX in 3 separate > layers allows you to enable first two w/o the need to get the second one > parsed or used. > Mostly I am saying keep your customers in mind, I very much like the story of oe-core as the foundation, adding meta-oe to build images that can be tested in qemu, using the TI BSP to support SOC specific features and as an example to create my own BSP with my image definitions. Finally I can use the Angstrom layer to provide some sanity to package versions and as a source for binary feeds. I'm not sure where Arago fits in this story. It would be really nice to get all this sorted out so we can clearly explain this to other users of TI products and OE users. Philip ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 22:40 ` Philip Balister @ 2012-01-27 23:39 ` Denys Dmytriyenko 0 siblings, 0 replies; 45+ messages in thread From: Denys Dmytriyenko @ 2012-01-27 23:39 UTC (permalink / raw) To: Philip Balister; +Cc: meta-ti@yoctoproject.org On Fri, Jan 27, 2012 at 05:40:39PM -0500, Philip Balister wrote: > On 01/27/2012 03:57 PM, Denys Dmytriyenko wrote: > > On Fri, Jan 27, 2012 at 03:50:41PM -0500, Philip Balister wrote: > >> On 01/27/2012 03:24 PM, William Mills wrote: > .... > > > >>> Chase: your right. I do not want to follow intel's example of layer per > >>> BSP. > >> > >> I build stuff for the USRP E100 (based on a gumstic overo). I use my own > >> later for BSP that provides kernel, u-boot, and image recipes. > >> > >> I still need a TI BSP layer for DSP stuff (we do not care about SGX, > >> although it is possible customers could). > >> > >> Do forget your customers using all this to ship products. > >> > > Philip, > > > > I don't understand what you are arguing here about or against? :) > > > > It won't change much for you, maybe just setup step a little. > > > > The proposal above is to split meta-ti and meta-arago repositories into > > multiple layers inside those repositories, like meta-oe already does. > > > > Your example above is a good one - having BSP, DSP and SGX in 3 separate > > layers allows you to enable first two w/o the need to get the second one > > parsed or used. > > > > Mostly I am saying keep your customers in mind, I very much like the > story of oe-core as the foundation, adding meta-oe to build images that > can be tested in qemu, using the TI BSP to support SOC specific features > and as an example to create my own BSP with my image definitions. > Finally I can use the Angstrom layer to provide some sanity to package > versions and as a source for binary feeds. I'm not sure where Arago fits > in this story. If you are worried about how Arago distribution fits in your use case, you shouldn't - we are definitely not trying to force our distribution on you, if you are happy with Angstrom. Moreover, that's the reason we propose to split meta-arago repository to separate apps from distro/TISDK configs, in case you want to use those apps with your own distro. > It would be really nice to get all this sorted out so we can clearly > explain this to other users of TI products and OE users. Hence the heated discussion of today :) -- Denys ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:21 ` Denys Dmytriyenko 2012-01-27 20:24 ` William Mills @ 2012-01-27 20:53 ` Koen Kooi 2012-01-27 20:55 ` Maupin, Chase 1 sibling, 1 reply; 45+ messages in thread From: Koen Kooi @ 2012-01-27 20:53 UTC (permalink / raw) To: meta-ti Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende geschreven: > On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: >>> -----Original Message----- >>> From: Mills, William >>> Sent: Friday, January 27, 2012 2:11 PM >>> To: Maupin, Chase >>> Cc: Koen Kooi; meta-ti@yoctoproject.org >>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from >>> arago overlay >>> >>> >>> On 01/27/2012 02:46 PM, Maupin, Chase wrote: >>>> I guess we have a difference of opinion on how we see meta-arago. >>> I >>>> don?t separate that layer into distro and non-distro. I was >>> really >>>> planning on meta-arago being all the stuff related to the >>> arago/SDK >>>> distribution. Meta-ti is for TI packages that can be used by >>> other >>>> distros. That being said I'm OK with meta-ti being split into a >>> BSP >>>> layer and everthing else, but I don't know exactly what that buys >>> us. >>>> Does it particularly hurt someone that pulls in meta-ti to have >>> access >>>> to matrix if they don't use it? I pull in things from meta-oe or >>>> oe-core that I don?t "need" but they are there anyway. >>> >>> Do you know that everything you are putting in meta-ti today only >>> depends on oe-core? I don't think you do as we are not testing >>> that >>> today. Yes, in the old days a recipie collection had tons of stuff >>> that >>> would be present but just fail if you actually tried to use it. >>> The >>> point of layers was to clean that up. >> >> Not sure what your comment about only needing oe-core is. For example I use >> lmbench but I don?t see that in oe-core. I get that from meta-oe. I can >> agree to spliting meta-ti into two layers, a HW layer for our devices and a >> layer containing all of the TI recipes. >> >> But if we wanted to match the meta-intel layer way would you also propose >> making a layer per device? I personally find that more confusing. > > I don't think that was Bill's message. It was simplicity. BSP only layer, no > supplemental apps, if not absolutely required. > > Your example with lmbench is not correct - BSP layer should be simple enough > to be used with OE-Core alone to produce a console rootfs image with nothing > but busybox. > > How about splitting meta-ti into: > * BSP only > * SGX graphics > * DSP tools Since sgx and dsp are built into the SoC, why isn't it considered BSP? I must really start warming about getting overzealous with layers and breeding a silo mentality. I'm not saying we only need one layer, but not a gazillion like the base proposal. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:53 ` Koen Kooi @ 2012-01-27 20:55 ` Maupin, Chase 2012-01-27 21:52 ` William Mills 0 siblings, 1 reply; 45+ messages in thread From: Maupin, Chase @ 2012-01-27 20:55 UTC (permalink / raw) To: Koen Kooi, meta-ti@yoctoproject.org > -----Original Message----- > From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti- > bounces@yoctoproject.org] On Behalf Of Koen Kooi > Sent: Friday, January 27, 2012 2:54 PM > To: meta-ti@yoctoproject.org > Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from > arago overlay > > > Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende > geschreven: > > > On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: > >>> -----Original Message----- > >>> From: Mills, William > >>> Sent: Friday, January 27, 2012 2:11 PM > >>> To: Maupin, Chase > >>> Cc: Koen Kooi; meta-ti@yoctoproject.org > >>> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port > from > >>> arago overlay > >>> > >>> > >>> On 01/27/2012 02:46 PM, Maupin, Chase wrote: > >>>> I guess we have a difference of opinion on how we see meta- > arago. > >>> I > >>>> don?t separate that layer into distro and non-distro. I was > >>> really > >>>> planning on meta-arago being all the stuff related to the > >>> arago/SDK > >>>> distribution. Meta-ti is for TI packages that can be used by > >>> other > >>>> distros. That being said I'm OK with meta-ti being split into > a > >>> BSP > >>>> layer and everthing else, but I don't know exactly what that > buys > >>> us. > >>>> Does it particularly hurt someone that pulls in meta-ti to > have > >>> access > >>>> to matrix if they don't use it? I pull in things from meta-oe > or > >>>> oe-core that I don?t "need" but they are there anyway. > >>> > >>> Do you know that everything you are putting in meta-ti today > only > >>> depends on oe-core? I don't think you do as we are not testing > >>> that > >>> today. Yes, in the old days a recipie collection had tons of > stuff > >>> that > >>> would be present but just fail if you actually tried to use it. > >>> The > >>> point of layers was to clean that up. > >> > >> Not sure what your comment about only needing oe-core is. For > example I use > >> lmbench but I don?t see that in oe-core. I get that from meta- > oe. I can > >> agree to spliting meta-ti into two layers, a HW layer for our > devices and a > >> layer containing all of the TI recipes. > >> > >> But if we wanted to match the meta-intel layer way would you > also propose > >> making a layer per device? I personally find that more > confusing. > > > > I don't think that was Bill's message. It was simplicity. BSP > only layer, no > > supplemental apps, if not absolutely required. > > > > Your example with lmbench is not correct - BSP layer should be > simple enough > > to be used with OE-Core alone to produce a console rootfs image > with nothing > > but busybox. > > > > How about splitting meta-ti into: > > * BSP only > > * SGX graphics > > * DSP tools > > Since sgx and dsp are built into the SoC, why isn't it considered > BSP? I must really start warming about getting overzealous with > layers and breeding a silo mentality. I'm not saying we only need > one layer, but not a gazillion like the base proposal. I did not read the above as making a bunch of layers in meta-ti. At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices. > > _______________________________________________ > meta-ti mailing list > meta-ti@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-ti ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 20:55 ` Maupin, Chase @ 2012-01-27 21:52 ` William Mills 2012-01-27 23:04 ` Koen Kooi 0 siblings, 1 reply; 45+ messages in thread From: William Mills @ 2012-01-27 21:52 UTC (permalink / raw) To: Maupin, Chase; +Cc: meta-ti@yoctoproject.org On 01/27/2012 03:55 PM, Maupin, Chase wrote: >> Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende >> geschreven: >>> On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: >>> How about splitting meta-ti into: >>> * BSP only >>> * SGX graphics >>> * DSP tools >> Since sgx and dsp are built into the SoC, why isn't it considered >> BSP? I must really start warming about getting overzealous with >> layers and breeding a silo mentality. I'm not saying we only need >> one layer, but not a gazillion like the base proposal. > I did not read the above as making a bunch of layers in meta-ti. At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices. > Well that was the proposal and why I figured you would barf all over it. I am OK with all the above in one layer (but separate dirs) if it all works with all the layer stack combinations we are targeting. The issue is we have no meta-ti+oe-core builds going on so we don't know where the dependencies will be hard to break. We all know the DSP support can get involved. If we got to the point where BSP and graphics worked with oe-core but DSP support needed meta-oe or something else, then I would want the DSP stuff in a separate layer so people that did not need it could opt out. Likewise people using TI WIFI on non-TI processors should be able to get that in any layer stack. If that all works with all the above in one layer thats fine. We just don't know yet. We can be optimistic and put it all in one layer or pessamistic and seperate them. In this example I am more inclined to believe that the other TI stuff would not cause problems. Koen: having a number of layers in on repo is a bad thing? You should tell the meta-oe maintainer because that guys has a good number of layers in there. :) Are you saying that was the wrong thing to do for meta-oe? Is there a leason learned? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 21:52 ` William Mills @ 2012-01-27 23:04 ` Koen Kooi 2012-01-28 3:23 ` Philip Balister 0 siblings, 1 reply; 45+ messages in thread From: Koen Kooi @ 2012-01-27 23:04 UTC (permalink / raw) To: meta-ti Op 27 jan. 2012, om 22:52 heeft William Mills het volgende geschreven: > > > On 01/27/2012 03:55 PM, Maupin, Chase wrote: >>> Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende >>> geschreven: >>>> On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: >>>> How about splitting meta-ti into: >>>> * BSP only >>>> * SGX graphics >>>> * DSP tools >>> Since sgx and dsp are built into the SoC, why isn't it considered >>> BSP? I must really start warming about getting overzealous with >>> layers and breeding a silo mentality. I'm not saying we only need >>> one layer, but not a gazillion like the base proposal. >> I did not read the above as making a bunch of layers in meta-ti. At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices. >> > > Well that was the proposal and why I figured you would barf all over it. I am OK with all the above in one layer (but separate dirs) if it all works with all the layer stack combinations we are targeting. The issue is we have no meta-ti+oe-core builds going on so we don't know where the dependencies will be hard to break. > > We all know the DSP support can get involved. If we got to the point where BSP and graphics worked with oe-core but DSP support needed meta-oe or something else, then I would want the DSP stuff in a separate layer so people that did not need it could opt out. > > Likewise people using TI WIFI on non-TI processors should be able to get that in any layer stack. If that all works with all the above in one layer thats fine. We just don't know yet. We can be optimistic and put it all in one layer or pessamistic and seperate them. In this example I am more inclined to believe that the other TI stuff would not cause problems. > > Koen: having a number of layers in on repo is a bad thing? You should tell the meta-oe maintainer because that guys has a good number of layers in there. :) Are you saying that was the wrong thing to do for meta-oe? Is there a leason learned? It's getting late here, so I'll give the short version: every additional layer is a pain to maintain and it's even worse for the type of users we target. You need a really good set of layer tools, which still don't exist :( And I just know that someone is going to ask the "why do I need 5 TI layers for my simple board?" question and I don't think we can give a satisfactory answer for users based on this discussion. So what about this plan: 1) evaluate directory structure of the current meta-ti, fix if needed 2) break the easy dependencies on external layers by duplicating the image recipes. 3) document the remaining dependencies in the README That should get us a layer that parses when being using with only bitbake+oe-core. Kernel and u-boot will build & work with the right toolchain 4) rename our u-boot recipes per the earlier RFC That should avoid clashes with other layers The remaining tasks are a bit more involved: 5) make our kernel+bootloaders compile and work with gcc 4.6/binutils 2.22 6) Make SOC_FAMILY work or find an equivalent regards, Koen ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 23:04 ` Koen Kooi @ 2012-01-28 3:23 ` Philip Balister 0 siblings, 0 replies; 45+ messages in thread From: Philip Balister @ 2012-01-28 3:23 UTC (permalink / raw) To: Koen Kooi; +Cc: meta-ti On 01/27/2012 06:04 PM, Koen Kooi wrote: > > Op 27 jan. 2012, om 22:52 heeft William Mills het volgende geschreven: > >> >> >> On 01/27/2012 03:55 PM, Maupin, Chase wrote: >>>> Op 27 jan. 2012, om 21:21 heeft Denys Dmytriyenko het volgende >>>> geschreven: >>>>> On Fri, Jan 27, 2012 at 08:17:42PM +0000, Maupin, Chase wrote: >>>>> How about splitting meta-ti into: >>>>> * BSP only >>>>> * SGX graphics >>>>> * DSP tools >>>> Since sgx and dsp are built into the SoC, why isn't it considered >>>> BSP? I must really start warming about getting overzealous with >>>> layers and breeding a silo mentality. I'm not saying we only need >>>> one layer, but not a gazillion like the base proposal. >>> I did not read the above as making a bunch of layers in meta-ti. At the risk of getting this all started again, I really hope meta-ti is one layer with BSP, SGX, DSP, WiFi support for our devices. >>> >> >> Well that was the proposal and why I figured you would barf all over it. I am OK with all the above in one layer (but separate dirs) if it all works with all the layer stack combinations we are targeting. The issue is we have no meta-ti+oe-core builds going on so we don't know where the dependencies will be hard to break. >> >> We all know the DSP support can get involved. If we got to the point where BSP and graphics worked with oe-core but DSP support needed meta-oe or something else, then I would want the DSP stuff in a separate layer so people that did not need it could opt out. >> >> Likewise people using TI WIFI on non-TI processors should be able to get that in any layer stack. If that all works with all the above in one layer thats fine. We just don't know yet. We can be optimistic and put it all in one layer or pessamistic and seperate them. In this example I am more inclined to believe that the other TI stuff would not cause problems. >> >> Koen: having a number of layers in on repo is a bad thing? You should tell the meta-oe maintainer because that guys has a good number of layers in there. :) Are you saying that was the wrong thing to do for meta-oe? Is there a leason learned? > > It's getting late here, so I'll give the short version: every additional layer is a pain to maintain and it's even worse for the type of users we target. You need a really good set of layer tools, which still don't exist :( > And I just know that someone is going to ask the "why do I need 5 TI layers for my simple board?" question and I don't think we can give a satisfactory answer for users based on this discussion. Koen is trying to touch in the matter that I am at the high end of customers skill levels wrt to the OE ecosystem :) So I can sort through the layers I need (and curse a lot), but people who have not been around as long just give up. The Intel guys have easy to follow bsp's because their chips are not that interesting :) TI brings to the table the asymmetric multiprocessing (or whatever the proper buzzzword is) which adds a fair bit of complexity to the BSP. Philip > > So what about this plan: > > 1) evaluate directory structure of the current meta-ti, fix if needed > 2) break the easy dependencies on external layers by duplicating the image recipes. > 3) document the remaining dependencies in the README > > That should get us a layer that parses when being using with only bitbake+oe-core. Kernel and u-boot will build & work with the right toolchain > > 4) rename our u-boot recipes per the earlier RFC > > That should avoid clashes with other layers > > The remaining tasks are a bit more involved: > > 5) make our kernel+bootloaders compile and work with gcc 4.6/binutils 2.22 > 6) Make SOC_FAMILY work or find an equivalent > > regards, > > Koen > _______________________________________________ > meta-ti mailing list > meta-ti@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-ti > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/3] matrix-gui-browser: port from arago overlay 2012-01-27 11:50 ` Koen Kooi 2012-01-27 12:09 ` Andreas Müller 2012-01-27 13:50 ` Maupin, Chase @ 2012-01-27 17:30 ` William Mills 2 siblings, 0 replies; 45+ messages in thread From: William Mills @ 2012-01-27 17:30 UTC (permalink / raw) To: Koen Kooi; +Cc: meta-ti On 01/27/2012 06:50 AM, Koen Kooi wrote: > > Op 26 jan. 2012, om 23:44 heeft William Mills het volgende geschreven: > >> On 01/26/2012 01:46 PM, Chase Maupin wrote: >>> * This package adds a simple web browser GUI application with >>> no decorations used to display matrix on the local display. >>> * Ported from arago overlay >>> >> >> Sorry for hijacking your patch Chase but I have serious big picture questions about all this stuff going into meta-ti and especially all into one layer. >> >> meta-ti is suppose to be the TI specific stuff people need to support their platforms regardless of what layer stack they are using. I understand we are not layer stack independent yet but that needs to be the goal. Certainly adding a whole bunch of non-HW related stuff into the same layer is not going to move us any closer. >> >> When we talked about where matrix belonged before there was debate about meta-oe or meta-arago. When did I miss the memo that put it into meta-ti?? > > Since meta-arago is supposed to be as empty as possible and matrix doesn't play well with others it's a bad fit for both meta-arago and meta-oe. Maybe we should split the meta-ti repo into 2 layers: one for BSP things (including sgx, dsp, etc) and one for 'sdk' things (matrix). > The idea is to keep reusable TI deliverables together without forcing people to use arago. Putting matrix in meta-arago would mean you can only use it with DISTRO=arago, which is a huge step backwards from the current situation. matrix does not play well with others so we should put it in the layer that is suppose to work in as many layer stacks as possible?? Yes, this can be fixed by making a different layer (as I alluded to) in meta-ti but the same can be said for meta-arago or (harder sell) for meta-oe (a "staging" layer?). I agree the Arago _distro_ _layer_ needs to be as thin as possible but that does not need to apply to the meta-arago.git. There is nothing "TI" about matrix other than we wrote it and are the ones that use it most often. The same logic could apply to meta-arago. Matrix originated in Arago related activities and is more closly related to the Arago concept than the TI concept. If lots of people pick up and want to use Matrix it would would need to move out of either place (meta-ti or meta-arago) to somewhere more neutral. However it would also need to more sophisticated in how it "plays with others". meta-ti should not be a dumping ground for all things that happened to have originated at TI. meta-ti needs to be clean. meta-arago can be a little messy if need be. Regardless of who's opinion prevails it seems we agree that another layer is needed. Agreed? ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2012-01-28 3:23 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-26 18:46 [PATCH 1/3] matrix-gui-browser: port from arago overlay Chase Maupin 2012-01-26 18:46 ` [PATCH 2/3] refresh-screen: add package from arago Chase Maupin 2012-01-26 18:46 ` [PATCH 3/3] matrix-gui: update to latest version Chase Maupin 2012-01-26 22:44 ` [PATCH 1/3] matrix-gui-browser: port from arago overlay William Mills 2012-01-27 11:50 ` Koen Kooi 2012-01-27 12:09 ` Andreas Müller 2012-01-27 12:24 ` Koen Kooi 2012-01-27 17:38 ` William Mills 2012-01-27 19:39 ` Denys Dmytriyenko 2012-01-27 19:47 ` Koen Kooi 2012-01-27 20:09 ` Denys Dmytriyenko 2012-01-27 13:50 ` Maupin, Chase 2012-01-27 14:54 ` Philip Balister 2012-01-27 15:19 ` Maupin, Chase 2012-01-27 17:51 ` William Mills 2012-01-27 19:46 ` Maupin, Chase 2012-01-27 20:03 ` William Mills 2012-01-27 20:05 ` William Mills 2012-01-27 20:10 ` Tom Rini 2012-01-27 20:11 ` Denys Dmytriyenko 2012-01-27 20:19 ` Philip Balister 2012-01-27 20:24 ` Denys Dmytriyenko 2012-01-27 20:20 ` William Mills 2012-01-27 20:11 ` William Mills 2012-01-27 20:17 ` Maupin, Chase 2012-01-27 20:21 ` Denys Dmytriyenko 2012-01-27 20:24 ` William Mills 2012-01-27 20:29 ` Maupin, Chase 2012-01-27 20:34 ` Denys Dmytriyenko 2012-01-27 20:39 ` Maupin, Chase 2012-01-27 20:42 ` William Mills 2012-01-27 20:44 ` Maupin, Chase 2012-01-27 20:48 ` William Mills 2012-01-27 20:34 ` William Mills 2012-01-27 20:50 ` Philip Balister 2012-01-27 20:54 ` Koen Kooi 2012-01-27 20:57 ` Denys Dmytriyenko 2012-01-27 22:40 ` Philip Balister 2012-01-27 23:39 ` Denys Dmytriyenko 2012-01-27 20:53 ` Koen Kooi 2012-01-27 20:55 ` Maupin, Chase 2012-01-27 21:52 ` William Mills 2012-01-27 23:04 ` Koen Kooi 2012-01-28 3:23 ` Philip Balister 2012-01-27 17:30 ` William Mills
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.