FS#69416 - [kodi] use exclusively GL rendering and simplify build and package

Attached to Project: Community Packages
Opened by John (graysky) - Saturday, 23 January 2021, 13:41 GMT
Last edited by Ike Devolder (BlackEagle) - Saturday, 27 February 2021, 14:12 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Ike Devolder (BlackEagle)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

We currently compile both kodi-x11 and kodi-wayland with the GL rendering system and kodi-gbm with GLES rendering but it is unclear to me what we gain by shipping the gbm binary with the reduced feature set of GLES which is intended for embedded systems[1] on x86_64 hardware.

I tested it, and kodi-gbm runs when compiled with GL rendering and it contains more features vs GLES. For example, currently our gbm binary (GLES) does not allow audio/video synchronized sped-up or slowed-down playback via Kodi built-ins[2], PlayerControl(tempoup) and PlayerControl(tempodown). If I compile gbm with GL instead of GLES these features are available.

If we switch to GL rendering for all three variants, we can further simplify compilation and packaging by compiling a single 'kodi.bin' supporting all three in one go rather than compiling three separate times as we currently do. The resulting kodi.bin can auto-detects which windowing system it wants to use based on deps on the system or the user can specify which one via a switch[3]. The result is a slight increase in executable size, and we will have to handle dependencies differently for x11, gbm, and wayland.

1. https://www.khronos.org/opengl/wiki/OpenGL_ES
2. https://kodi.wiki/view/List_of_built-in_functions
3. https://github.com/xbmc/xbmc/pull/18534
This task depends upon

Closed by  Ike Devolder (BlackEagle)
Saturday, 27 February 2021, 14:12 GMT
Reason for closing:  Implemented
Additional comments about closing:  enhancements implemented in kodi 19
Comment by John (graysky) - Saturday, 23 January 2021, 15:16 GMT
Though testing, I can confirm that if we build the unified binary as I suggested with Matrix 19.0RC1, it seems that both waylandpp and libxkbcommon cannot be optdepends they must be depends to run x11 mode. So this change will increase the hard deps.

Example launching without these:
/usr/lib/kodi/kodi.bin: error while loading shared libraries: libwayland-client++.so.0: cannot open shared object file: No such file or directory
/usr/lib/kodi/kodi.bin: error while loading shared libraries: libxkbcommon.so.0: cannot open shared object file: No such file or directory
Comment by Ike Devolder (BlackEagle) - Saturday, 23 January 2021, 18:06 GMT
I guess I can already assume this is an improvement that will only be applicable to kodi 19, So I keep this in mind for when I start preparing for kodi 19
Comment by John (graysky) - Saturday, 23 January 2021, 18:31 GMT
I believe both suggestions can be applied to either version of Kodi, but have only tested with Matrix RC1.

The more I think about it, the more I do NOT like the fact that wayland libs are required if users want to run X11. Perhaps there is a cmake option that makes that optionally, but I don't know of one. If you want to see a modified PKGBUILD (based on kodi-devel): https://gist.github.com/graysky2/8f45c3653434b02180095b8d81143307

So a split package might actually be preferred...

1. I do think you can switch all 3 bin packages to GL rendering and retain the split binaries though.
2. I think you can actually build x11 and gbm together with minimal change in the deps (just libinput I think) and then compile wayland on its own.
Comment by Ike Devolder (BlackEagle) - Saturday, 27 February 2021, 14:11 GMT
I have greatly reduced the complexity of the building of Kodi in the upcoming kodi 19 pkgbuild, while retaining the split kodi-x11, kodi-wayland and kodi-gbm

also the rendering backend will be set to gl for all the binaries, the gles was most likely just copy paste from the README.linux

Loading...