Question Linux player lifecycle issues on Linux From Scratch

I tried creating a Unity game to run on Linux with mixed success. I have an up-to-date Arch Linux build running gnome and it runs anything I build just fine. When I try to run the same game on a more locked down Linux From Scratch build I am having issues. (I am not the Linux guru, but am opening this ticket because I wrote the game). I have since boiled the entire build down to just one very simple activity and can see the lifecycle still doesn't seem to be working properly.

On LFS I start X manually and then launch the game OK without any errors in the Player.log. The graphics seem fine, but the MonoBehaviour lifecycle seems suspect. I have debug logs showing the update method is only called once and then never again. I also try to call a coroutine from the start method which will run code in a loop with a WaitForSeconds yield before looping back to the top. It only executes once up until the point where I have the WaitForSeconds and it never gets past that. The default input drivers are not loaded in the OS, but X uses evdev drivers and I can move the mouse on the screen, but none of the buttons accept a click event.

Since the same game runs fine on native Arch I am likely missing something in LFS. I couldn't find a player requirements page to see what libraries might be needed (only found the Editor requirements) or any other breadcrumbs on what might be the issue. I have included the small player log which doesn't contain any errors, but does show the IEnumerator not looping as well as the Update method not being called more than once.

Any hints or suggestions on how to troubleshoot this would be greatly appreciated.


Here is my extremely simple script for my activity:
public class testTime : MonoBehaviour
{
[SerializeField] private TMP_Text readText;

private void Awake()
{
Debug.Log("LinuxTest - Awake method called.");
}

private void Start()
{
Debug.Log("LinuxTest - Start method called. Beginning of method");
StartCoroutine(LoopingIEnumerator());
Debug.Log("LinuxTest - Start method called. End of method");
}

private void Update()
{
Debug.Log("LinuxTest - Update method called. Beginning of method");
readText.text = DateTime.Now.ToLongTimeString();
Debug.Log("LinuxTest - Update method called. End of method");
}

private IEnumerator LoopingIEnumerator()
{
Debug.Log("LinuxTest - LoopingIEnumerator called. Beginning of call");
float CONTROL_PACKET_LOOP_TIME = 1f;
int loops = 0;

while (loops < 5)
{
Debug.Log("LinuxTest - About to use WaitForSeconds for " + CONTROL_PACKET_LOOP_TIME + " seconds before looping. Will debug log again right after");
yield return new WaitForSeconds(CONTROL_PACKET_LOOP_TIME);
loops++;
}

Debug.Log("LinuxTest - LoopingIEnumerator called. End of call");
}
}

 

The first thing that comes to mind is the compositor. Many 3D games and applications (not just Unity) require a compositor to work properly. Gnome does compositing for you. Most desktop environment will do compositing, but sometimes it has to be enabled manually (for example on KDE it can be disabled). But you didn't say which desktop environment you're using on your LFS install.

 

Thank you for the reply! The LFS is hardend such that it doesn't even have an official desktop it uses. In a production environment it will start X via script and boot right into a game (none of the previous games were developed using unity so this was never a problem before). In a development environment it will boot into a read-only screen with some debug info, but you still can't do anything locally. I can however SSH into a development box, startx and launch my game manually to test though.

I will mention this to the systems dev to see if it makes sense to him. You think that would effect the MonoBehavior weirdness I am seeing?

 

I can't be certain but if I had to bet I would put my money on that. Update() is being called every frame, but without a compositor the game will not get the message that the frame has finished drawing.

Maybe an alternate solution would be to tweak the VSync setting in your game. But I'm not sure it will work, and even if it does the result will probably look like S*** because of tearing.

X alone will not do compositing. You need a compositor. I know there are some lightweight compositors like Compton and Picom that can be used without installing a whole desktop environment. But I never tried that.

 

Player requirements are in the same page slightly lower. https://docs.unity3d.com/Manual/system-requirements.html#desktop

Essentially anything except Gnome on X11 in the stock installation of Ubuntu 18.04, 20.04, Centos 7 is unsupported.

Assuming ChiwTheNeko was right and problem is in lack of compositor, might want to also consider gamescope https://github.com/ValveSoftware/gamescope as a minimalistic compositor made for the exact purpose of running games.