How to support /var/run/spnav.sock ?

[Arxcis]

Linux distribution and version

PopOS 19.10 + Gnome 3.34 on Wayland

Flatpak version

1.4.3

Description of the problem

Hi, I have a SpaceNavigator "3D-mouse". This device is supported by Blender running outside Flatpak. Blender uses an open source driver, spacenavd (daemon) + libspnav (client library), which communicates over a unix socket /var/run/spnav.sock. This socket is not one of the "well-known" sockets. How do I expose the socket to flathub/org.blender.Blender?

References

The problem is discussed further in this issue flathub/org.blender.Blender#18
There is also an open PR (with no working solution) @ flathub/org.blender.Blender#19

[eszlari]

The Flatpak sandbox has its own /var and therefore doesn't expose /var from the host system:
https://docs.flatpak.org/en/latest/sandbox-permissions.html#filesystem-access

You will have to ask the developers of spacenavd/libspnav to make that path configurable.

[alexlarsson]

It is actually possible to export stuff from /var using --filesystem=/var/foo. However, /var/run is special as it is normally symlinked to /run, and is not really a regular filesystem.

[Arxcis]

It is actually possible to export stuff from /var using --filesystem=/var/foo. However, /var/run is special as it is normally symlinked to /run, and is not really a regular filesystem.

Just to clarify. In theory it is possible, but under the current implementation of Flatpak it is not possible?

[hammerandtongs]

It seems like asking users to reconfigure the location of /var/run/spnav.sock is going to break the model of flatpak in general.

They'll need root and some configuration chops which ... hopefully flatpak users don't need.

It would seem like adding a spnav socket to the flatpak configuration would be better overall.

--socket=spacenavigator

These space navigator devices are very unknown for most people but very well known among 3d professionals working in 3d/CAD environments (they are magic once you discover them). These folks would seem like a primary target for installing Blender or Freecad via flatpak.

[Arxcis]

You will have to ask the developers of spacenavd/libspnav to make that path configurable.

@eszlari You would also need to ask Blender developers to make the socket reconfigurable, because last time I checked the socket was hard coded into Blender source code.

I am starting to think the best is to solve this in Flatpak, and make the socket a «well-known» Flatpak socket.

[hammerandtongs]

The flathub apps -

Blender
OpenSCAD
FreeCAD

need this socket support.

https://3dconnexion.com/uk/supported-software/?fwp_supported_software_operating_system=linux

Is a list of 13 mostly commercial large cad systems that might interested in flatpaks in the future.

@alexlarsson is adding a well known socket to flatpak an acceptable path forward? ie

--socket=spacenavigator

providing -

/var/run/spnav.sock

tldr; Reconfiguring the daemon at the distribution requires root and I believe several of the apps would recompiling to support a different scheme from flatpak.

[adrianinsaval]

it seems to be now configurable in libspnav https://github.com/FreeSpacenav/libspnav/releases/tag/v0.3 what is needed to make the flatpaks work?

[ananace]

It's a simple matter of passing through the socket from /run and (optionally) updating libspnav and adding the new environment variable to point it to the socket. (e.g. flathub/org.freecadweb.FreeCAD#55)
Since /var/run is supposed to be a symlink, it should be enough with the filesystem passthrough from /run, but I personally feel better being explicit about things when using different paths than those hardcoded in the lib.

[Arxcis]

I think we have a solution now, which is proven to work for multiple apps - Blender and FreeCAD - as documented in this issue flathub/org.blender.Blender#18

I therefore close this issue now :) Thank you for all contributions 👍