[alan_griffiths]

I'm from the Mir project that's used by Canonical for IoT graphics. For demonstration purposes I have put together a snap of Kodi for Wayland based on ppa:team-xbmc/ppa.

While the demo targets Ubuntu Core, the snap works for any distro that supports snaps and has a Wayland supporting desktop.

Is snap packaging something of interest to the Kodi project? And is there anyone in the project interested in maintaining it?

It shouldn't be a lot of work and I'm happy to share what I know.

For the curious: packaging for Kodi Wayland on GitHub and Kodi Wayland in the Snap Store

[wsnipex]

Interesting,  I didn't think using kodi from our ppa in a snap could work, maybe snap finally fixed a couple of really annoying issues.
Does hardware video decoding with vaapi and vdpau work?

In case you are interested, there is some history about my snap efforts in this thread:  https://forum.kodi.tv/showthread.php?tid=315213

btw, the stage package kodi-repository-kodi should be removed, this is not provided by our ppa (its debian patchery from official repos).

[alan_griffiths]

Interesting,  I didn't think using kodi from our ppa in a snap could work, maybe snap finally fixed a couple of really annoying issues.

I've had some experience with using PPAs with snapcraft (Mir is released to a snap) and can confirm that, while it has always been possible, it has got a lot easier over time.

In particular, adding support for local plugins, made it easy to ensure that the PPA was added before the pull step.

Does hardware video decoding with vaapi and vdpau work?

I don't know enough about Kodi to answer this. (I've got so far as installing YouTube and iPlayer plugins and seen them work.)

btw, the stage package kodi-repository-kodi should be removed, this is not provided by our ppa (its debian patchery from official repos).

Thanks for that, will update accordingly.

[alan_griffiths]

Does hardware video decoding with vaapi and vdpau work?

I looked a bit closer.

Loading i965_drv_video.so was failing because I didn't stage i965-va-driver.

But adding that leads to a further failure:

error: failed to resolve wl_drm_interface(): /snap/mir-kiosk-kodi/x4/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_drm_interface

A google search turns up intel-vaapi-driver#419: use wl_drm_interface from libva and not libEGL - which is plausibly not fixed in the 18.04 archive.

[wsnipex]

In case you want to give it a try, I've put up libva 2.5 and i965-va-driver 2.3.0 here: https://launchpad.net/~wsnipex/+archive/ubuntu/vaapi

I don't have a wayland desktop on intel gpu atm, so I can't easily test it myself right now.

[alan_griffiths]

In case you want to give it a try, I've put up libva 2.5 and i965-va-driver 2.3.0 here: https://launchpad.net/~wsnipex/+archive/ubuntu/vaapi

I don't have a wayland desktop on intel gpu atm, so I can't easily test it myself right now.

Thanks, I'll try that later.

I don't run a Wayland desktop either. If you're running X11/Mesa you can leverage Mir's support for running on X11:

Update snapd to edge (there are some recent changes that make this work), install mir-kiosk and mir-kiosk-kodi run them:

snap install --edge snapd
snap install mir-kiosk
snap install mir-kiosk-kodi # Or your local build: snap install --dangerous *.snap
/snap/mir-kiosk-kodi/current/bin/setup.sh
mir-kiosk&
mir-kiosk-kodi

[alan_griffiths]

In case you want to give it a try, I've put up libva 2.5 and i965-va-driver 2.3.0 here: https://launchpad.net/~wsnipex/+archive/ubuntu/vaapi

Thanks, I'll try that later.  

Actually, that was faster than I expected: https://github.com/MirServer/mir-kiosk-kodi/pull/4

libva info: VA-API version 1.5.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /snap/mir-kiosk-kodi/x4/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_5
libva info: va_openDriver() returns 0
sh: 1: nmblookup: not found
WARNING: Invalid RefPicListX[] entry!!! It is not included in DPB

So far (va_openDriver() returns 0), so good. Not sure what the rest shows.

[wsnipex]

this looks ok from vaapi side. You can verify vaapi is working by playing a video and pressing "o" to show the player info screen. It should read ..-vaapi in the codec info.

[alan_griffiths]

this looks ok from vaapi side. You can verify vaapi is working by playing a video and pressing "o" to show the player info screen. It should read ..-vaapi in the codec info.

Confirmed.

I've created an "edge/wsnipex-i965-va-driver" channel with this version. It can be tested with:

snap install --channel edge/wsnipex-i965-va-driver mir-kiosk-kodi
/snap/mir-kiosk-kodi/current/bin/setup.sh

For the moment, I'm reluctant to add this "random PPA" to the stable package as I've no oversight of its contents. (It looks as though ppa:ubuntu-x-swat/updates predates the wl_drm_interface fix.)

[wsnipex]

Nice, I'll try to test this later at home.
I agree that adding a random ppa is not a clean solution. You could add libva and i965-va-driver built from source as component in the snap instead.
OR I might add those 2 to our official kodi ppa instead. We've done that in the past when there were issues with official packages, but this would need more testing

[alan_griffiths]

OR I might add those 2 to our official kodi ppa instead. We've done that in the past when there were issues with official packages, but this would need more testing

Another thing you might be able to inform me on: For my purposes, ARM support would be convenient.

But the ppa:team-xbmc/ppa doesn't support ARM architectures. What is the reason for this?

I assume there's no technical limitation as I've seen arm packages in the Ubuntu archive (but these lack Wayland support)?

[wsnipex]

Arm SOCs are very heterogeneous in terms of mainline linux and video decoding api support. They heavily depend on closed source binary blobs for gfx drivers, sometimes very old, non-mainline, vendor specific linux kernels and historically have their own custom video decoding apis.
It's impossible to build a one size fits all package that would work properly on more then 1 Soc family at a time.
Some vendors have finally acknowledged that this is a big issue and started working towards mainline linux support and using v4l2 and gbm/libdrm, but we're not there yet.

If you can live without hardware video decoding, it is possible to get kodi running on a number of recent socs, e.g. raspberry pi 4, but we're not going to release half-baked builds on our PPAs.

edit: If you only want to provide kodi for a specific arm soc, it could be possible, provided it doesn't need a custom kernel. E.g. You can make rpi4 work, but atm it still requires binary blobs (MMAL), and a 32bit kernel

[alan_griffiths]

Arm SOCs are very heterogeneous in terms of mainline linux and video decoding api support. They heavily depend on closed source binary blobs for gfx drivers, sometimes very old, non-mainline, vendor specific linux kernels and historically have their own custom video decoding apis.
It's impossible to build a one size fits all package that would work properly on more then 1 Soc family at a time.
Some vendors have finally acknowledged that this is a big issue and started working towards mainline linux support and using v4l2 and gbm/libdrm, but we're not there yet.

Thanks, that makes sense. (I'm well aware of this background from my work on Mir.)