Created attachment 577718 [details] modified ebuild with comments (even in inappropriate sections) As upstream has included the proposed changes in #633764, we should make use of them. Far as I can see from cmake/scripts/common/ArchSetup.cmake if(WITH_CPU) set(CPU ${WITH_CPU}) elseif(NOT KODI_DEPENDSBUILD) set(CPU ${CMAKE_SYSTEM_PROCESSOR}) endif() we need to specify the CPU type by passing -DCPU=foo; as KODI_DEPENDSBUILD is always true in the gentoo build process. Changes include a selection of the raspberry pi platform instead of X,gbm,wayland only. Dependencies not required for the raspberry are made conditional and required useflags for the raspberry are conditionally added to packages. Sorry for the useflag mess, raspberry-pi, raspberry-pi1, raspberry-pi2 and raspberry-pi3 seem a little bloated to me - but I needed to identify in general "is it a raspberry" and "what revision is it" - and couldn't find any example of "if use is either a or b or c" then set "foo".. I've attached the ebuild with comments to my changes. Hope that we can add some of the effort to the ebuild, to get the most out of our little gentoo media-centers.
Thank you for your contribution. I had a short look on the ebuild. Here a few ideas: * Please test the ebuild with repoman full -d -x https://wiki.gentoo.org/wiki/Repoman * We always try to use the latest EAPI, please bump to EAPI=7 * eutils is not required here Anyway, I do not understand your ticket. Do you suggest a new ebuild, or a modification of the existing?
Created attachment 577794 [details] Updated ebuild for raspberries Updated for raspberry-pi1, previous ebuild had a typo - or maybe I had one beer too much.
Created attachment 577796 [details] Updated ebuild for raspberries ...fixed yet another typo.
Sorry for the late reply! The suggestion is to modify the original ebuild. I left it as much in original state as I could, thus the EAPI and eutils. Bumping the EAPI does not require anything else than bumping here? My idea is making the official ebuild suitable tabke for raspberries, i can confirm that it works well on my pi3b. Is there anything else to do for me besides the aforementioned changes?
A new ebuild added. Kodi 18.3 Leaving as much original as I could, the EAPI is now on 7; repoman full -d -x It has been tested to work well on a raspberry Pi 3B using MMAL acceleration of the Videocore VC4. Changes in Detail, compared to the official kodi-18.3 ebuild: Added IUSE raspberry-pi raspberry-pi1 raspberry-pi2 raspberry-pi3 "raspberry-pi" is required to have one flag to identify raspberries. If anyone can show me a syntax that works for "one-of" conditions, I would drop the superfluous "raspberry-pi" flag. (I had hoped for something like "||(raspi1 raspi2 raspi3)?" Added "raspberry-pi" to the possible rendering targets, besides "gbm, wayland, X" On a raspberry pi, up to kodi-18.3 runs perfectly without X or anything else. Added condition for libcec When compiling for a raspberry pi and enabling CEC, make sure that libcec is using the "raspberry-pi" flag. Added condition for GLES If using GLES on a raspberry, mesa is not required. We can use the Videocore GLES libraries without mesa, so no bloat is required here. Added condition for EGL If using EGL on a raspberry, mesa is not required. We can use the Videocore EGL libraries without mesa, so no bloat is required here. Added condition for raspberry-pi If running on a raspberry pi, make sure that one-of "media-libs/raspberrypi-userland" or "media-libs/raspberrypi-userland-bin" is available, providing the libraries mesa would provide in other cases. Removed "-DENABLE_VAAPI=$(usex vaapi)" As kodi 18.3 does automatically detect VAAPI being available or not. If this is set, cmake will hint you that a manually set and unused variable, "-DENABLE_VAAPI" was ignored. Removed "-Dlibdvdcss_URL="${DISTDIR}/libdvdcss-${LIBDVDCSS_VERSION}.tar.gz" As exactly the same happens with cmake, telling that this variable is unused. Added configure arguments -DCORE_PLATFORM_NAME / -DPLATFORM / -DWITH_CPU Here we set the proper platform name (kodi optimizations/ARM target) and CPU model. Sure there will follow a patch for Cortex-A72 soon. This here ensures that kodi is compiled using the correct CPU and arch. You can try to have the ebuild without this section; and on 'configure' you'll end up witout any platform/arch selected, thus no optimizations take place. Far as I can see, this is due to KODI_DEPENDS_BASED_BUILD being set, which disables the automagic detection of hardware stuff for us gentoo people.
Created attachment 581808 [details] modified ebuild suitable for raspberry pi 1,2,3 This has been tested by using it in an overlay on my raspberry pi3, it compiles and runs nicely as it is supposed to.
Created attachment 581810 [details, diff] Simple patch to update kodi-18.3.ebuild to match the raspberry ebuild. Unified diff of my changes, my comment regarding the changes is in the same order as the patch.
Created attachment 581812 [details] modified ebuild suitable for raspberry pi 1,2,3 Updated modified ebuild to be less invasive. Now allows to run on the FKMS with Mesas VC4 driver.
Created attachment 581814 [details, diff] Simple patch to update kodi-18.3.ebuild to match the raspberry ebuild. Updated patch,just like ebuild to not force people into Broadcoms proprietary VC4 driver, but allow mesa FKMS as well.
A few questions... * Why did you drop -DENABLE_VAAPI=$(usex vaapi) ? * Why did you drop -Dlibdvdcss_URL="${DISTDIR}/libdvdcss-${LIBDVDCSS_VERSION}.tar.gz" ? * Do we really need -DWITH_CPU? I'd very much like to not have the raspberry-pi1 raspberry-pi2 raspberry-pi3 USE flags Thanks!
(In reply to Craig Andrews from comment #10) > A few questions... > * Why did you drop -DENABLE_VAAPI=$(usex vaapi) ? > * Why did you drop > -Dlibdvdcss_URL="${DISTDIR}/libdvdcss-${LIBDVDCSS_VERSION}.tar.gz" ? > * Do we really need -DWITH_CPU? I'd very much like to not have the > raspberry-pi1 raspberry-pi2 raspberry-pi3 USE flags > > Thanks! Hi Craig, VAAPI was dropped, as it can't be force-enabled anymore. Kodi autodetects this. CMake throws an info that it threw away the manually set "-DENABLE_VAAPI". Same for -Dlibdvdcss_URL Well, we really do need -DWITH_CPU, as we are having three different ones out now; the forth is on the way and my Pi4 with a cortex-a72 should arrive in a day or two. I hope we need the specific CPU, unless we are willing to use gentoo and shower praise on its great and beneficial -march=x86-64 optimizations. Since KODI_DEPENDS_BASED_BUILD disables the detection, we have to tell it which CPU we are using.
Craig, I guess someone smarter than me could modify an ebuild to properly identify the raspberry pi version and report the CPU, so we could feed that instead of manually specifying it. But I wouldn't know how to do that inside an ebuild.
(In reply to Walter Hüttenmeyer from comment #11) > (In reply to Craig Andrews from comment #10) > > A few questions... > > * Why did you drop -DENABLE_VAAPI=$(usex vaapi) ? > > * Why did you drop > > -Dlibdvdcss_URL="${DISTDIR}/libdvdcss-${LIBDVDCSS_VERSION}.tar.gz" ? > > * Do we really need -DWITH_CPU? I'd very much like to not have the > > raspberry-pi1 raspberry-pi2 raspberry-pi3 USE flags > > > > Thanks! > > Hi Craig, > > VAAPI was dropped, as it can't be force-enabled anymore. > Kodi autodetects this. CMake throws an info that it threw away the manually > set "-DENABLE_VAAPI". Are you sure? It looks like it's still used: https://github.com/xbmc/xbmc/blob/18.3-Leia/cmake/modules/FindFFMPEG.cmake#L234 > > Same for -Dlibdvdcss_URL Are you sure? It looks like it's still used: https://github.com/xbmc/xbmc/blob/18.3-Leia/cmake/modules/FindLibDvd.cmake#L100 > > Well, we really do need -DWITH_CPU, as we are having three different ones > out now; the forth is on the way and my Pi4 with a cortex-a72 should arrive > in a day or two. > I hope we need the specific CPU, unless we are willing to use gentoo and > shower praise on its great and beneficial -march=x86-64 optimizations. > Since KODI_DEPENDS_BASED_BUILD disables the detection, we have to tell it > which CPU we are using. If you're building on a pi, you won't be using -march=x86-64. Looking at your PR at https://github.com/xbmc/xbmc/pull/16282 it seems this may be a misleading logging situation? I'd much rather carry patch in Gentoo that you've requested for merge upstream than adding 4 new use flags.
Hi Craig, I can see that in the source code it auto-checks for vaapi and throws off any attempt to use -DENABLE_VAAPI as well as the libdvdcss. Sorry, the "generic x86-64 optimizations to shower praise upon" were a little sarcastic to clarify my point of using the proper optimizations. Not ricing, just using the proper CPU as it's stated quite early in the gentoo install. "We're the good guys that let you unleash all the power of your CPU" is my transcription of that section of the manual. So I guess we should unleash the raspberries CPU as well. So using the official ebuild, I get at the end of configure #### CMake Warning: Manually-specified variables were not used by the project: ENABLE_VAAPI USE_LTO libdvdcss_URL #### Seems to me they aren't used after all now. Regarding the optimizations, my ebuild gives this here as output: #### -- Core system type: linux -- Platform: raspberry-pi -- CPU: cortex-a53, ARCH: arm C -O2 -pipe -fomit-frame-pointer -fPIC -mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mvectorize-with-neon-quad -D_ARMEL -DTARGET_RASPBERRY_PI -Wall #### (note the -mcpu and -mfpu) whilst without specifying -DCPU (but specifying -DCORE_SYSTEM_NAME and -DCORE_PLATFORM cause otherwise it's just plain old empty since autodetection doesn't work through the ebuild): #### -- Core system type: linux -- Platform: -- CPU: armv7l, ARCH: arm #### And I don't even get further, since I don't have mesa installed. But the clue here is that it would definitely read armv7 and use the generic optimizations.
And it's about time to make it even more extensive. Two things: Kodi revision changed to 18.3-r1; really just one minor change in the ebuild between 18.3 and 18.3-r1; so it was quite easy to update this ebuild as well. It's extended and now handles the raspberry Pi4. I got my 4GB model today and have already compiled kodi on it. Unfortunately kodi CPU detection thinks it's a Cortex-A7 (It's an A72). So now, until upstream merges PR#16344 (https://github.com/xbmc/xbmc/pull/16344) we will need the new patch added to be present in /etc/portage/patches/media-tv/kodi/ This allows us to compile kodi for the raspberry Pi4. Of course, no man is an island; so the patch does nothing without the modified ebuild. Attached is everything I needed to get Kodi going on the Raspi4.
Created attachment 581852 [details] modified ebuild suitable for raspberry pi 1,2,3,4 Added raspberry-pi4. I know, it's getting out of hand, but I have no other way to determine which raspi we are compiling for.
Created attachment 581854 [details, diff] Simple patch to update kodi-18.3-r1.ebuild to match the raspberry ebuild. For raspberry pi4, we need the other patch file (kodi-rpi4-cortex-a72.patch) to be present in /etc/portage/patches/media-tv/kodi/ Sure it would be nice to have this patch included in the gentoo official patchset for kodi, until upstream decides to add the functionality.
Created attachment 581856 [details, diff] patch needed to work reliable with cortex-a72 Specifying -DCPU=cortex-a72 in the ebuild is not enough, as ArchSetup.cmake will check for (CPU MATCHES "cortex-a7") and this triggers on the "cortex-a72" as well. The informative output will show "CPU: cortex-a72" after all, but the CFLAGS will give you a -mcpu="cortex-a7" To not mess things I don't understand, I left all the "Matches (contains)" checks, but added a "(CPU STREQUAL "cortex-a72") before the other checks inside ArchSetup.cmake If you now specify -DCPU=cortex-a72, it will be reflected in the CFLAGS to read mcpu="cortex-a72". This only triggers when the selected platform is a a raspberry pi (-DCORE_PLATFORM_NAME=rbpi) and the CPU was specified to be an A72 (-DCPU=cortex-a72). Other things are not affected. Putting this in /etc/portage/patches/media-tv/kodi/ enables the modified ebuild to build explicitly for the Raspberry Pi4 along with all the goodness it brings.
Kodi upstream says pi4 doesn't work: https://github.com/xbmc/xbmc/pull/16344#issuecomment-508154599 I can't add support for pi4 until Kodi does... so I suggest we watch Kodi and see when they provide this support. For example, see https://github.com/xbmc/xbmc/pull/16324 Also, for Kodi 19, it looks like all the pi-specific stuff is probably going away in favor of using gbm: https://github.com/xbmc/xbmc/pull/16321 I'm pretty sure we don't need the 3 model specific use flags (raspberry-pi1, raspberry-pi2, raspberry-pi3). Looking at https://github.com/xbmc/xbmc/blob/18.3-Leia/cmake/scripts/linux/ArchSetup.cmake#L42 if "-DWITH_CPU" isn't specified, no modifications to the CFLAGS will be made. Meaning the ones you configured in Gentoo (make.conf) will be used. So you can rice all you want using the Gentoo provided standard approach :) You can confirm by looking at the portage build log for Kodi and seeing what options were passed to GCC. Also, we don't need to set -DPLATFORM, see https://github.com/xbmc/xbmc/pull/16282#issuecomment-502995947 With that said, here are the changes I'm thinking of: https://github.com/gentoo/gentoo/pull/12384 What do you think?
Hi Craig, I think that your approach is the better way to go from here. During my phase of excessive happiness about having the pi4; I didn't stop to think that it could work this kinda "vanilla" way just as well. I'll check and confirm that this is working. The "raspberry-pi" flag is in use for other packages already (e.g. libcec); so this wouldn't even be something new. Your commit looks clean and logical; so I'll definitely be happy with it. ...just hope my micro-hdmi arrives soon, so I can actually test the GUI :D Thanks for this nice solution!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63cac960d501ac6cea62e1f52a2449a6bb8fac88 commit 63cac960d501ac6cea62e1f52a2449a6bb8fac88 Author: Craig Andrews <candrews@gentoo.org> AuthorDate: 2019-07-03 19:03:08 +0000 Commit: Craig Andrews <candrews@gentoo.org> CommitDate: 2019-07-04 13:32:58 +0000 media-tv/kodi: Add raspberry-pi USE flag Closes: https://bugs.gentoo.org/686686 Package-Manager: Portage-2.3.68, Repoman-2.3.16 Signed-off-by: Craig Andrews <candrews@gentoo.org> media-tv/kodi/kodi-18.3-r1.ebuild | 19 ++++++++++++++----- media-tv/kodi/kodi-9999.ebuild | 19 ++++++++++++++----- media-tv/kodi/metadata.xml | 1 + profiles/arch/arm/package.use.mask | 4 ++++ profiles/arch/base/package.use.mask | 5 +++++ 5 files changed, 38 insertions(+), 10 deletions(-)
