[Question] Mobile Linux Support

[ethical-haquer]

Problem Description

First of all, I'm not really sure if this is better opened here or upstream, let me know if it's the latter.

I just got your mobile fork of ES to build on my PPP (PinePhone Pro). It was a bit of a challenge, since I'm running postmarketOS, which is based off Alpine Linux, which is based on musl libc. Since it uses musl, I had to tweak the SConfiguration file in order for it to build. (On a side note, ES is already packaged in pmOS, but it has the same issue as below, with scaling. Also, it doesn't have the tweaks for mobile that your fork has.)

After I got it to build, it wouldn't run. It said "Monitor resolution is too small!", and then crashed a few seconds later. ("crashed" as in the process ended, it never opened a window). According to the source code, it will say that if your screen is smaller than 640x480. However, the screen on the PPP is 1440x720. I'm not sure how scaling in phosh works, but by default the scale in settings is set to 200%. ES would only start after turning scaling down to 100%. (~it wouldn't start at 125%~ EDIT: It works at 150% or lower) However, setting the scale to 100% is not ideal, because it's system-wide and makes all other apps hard to use (e.g. their buttons are very small, etc.).

TIA, and once again, please let me know if this would be better for upstream!

Related Issue Links

I couldn't find anything about getting ES to run on mobile Linux, surprisingly.

Desired Solution

I'm hoping that in the future ES will "just work" on mobile Linux, and I was wondering what the best way to go about that is.

Alternative Approaches

N/A

Additional Context

No response

[thewierdnut]

My phone is 1440x720, and its quite playable. I'm curious what resolution will be listed if you adjust that error to say:

   ExitWithError("Monitor resolution is " + std::to_string(maxWidth) + "x" + std::to_string(maxHeight));

[thewierdnut]

I will note that I play this game on debian on a lenovo yoga in tablet mode, and the touchscreen controls work just fine.

[ethical-haquer]

My phone is 1440x720, and its quite playable. I'm curious what resolution will be listed if you adjust that error to say:

   ExitWithError("Monitor resolution is " + std::to_string(maxWidth) + "x" + std::to_string(maxHeight));

Great idea.

I will note that I play this game on debian on a lenovo yoga in tablet mode, and the touchscreen controls work just fine.

👍 The touchscreen controls seemed to work alright, albeit the buttons are a little hard to hit on such a small screen. I also added that compact-layout plugin that's used on Android.

Thanks for replying! I'll get back to you once I've messed with it (the code and the game) some more.

[ethical-haquer]

I just tested out that error you suggested, and it says: Monitor resolution is 720x360. So it's simply getting half the actual screen size due to the 200% scaling. Also, disregard what I said before, it will work up to 150% on this phone. 175% is 411 pixels tall. I'm wondering, is it possible to get the resolution without scaling? Or does scaling to 200% actually make each "pixel" displayed use four pixels on the display?

[thewierdnut]

What "scaling" are you referring to here? The in-game Main zoom factor does not affect the reported monitor resolution.

[ethical-haquer]

What "scaling" are you referring to here? The in-game Main zoom factor does not affect the reported monitor resolution.

The scale in GNOME Settings:

Sorry for not clarifying.

[thewierdnut]

Oh. Does the game work if you set that to 100%? You can scale the buttons in-game by changing the UI zoom.

[ethical-haquer]

Yeah, it works if I set it to 150% or lower, but like I said, that messes with all the apps scale. Changing the min values in the source code didn't work :rofl::

[thewierdnut]

it also doesn't appear to be respecting the fullscreen setting.

[ethical-haquer]

I just didn't have it in full-screen, that part does work:

Also, I keep getting dozens of these in the output: Flushing user due to: AFBC write staging blit

[thewierdnut]

Windows tries to do the same thing on high resolution displays, and the upstream project sets the SDL_WINDOW_ALLOW_HIGHDPI flag to tell it to leave the SDL app alone. I wonder if there is a similar hint I can set for you.

[thewierdnut]

what sdl version do you have?

[ethical-haquer]

@thewierdnut 2.30.8, according to sdl2-config --version

[thewierdnut]

x11 or wayland?

[ethical-haquer]

@thewierdnut Wayland.

[thewierdnut]

Uhg. They added a flag to bypass wayland scaling in SDL 3 just this year. There isn't a quick way to get that working...

Can you add some logging statements here?

Something like

SDL_Log("WindowSize: %d %d   DrawableSize: %d %d", windowWidth, windowHeight, drawWidth, drawHeight);

[ethical-haquer]

@thewierdnut This is with the keyboard up: INFO: WindowSize: 720 133 DrawableSize: 1440 266 and the keyboard down (hidden): INFO: WindowSize: 720 360 DrawableSize: 1440 720 On startup: INFO: WindowSize: 720 313 DrawableSize: 1440 626 I'm getting flooded with Flushing user due to: AFBC write staging blit, do you happen to know how to silence those? Thanks for the help!

[thewierdnut]

INFO: WindowSize: 720 360 DrawableSize: 1440 720

Interesting. That implies that the pixels are still there, its just lying about the surface size. That means that if I make it so that you can scale the window size to less than 100%, it should still look good.

Flushing user due to: AFBC write staging blit

I've never seen this, and google isn't helpful either. it looks as though I'll have to dig into the graphics driver source code to find this one. What graphics driver are you using? (glxinfo)

[thewierdnut]

I've pushed an update that reduces the minimum zoom to 50%. Try setting that and see if it helps.

[ethical-haquer]

I hope this is the info you need: OpenGL renderer string: Mali-T860 (Panfrost). Let me know if it's not.

I tried with your changes, and it worked wonderfully:

[thewierdnut]

Let me know if you run across any user interface quirks. I've run into issues in the past where the window environment would reinterpret touch events as mouse clicks, even though the game handles touch events directly.

[ethical-haquer]

What is the standard way to open up the map or jump from the flight view? I've been pulling up the keyboard, but there must be a better way.

A different issue is that clicking buttons that are on the bottom of the display causes the top and bottom bars (in the OS, not the game) to show, essentially making it not go full-screen temporarily. That is an issue with phosh though, not the game.

[thewierdnut]

Where are your onscreen buttons? It should look like this:

[thewierdnut]

Check these preferences in the second page of the settings menu:

[ethical-haquer]

That was the problem, those were turned off. I guess since I'm using a Linux build those aren't turned on by default like they are for the Android build. Thanks for the tip.

How does the game typically handle starting from portrait? Like on Android does it automatically go landscape?

[thewierdnut]

I lock it into landscape with the manifest: https://github.com/thewierdnut/endless-mobile/blob/android/android/app/src/main/AndroidManifest.xml#L77

I'm not sure how to do something similar on a pinephone.

[ethical-haquer]

Your phone has a little more power than this PPP (look at the CPU/GPU load :smile:):

May I ask what phone you have?

[thewierdnut]

That was a screenshot from my desktop, which is just using the integrated graphics on a ryzen 9 7900 cpu.

This is a screenshot from my phone, a moto g7 power, which is much closer to the GPU limit:

[thewierdnut]

Note that you can turn some of the special effects off in the settings. I typically turn off at least motion blur.

[thewierdnut]

The game typically doesn't use up a lot of cpu. I've had it working on 12 year old tablets, no problem. I suspect that whatever is flooding your logs is causing your high cpu usage, probably more from the logging than from the actual issue.

[ethical-haquer]

You're probably right, I'm getting those nonstop, hundreds of them.

[ethical-haquer]

Have you ever flashed a custom ROM to your Moto G7 Power?

[thewierdnut]

Yeah. I ran lineageos for a while. It was unstable and the colors kept breaking. I eventually went back.

[ethical-haquer]

Cool, did it seem any faster on LOS? What do you mean by "colors"?

[thewierdnut]

No, lineageos was slower. By colors, I mean the color profile was wrong, and all of the reds and blues were swapped. Adjusting the color profile would fix it, at least until next reboot. I also couldn't reliably get phone calls or text messages.

[ethical-haquer]

Yeah, that sounds more like an unofficial LOS build. :grimacing: How long ago was that?

Regarding getting your build running on mobile Linux, I think that it's running pretty good now. Hopefully we can get the "hacks" for scaling implemented in a way that can be used upstream. Or will upstream not bother with mobile Linux? I guess it might just be something to get working on your branch. Then there's the tweaks I had to make in order to get it built with musl. Should I try to get those in upstream? (since it's not mobile-specific) TIA.

[thewierdnut]

Upstream won't accept merges for mobile or touchscreen support. That's why I maintain this fork.

I'll leave the zoom changes in place. I think that the first time it loads it will auto-compute the correct aspect ratio, as it tries to set it automatically as high as possible. Most mobile users never even mess with it.

[thewierdnut]

Then there's the tweaks I had to make in order to get it built with musl. Should I try to get those in upstream?

If you want to know, raise an issue upstream asking about it, or join the endess-sky discord and ask in #the-hub

[thewierdnut]

Hey, you mentioned you used scons to build it? I'm surprised that still works. I use cmake, and the upstream repo primarily does as well.

[ethical-haquer]

@thewierdnut Well, your README says: "Most development is done on using the SCons build tool to compile the project." And in the Linux build instructions: "Then, from the project root folder, simply type: $ scons, $ ./endless-sky" Oh, now I see that the upstream README says to use cmake. I think your README needs updating then. 😉

But yeah, I guess I was able to build it with scons. I should try building it with cmake then, and see what tweaks need to be done there.

[ethical-haquer]

Interesting, I'm not used to seeing Linux build instructions listed after Windows. Do most ES devs use primarily Windows? Your README (which I presume used to be the same as upstream's) lists Linux, Windows, and then macOS, which is more what I'm used to seeing.

[thewierdnut]

Yeah, I started with the upstream readme and stripped out what wasn't relevant, then haven't touched it since then. The upstream project has changed quite a bit since then.

edit: There, I added an issue to remind myself to fix the readme later.

[ethical-haquer]

@thewierdnut Nice. I'm working on getting it to build with cmake.