Linux snap packaging
#1
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
Reply
#2
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:  315213 (thread)

btw, the stage package kodi-repository-kodi should be removed, this is not provided by our ppa (its debian patchery from official repos).
Reply
#3
(2019-10-04, 14:48)wsnipex Wrote: 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.
(2019-10-04, 14:48)wsnipex Wrote: 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.)
(2019-10-04, 14:48)wsnipex Wrote: 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.
Reply
#4
(2019-10-04, 14:48)wsnipex Wrote: 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.
Reply
#5
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.
Reply
#6
(2019-10-06, 11:59)wsnipex Wrote: 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
Reply
#7
(2019-10-07, 10:43)alan_griffiths Wrote:
(2019-10-06, 11:59)wsnipex Wrote: 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.
Reply
#8
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.
Reply
#9
(2019-10-07, 11:59)wsnipex Wrote: 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.)
Reply
#10
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
Reply
#11
(2019-10-07, 16:22)wsnipex Wrote: 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)?
Reply
#12
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
Reply
#13
(2019-10-09, 09:00)wsnipex Wrote: 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.)
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
snap packaging00