NW.js app can't run on Steam Linux Runtime (libcups)

[prominentdetail]

I was told to open a new issue.
I'm having same issue as this:
#579

My users that use SteamDeck can't open my app: (I don't have SteamDeck, so I can't test it myself).
My app # is 1244040

Here is a past report I made to nw.js:
nwjs/nw.js#8032

I also opened a support ticket with valve in the past and an employee told me they get an error: " libnw.so: undefined symbol: cupsEnumDests "

My app uses nw.js v0.66.1

I'm not sure how to continue, since I don't own a SteamDeck.

[dfabulich]

It'll be a huge help if you can provide "To reproduce" instructions, like the instructions I provided in #579. At a minimum:

1. A shipping game where it doesn't work (ideally with a free demo… your game 1244040 doesn't have a demo)
2. Steps to launch a hello-world NW.js app on Steam Deck.

It might be worth buying a Steam Deck to investigate and reproduce these issues.

[smcv]

If this is similar to #579, then it's probably possible to reproduce this on a Linux system that is not a Steam Deck, with: right-click -> Properties -> Compatibility -> Force the use of -> Steam Linux Runtime.

Game Dev Tycoon (239820) is an example of a NW.js app that is (or was) known to work in that environment (I know because we had to add some more libraries to make it work, similar to #579). But I think that's using an older version of NW.js, which is probably why it didn't have #579.

As with #579, the bottom line here is that having someone else build a binary in a non-Steam-Runtime environment, and then dropping it into a Steam Runtime environment and hoping that it still works, is not really something that can ever be reliable. The benefit of the container runtime used on Steam Deck is that after an app or game works in that restricted environment, it'll probably work on all Linux distributions, for a long time - but the cost is that it needs to be made to work in that restricted environment in the first place.

[smcv]

I tried Janosik (1412170), the first free NW.js game I could find, and that works fine in the Steam Linux Runtime environment. Its lib/libnw.so is 64-bit, depends on libcups.so.2 and requires the cupsEnumDests symbol, so as far as I can see, it would not have worked while #579 was open; but it works now.

I also tried removing everything except Janosik 1 ver1.6 and package.nw, and unpacking nwjs-v0.66.1-linux-x64.tar.gz into its top level directory instead. That also seemed to work fine. Is that how your game works?

[prominentdetail]

If this is similar to #579, then it's probably possible to reproduce this on a Linux system that is not a Steam Deck, with: right-click -> Properties -> Compatibility -> Force the use of -> Steam Linux Runtime.

I tried to run it with compatibility setting (Steam Linux Runtime), and it runs fine on my linux virtual machine ubuntu 22.04.
So, I don't know why it doesn't run on the Steam Deck for my user. Is there something different between a linux machine versus the steam deck when it comes to running the steam linux runtime?

I also tried removing everything except Janosik 1 ver1.6 and package.nw, and unpacking nwjs-v0.66.1-linux-x64.tar.gz into its top level directory instead. That also seemed to work fine. Is that how your game works?

Yeah, I think so. It uses the nw.js 0.66.1 files to package the app.

[smcv]

Is there something different between a linux machine versus the steam deck when it comes to running the steam linux runtime?

There shouldn't be, except for whether they use it by default or only as an opt-in.

Native Linux games on Deck use Steam Linux Runtime by default, and native Linux games on all other Linux platforms only use Steam Linux Runtime if you specifically ask for it. For historical reasons, on desktop you get the legacy LD_LIBRARY_PATH runtime by default, but the Steam Deck team don't want to support that or use it in their QA testing, because it's a constantly moving target (it uses a lot more files from the OS, instead of trying to limit itself to what's in the runtime) so it could easily regress with an OS update, particularly with a reduced-size OS installation like the one on the Deck.

I don't actually have access to a Steam Deck myself at the moment, but my colleagues do. I'll ask someone to try Janosik on Deck and report back. Failing that, if you can give us a key for your specific game (email smcv at collabora.com) or point us to a game with a demo that has the same problem, that's probably the easiest way to get more information.

[sleepingpandagames]

#579 fixed the issues I had for my game that was not launching on the SteamDeck as well.

Some players reported me several issues still like not being able to open the game still, or some screen glitches when the game was trying to go full screen on game starts.
I tested it on my own SteamDeck and I could see that Steam was suggesting to run the game using Proton 0.7.x. If I set the compatibility setting to force to run the game using Proton 0.8.x or the latest Steam Linux Runtime, the game works perfectly with no glitches. So I suggested my players to do the same.

I just wanted to share the info, and hope that it helps.
Thanks for all your efforts fixing this!

[smcv]

Ah, I might see what has happened. If your game has gone through Steam Deck compatibility testing and the testers reported that the native Linux version didn't work (because of #579), then it might have been flagged to run the Windows binaries via Proton by default, instead of the native Linux version.

This is necessary because some games offer a native Linux build but it doesn't actually work (or only works on the developer's machine), so sometimes running the Windows build via Proton is more reliable.

If that happens, then the thing to do is to force the compatibility setting to Steam Linux Runtime (which will install the native Linux version of your game), test that, and if successful ask your Valve representative for re-testing.

[smcv]

using Proton 0.7.x [...] using Proton 0.8.x

FYI it's Proton 7.0 and 8.0 (based on Wine 7.0 and 8.0 respectively). There was never a Proton release versioned 0.x, the oldest version of Proton is 3.something.

[smcv]

In https://steamdb.info/app/1244040/info/ I see that @prominentdetail's app Crocotile has "recommended_runtime: native", so the Steam Deck is probably already trying to use the native Linux binaries via Steam Linux Runtime? But I could be wrong. (SteamDB is unofficial, but seems to be usually reliable on these things.)

CrossCode, https://steamdb.info/app/368340/info/ is an example of a NW.js game that has been flagged to run under Proton, with "recommended_runtime: proton-stable". (Maybe its developer should ask for re-testing after the changes we made in #579, but if its Windows build works acceptably on Deck via Proton, that's good enough for now.)

Janosik, https://steamdb.info/app/1412170/ is an example of a NW.js game that has not yet been tested on Steam Deck and therefore has no specific configuration either way.

For comparison, Into the Breach, https://steamdb.info/app/590380/info/, is a non-NW.js game that works well as a native Linux game on Deck.

Whatever game @sleepingpandagames mentioned probably has the same configuration as CrossCode? @sleepingpandagames, would you mind telling me the Steam app ID of your game so I can compare?

[sleepingpandagames]

using Proton 0.7.x [...] using Proton 0.8.x

FYI it's Proton 7.0 and 8.0 (based on Wine 7.0 and 8.0 respectively). There was never a Proton release versioned 0.x, the oldest version of Proton is 3.something.

Indeed.. I was on the go so I did not check. Sorry for misinformation.

Whatever game @sleepingpandagames mentioned probably has the same configuration as CrossCode? @sleepingpandagames, would you mind telling me the Steam app ID of your game so I can compare?

Sure! My game Steam app ID is 1271910, https://steamdb.info/app/1271910/

One quick note though. Looking at how well Windows build work on Linux using Proton, is it still worth it to provide a Linux build for our games? I'm always afraid things break with every new versions of NW.JS, tbh.

[smcv]

My game Steam app ID is 1271910, https://steamdb.info/app/1271910/

As I suspected, it's like CrossCode: "recommended_runtime: proton-stable" on Deck. From its name, I would guess that the meaning of that flag might change from Proton 7 to Proton 8 at some point in the future, when Proton 8 has been more heavily tested, but I don't have any special insider knowledge that can confirm or deny that.

If the Linux build is known-good on Deck after #579, you could ask for it to be re-tested as a native Linux game. I'm not a game developer, so you'd know the procedure for that better than I do!

Looking at how well Windows build work on Linux using Proton, is it still worth it to provide a Linux build for our games? I'm always afraid things break with every new versions of NW.JS, tbh.

That's up to you and what you're willing to test/support as the game developer. It could go either way: a new version of the NW.js Linux binaries could regress in the native Linux "Steam Linux Runtime" container, but equally, a new version of the NW.js Windows binaries could start using a Windows API that Proton doesn't yet implement correctly. Any time you're relying on a third party to build your game's binaries, you're also relying on them to provide updated binaries that still work in your target environment.

The only thing we can recommend for native Linux games is using binaries that have been compiled in the Steam Runtime SDK, against the libraries that the Steam Runtime guarantees to provide - but I realise that for a web runtime like NW.js, which is basically an entire web browser, that's not necessarily practical.

[smcv]

I tried Janosik (1412170), the first free NW.js game I could find, and that works fine in the Steam Linux Runtime environment. Its lib/libnw.so is 64-bit, depends on libcups.so.2 and requires the cupsEnumDests symbol, so as far as I can see, it would not have worked while #579 was open; but it works now.

A colleague has confirmed that this works on Deck, forcing the Steam Linux Runtime compatibility tool, and with or without overwriting its copy of NW.js with the NW.js v0.66.1 x86_64 binaries linked above.

The should be similar to @prominentdetail's app - obviously the actual app/game content will be different, but this issue is about whether the NW.js runtime starts up, and if you're all using the same prebuilt binaries then that should be generic across all apps/games?

(In case it becomes important later, my colleague was using the latest stable versions as of today: SteamOS BUILD_ID=20230313.1, VERSION_ID=3.4.6 with Steam client 1679680416.)

[smcv]

I also tried removing everything except Janosik 1 ver1.6 and package.nw, and unpacking nwjs-v0.66.1-linux-x64.tar.gz into its top level directory instead. That also seemed to work fine. Is that how your game works?

For completeness: I also tried overwriting Janosik 1 ver1.6 with the nw from nwjs-v0.66.1-linux-x64.tar.gz, so that the only file I have that came from the original game is package.nw. The result is:

.../steamapps/common/Janosik$ find . -type f -print0 | grep -zv locales/ | sort -zu | xargs -0 md5sum
9585bcd7a4494787d3e372d01877201d  ./chrome_crashpad_handler
c883dcd914613c3b576da901ba5f94b1  ./credits.html
6690f2b2384e1bf8961fda96a4d07691  ./icudtl.dat
f92743a713539b98eba9527499180246  ./Janosik 1 ver1.6
7bf5ea3dd8acc4461eb71797604429e6  ./lib/libEGL.so
e412e1e9c22f8b7e7a976211ba1e9281  ./lib/libffmpeg.so
9040125fc480e49e6e9ec45e5e92ffc3  ./lib/libGLESv2.so
70cd0bf597708249cf31e87406d35cc1  ./lib/libnode.so
f5ae226f449b660dbf4389150fe4909b  ./lib/libnw.so
b677c5bfdff460144f2839bd7df86147  ./lib/libvk_swiftshader.so
d1467b4da148ea8986878a4d5ca8e289  ./lib/libvulkan.so.1
c85ec806c575220afc0c3378c6653dd8  ./lib/vk_swiftshader_icd.json
02cfbec5711bb4bd744b36648856a1a7  ./nw_100_percent.pak
1ca1b0dcaadd8e63a836877b3cfe9aaf  ./nw_200_percent.pak
c080002ff248a9e9678e8a997d48b54f  ./package.nw
76d69e731beb3a897ca7ace07ec12bed  ./resources.pak
29e2a207f3f024d4aa40a29ceeebf302  ./v8_context_snapshot.bin

If I understand the way this works correctly, any other NW.js v0.66.1 game should be the same md5sums as this, except that package.nw will be different?

This also worked on my desktop (Debian 12 prerelease and Steam beta, just in case that's important) and on my colleague's Deck.

[smcv]

My app uses nw.js v0.66.1

From what I can see on SteamDB, it doesn't seem to be the same binaries as in nwjs-v0.66.1-linux-x64.tar.gz: your main executable is a lot larger than nw, your resources.pak is twice the size, and it contains chromedriver and NACL stuff that isn't in the NW.js release binaries. So I think your browser engine binaries might not be what I thought they were.

[smcv]

Ah, it looks more like the contents of nwjs-sdk-v0.66.1-linux-x64.tar.gz; but using that browser engine (again renaming nw to Janosik 1 ver1.6 and copying package.nw from the released game) is also working fine for me.

[smcv]

I've received a key for Crocotile 3D from @prominentdetail and it seems to start up fine on Steam Linux Runtime under Ubuntu 22.04. I'll see if my colleague can reproduce the issue on a Deck.

[smcv]

I'll see if my colleague can reproduce the issue on a Deck.

It seems to be working fine on Deck too. My colleague reports that it starts up fine, and runs in Steam Linux Runtime by default. (Again, this is SteamOS BUILD_ID=20230313.1, VERSION_ID=3.4.6 with Steam client 1679680416.)

@prominentdetail, if a user of your app is unable to launch it on Deck, some things that could help are:

• make sure that "Steam Linux Runtime" and "Steam Linux Runtime - soldier" are up to date (they both show up in the Steam library as "tools", the same as Proton)
  • doing a "verify integrity" on both might help
• use the latest stable SteamOS update
• use the latest stable Steam Client update

If the user is sufficiently familiar with Linux to be able to access desktop mode and navigate the filesystem, it would be useful to see what they have in ~/.local/share/steamapps/common/SteamLinuxRuntime/VERSIONS.txt (should say depot 0.20230405.0 or newer) and ~/.local/share/steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt (should say depot 0.20230405.47174 or newer, this is the one that's important for #579 being fixed).

If they can get a log that would be even better.

I also opened a support ticket with valve in the past and an employee told me they get an error: " libnw.so: undefined symbol: cupsEnumDests "

That symptom matches #579, which should no longer be a problem since 2 days ago.

[smcv]

[edited previous comment to add some debugging steps if your user is sufficiently familiar with Linux]

[prominentdetail]

Thanks for the help! I'm waiting to hear back from a user about whether they can get it to work or not given the new information. I'll let you know when I hear from them.

[smcv]

I'm waiting to hear back from a user about whether they can get it to work or not given the new information. I'll let you know when I hear from them.

Is there any more recent feedback, or can we assume that this was a duplicate of #579 and therefore fixed now?

[prominentdetail]

I never heard back from the user. However, I did resubmit my app to be tested on steamdeck, and valve said it launched fine.
So it seems like it is fixed.
Though since my app is a software and not a game, they can't list my app as supported on steamdeck :\

[smcv]

Thanks, I think this is a duplicate of #579 then. Please could you or @kisak-valve close it?