Support for Linux

[Enny1991]

Hi thank you for your work!
What is the reason behind the missing support for Linux platform? I would be happy to contribute if the reason is only missing resources for the development.

[brifsttar]

Hi @Enny1991,

@cboulay did all the original work on the plugin, so he's the one who would know that. On my part, I'm only using Windows, so that would be the only reason.

So if Chad has no objection to this, the contribution would be very welcome! :-)

[cboulay]

No objection.
(Background context: I was using the UE4 plugin for a VR experiment, and at the time there was no viable solution to do VR in Linux.)

[Enny1991]

Cool! Thanks @cboulay and @brifsttar. I have started looking into it and it seems doable, few questions, the compiled dll library was compiled outside (i.e. lsl repo) and transplanted or compiled from this repo using lsl.lib as base?
I managed to get a version of the plugin running by compiling the .so library from the source lsl repo and copying it over, but I am encountering Segmentation faults at runtime and was thinking it might be due to that.

[brifsttar]

From my recollection, we use a very standard liblsl release 1.16.1 (see 95726cb). Maybe using a .so from that release tag would work better?

We could also use the opportunity to bump the liblsl dependency to latest.

[Enny1991]

Thanks for your suggestion! I've built an .so from v1.16.1 and it is now not crashing anymore, which I consider progress :). My cube is not moving for the moment but I'll keep trying.

Do you think the reason for the crash using a newer compiled version could be incompatibility between the code shipped with the plugin and the library?

[brifsttar]

If you just brought the .so from a v1.16.2 build, without updating the plugin's headers in Source/ThirdParty/liblsl/include to match that release, then it could indeed lead to a crash.

[Enny1991]

After enabling some logging I figured that the plugin is running but is not able to resolve the input stream. The input stream is present and is discoverable as I can received it with a second script normally. Since I am using pylsl to produce/retreieve these streams I tried to downgrade that as well to v1.16.2 thinking that it could be due to some changes in network default config, but that did not help. The only clue I have so far is that the logs internal to Unreal Engine show a different net interfaces with respect to the ones used by python.

Unreal

2025-05-26 11:59:42.661 ( 289.831s) [UnrealEditor    ]      netinterfaces.cpp:89    INFO| netif 'lo' (status: 0, multicast: 1, broadcast: 0)
2025-05-26 11:59:42.662 ( 289.831s) [UnrealEditor    ]      netinterfaces.cpp:89    INFO| netif 'enp36s0f0' (status: 4096, multicast: 1, broadcast: 2)
...
2025-05-26 11:59:42.662 ( 289.831s) [UnrealEditor    ]      netinterfaces.cpp:89    INFO| netif 'enp36s0f1' (status: 4096, multicast: 1, broadcast: 2)

Python

2025-05-26 11:47:37.282 (   0.001s) [python          ]      netinterfaces.cpp:89    INFO| netif 'lo' (status: 1, multicast: 0, broadcast: 0)
2025-05-26 11:47:37.282 (   0.001s) [python          ]      netinterfaces.cpp:89    INFO| netif 'enp36s0f0' (status: 1, multicast: 4096, broadcast: 2)
...
2025-05-26 11:47:37.282 (   0.001s) [python          ]      netinterfaces.cpp:89    INFO| netif 'enp36s0f1' (status: 1, multicast: 4096, broadcast: 2)

any thoughts?

[brifsttar]

Hmm strange, I just tested on my side (Windows) and it works without issue.

To create an outlet, I just did

py -m pylsl.examples.SendData

On the Unreal (5.5) side, I made this very simple actor Blueprint

I dropped it in an empty world, hit play, and I receive the data without issue.

LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.826401;0.380272;0.525925;0.876422;0.124707;0.041926;0.93871;0.370701
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.226472;0.225111;0.306661;0.456626;0.818397;0.135144;0.724467;0.02067
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.29911;0.148445;0.081052;0.739714;0.492732;0.686326;0.980025;0.138912
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.050533;0.539606;0.549794;0.95511;0.417806;0.141113;0.398095;0.557591
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.632906;0.199422;0.307971;0.482626;0.751068;0.492936;0.557089;0.341142
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.392165;0.4164;0.899768;0.450748;0.447023;0.41129;0.002794;0.393648
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.677745;0.398796;0.456554;0.978496;0.047042;0.324009;0.433506;0.730584
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.243769;0.276821;0.668333;0.528712;0.657703;0.51688;0.098243;0.570474
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.4683;0.943939;0.316918;0.98658;0.776734;0.714895;0.092591;0.096808
LogBlueprintUserMessages: [NewBlueprint_C_1] ;0.329415;0.207762;0.094435;0.322218;0.296491;0.009583;0.961329;0.953494

I had never used the inlet component before, so I can't say it's been battle tested. But I can't think of anything that would cause this issue.

[Enny1991]

Thanks for checking @brifsttar! I did reproduce the same blueprint

but the issue remains the same i.e. the resolver is failing to resolve any stream. I will keep exploring the network issue trail, the fact the log output indicates netif 'lo' (status: 0, multicast: 1, broadcast: 0) reminds me of some issue people were experiencing with multicasting with LSL running in docker on a same machine. Maybe for some reason the internal network setup of UE5 is different for Linux.

[Enny1991]

Quick update, I believe the problem does not reside in network issues but instead in wrong/incompatible compiled versions of liblsl.so. I am currently trying to compile a version of liblsl using the same compiler/linker shipped with my current version of UE which is proving more challenging than anticipated.

[Enny1991]

Hey guys, took a long time cause I was sidetracked, but I finally have a working version of liblsl.so compiled with the UE toolchain that works on UE 5.4.4. The big question is whether it would work for other UE version and other Linux distros. I will test other UE, but I am not sure I can test other Linux distros (using Ubuntu right now). I can include instructions on how to recompile liblsl locally with UE toolchains and a script to detect locally installed UE and their toolchains and have the user select which one they want to use.

@cboulay @brifsttar Let me know if this is a viable solution or if you have other suggestion on how to do this.

PS: I realize I might be the only person on earth caring about using LSL with UE on Linux, but you never know :)