can't run on ARM architecture systems

[nebrassy]

after installing steam using gdebi, I open it and it says it needs additional packages, then it gives this error:

" Steam needs to install these additional packages:
libgl1-mesa-dri:i386, libgl1-mesa-glx:i386, libc6:i386
.................................
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libgl1-mesa-dri
E: Unable to locate package libgl1-mesa-glx
E: Unable to locate package libc6
Press return to continue: "

then this error:

" You are missing the following 32-bit libraries, and Steam may not run:
libc.so.6 "

all libraries mentioned are available for ARM systems, please help and reply soon.

[gdrewb-valve]

Steam is x86 only, what are you trying to run on ARM?

[nebrassy]

that's the problem, Valve should make an ARM version of Steam, not necessarily games, maybe just streaming and using the community.

[gdrewb-valve]

Changing to a feature request.

[MrSchism]

I had suggested an in-home streaming client that's ARM compatible in order to play the games without having to say "Steam for Linux (x86+ARM)" and hoping that devs port to Steam for ARM (quite some time ago). Not sure where it went; got buried.

As for messenger/community, that's already built into the website. Streaming is the only part that isn't.

[gdrewb-valve]

You'll soon be able to buy a Steam Link, which is a $50 streaming device. :-)

[MrSchism]

Exactly. That's probably why my suggestion was closed all that time ago.

[nebrassy]

well, since valve took it up to porting all their games from windows to linux, I guess they can port them to ARM too, I mean, Imagine installing linux on your android phone, installing steam on it and play valve games, it would be amazing, I already tried that when I had an x86 architecture phone.

[MrSchism]

As a person who ports software and isn't afraid of ARM, I'd happily port... but ARM comes with it's own sets of standards that are NOT user friendly. For Valve (and developers), one would have to really just focus on one ARM EABI instead of trying support Vector Floating Point, Soft Float, and Hard Float (which is the de-facto current standard). This isn't as simple as making a .deb and a .rpm. We're talking something that can affect an insane amount of change.

So you'd have to have Steam list WIN, MAC, SteamOS(x86_64, ARM[hf, 64]). That's not going to work.

Honestly, the best solution would be:

• Making the mobile Steam app available to non-Android systems (just making a .tar.gz with the appropriate ELFs should work)
• Making a Streaming app or perhaps a plugin (even paid to mitigate competition against the Steam Links)

That would give full functionality without porting the games (which is up to the individual developer). On an aside, someone actually somewhat ported the old source engine to ARM, but it performed sub-optimally. There's a library software being developed to unify shops and libraries for both DRM- (Steam, et al) and DRM-Free-titles. It's open source and could potentially work on ARM (but it's not even in Alpha yet). That won't work for allowing access to Steam gaming servers or achievements, but it will give you access to a library.

[nebrassy]

I know that games on ARM will never work as smotth as if it were on x86 or x64, but maybe just old games like counter-strike , half-life and team fortress classic would work pretty good if ported to ARM, ofcourse they will need to port steam first.

[MrSchism]

Actually, Steam doesn't need to be ported... And they don't run very well.

You can find one guy's attempt at porting the 2013 sdk here: https://github.com/aunali1/source-sdk-2013-arm

For older engines, Google around. It's not an ideal situation.

[Foxhunt]

I'm a big fan of the steam client on arm idea. Been holding my eyes open for that feature since the first steamos announcement. Having a raspberry pi flying around and converting it into a Steam Link would be nice.

Is there any official word out there why this has not happened yet?

Is it for business reasons? Not cutting into the own Steam Link flesh?
Or are there no concerns on that side but on the development front for the reasons listed by MrSchim?
Or is it even being considered but not yet publicly discussed?

[lellis2k]

So is it not physically possible to install the steam client on a Raspberry Pi until/unless Steam release a different version?

I really want to set up streaming from my PC to my pi, it's simple with nVidia but seems impossible with an ATI card :(

[VelorumS]

It seems that with Vulkan and GNU/Linux ARM devices it's reasonable to give the ARM option to the game developers. Browsing community/store on a tablet (since the multiple login is working for that, as far as I know) would be nice too.

There is no big difference for a well-written cross-platform code whether it's GNU/Linux ARM or x86. And Vulkan fills the GPU gap.

[ronlaws86]

I use the nvidia/moonlight solution right now which does work very well, though it has a tendency of getting broken because nvidia keep changing the protocols in Geforce Experience, and force updates. I'd really like to move to an AMD card some time, as i've grown tired of nVidia's BS, but sadly until a viable software solution that is competitive and hardware-agnostic, i'm really forced to use nVidia and duck the updates.

On a side note, a steam link is a cool thing, but i just spend less than that on a Pi3 which runs Emulation station/retropie. I'm really not interested in yet another micro-box to take up the only remaining HDMI port on my TV that can only be used for steam.

[NullMember]

i think it's already ported (steam link) but valve need to sell steam link devices. Raspberry pi cheaper than steam link and multi-functional. If steam release this thing nobody buy steam link devices.

[ronlaws86]

There is a Steamlink Dev kit that you can download, and looking at the spec of the Steamlink it actually runs the the same GCC version as the rasbian distribution for the Pi2/3 the processor arch is also the same A7 instruction set as the Pi2 (including neon support), though it is clocked in at 1000Mhz, the Pi2 can be overclocked to this speed through the config utility (turbo), the Pi3 is 1.1Ghz at stock, and while it is an Arm A8 (64bit) it is binary compatible with A7, so in theory it should be easy to run at least the steam link binaries on a raspberry pi with little effort. not sure if the SDK includes the binaries for the steam link software itself however. but in theory it is possible.

[PeterHindes]

Try using multi arch to install those packages

[mik3caprio]

The NextThingCo PocketC.H.I.P. is a $49 dollar open and hackable Debian Jessie handheld computer running on a 1GHz R8 ARM processor. I think it would be an excellent platform to port to.

Here's the processor: https://en.wikipedia.org/wiki/ARM_Cortex-A8

Here's all their source: https://github.com/NextThingCo

[mdeguzis]

@NullMember , no, the Link runs a custom software stack, not the Steam Client.

[ronlaws86]

@ProfessorKaos64 What the steamlink runs I think is the core feature most people are after from a ported version to pi, not to run the full desktop version of steam and games locally but to have a way of streaming them from a more hefty X86 based system running the full desktop steam. In most cases asking for games to be ported to the pi is not practical, however a basic front end streaming client (That isn't Moonlight) is well within realms of practicality, the steam-link is essentially what people are after, but on a Pi instead. (or at least a way to run its software stack from rasbian)

[Foxhunt]

@ronlaws86 this is what I'm looking forward for. Hope some one spends his time porting the steam-link-sdk to a rpi. Don't have time to do it my self at the moment.

Not sure if all the necessary components are in the sdk to actually do it. But we'll see.

Edit:

Seems like this wont happen.
link

[MichaelMackus]

👍

Open up the steam link, @Valve

[Zenitur]

Hello Valve! I suggest to make Steam for ARM, with Raspberry Pi as the main platform. I suggest to release it as unofficial version - as a project supported by one developer of Linux- and SteamOS-version of Steam.

Raspberry Pi is a single board computer with the size of palm and costs $25. It's graphics acceletator is weak and it can be compared with a mobile device GPU's. In fact, it's used in mobile devices. Judging by the fact that smartphones and tablet PC's has many games, this GPU has a right to exist. I see RPi as the most popular ARM computer on desktops.

INTRODUCTION

Raspberry Pi developers are making efforts to promote their product. Recently they're perfected the graphical shell by the desktop theme. Now a frumpy LXDE interface become beautiful, while consuming few resources which can be compared with Windows 98.

Also developers have a focus on a schools and on equipment by RPi's instead of PC's: in a "Programming" section in the Main menu of Raspbian OS you can find much of programming languages, designed for learn programming. There is a GPIO connector on the device, you can connect a robot using that and manage him using Python, or something else.

Some time ago in a Chromium browser included in Raspbian was appear hardware decoding of FullHD-video. Also was appear a Flash Player taken from ChromeOS.

I think that's a good idea to help this platform presenting them games.

HOW AM I SEE IT

Steam client built for two processor architectures: armv7hf and armv8hf 64-bit. No Steam Runtime cause by the hard requirement: build platform is Raspbian 1.0, not 2.0 and not any other distribution, otherwise it will not be taken in Steam library. Steam Runtime has a right to exist as a 20 MiB, not 1 GiB. It can include only SDL and OpenAL.

Such Steam client can works not only on Raspberry Pi, but on ather armv7hf devices, like Orange Pi and NVIDIA Jetson TK1. The only requirement is GNU/Linux with X11, not Android (like Toshiba AC 100) or ChromeOS.

OpenGL? Once I met a problem when install Quake3 from Raspbian repository (Raspbian is a Debian repo plus small additional repo). It's using OpenGL, however Raspberry Pi hasn't support hardware acceleration for it, having only OpenGL ES support. I had to visit an official Github repository of Raspberry Pi, when download Quake3 patched for OpenGL ES support.

So I suggest to make compulsory to use OpenGL ES in games, but OpenGL can be an option (for devices like Jetson TK1). If the game uses only OpenGL (not ES), it will not be taken in Steam library, though it was build for armv7hf.

Next, what API is necessary for hardware decoding video in games? OpenMAX, because it is in Raspberry Pi.

And the final: GLX or EGL? EGL.

WHAT GAMES WILL BE IN THE START OF STEAM FOR ARM?

No one. Source engine is using Direct3D, and OpenGL is obtaining by the translator. Cause by this, a weak GPU can't cope the load to show big FPS. Source 2 is support native OpenGL, but the games are too modern for weak GPU. There are only first Valve games: Half Life, Counter Strike and Team Fortress, that uses OpenGL not Direct3D.

I suggest to take in Steam library only those games, that are present in a Windows, macOS or Linux library. Otherwise there will be thousand games were ported from mobile devices, as it was in OUYA game console.

TEHINCAL DETAILS FOR DEVELOPERS

When Steam for Linux just started to develop, there was Ubuntu 12.04 base. No Steam Runtime in planes: it was planned that every game developer will compile it exactly in Ubuntu 12.04. If the game needs nonstandard dependency (like a SpaceChem game) Steam shows a window "You need to install Mono package to play this game. Press OK and type an administrator password to install it".

Now we knows, the plan was changed when Ubuntu 12.10 released. Was revealed that sometimes system libraries drops ABI. A shining example is libICU. In an Ubuntu practice old ABI libraries are exposed to delete. Thus, Ubuntu distribution does not provide full backwards compatibility with it's old versions. From the Linux distributions I can stand out RHEL as a one of the few that provides backwards compatibility (if follow the conditions described in the LSB document).

This is the reason why the Steam Runtime was created. Now you can compile your game in Ubuntu 12.04 then run in any other Linux distribution, starting from Ubuntu 15.10 ending on Slackware. Some developers have gone further, and did not even bother to prepare a build-farm based on Ubuntu 12.04, and compile software directly in the system, which is installed on their computer! Steam Runtime is allowing them to relax, cause it has a collection of 1 GiB of system libraries for all occasions.

I suggest to prevent this problem in the Steam for ARM. The support of the big Steam Runtime costs a big time and money. If do from scratch, it's enough to make build farm based on Raspbian 1.0 as a hard requirement. If the command "strings appname | grep LIB" shows that the game need GLIBC > 2.14 then it will not be taken on Steam library.

What about a library dependencies? A lot of of games depends of libGLES, SDL and OpenAL. But there are exceptions. I suggest to put all libraries in the game distributions, except of GNU stack[1], X11 stack, GTK, Cairo, Freetype, libasound2[2] and OpenSSL 1.0. There is the LSB 5.0[1] standard that originally written for RHEL but Debian is also complies it.

What if the developer needs fresh GCC, not the version from Raspbian 1.0? For this case Valve needs to prepare a packages with them. I suggest to look on Devtoolset[4]. The maintainers of the GCC were somewise made the magical build. In the CentOS build farm, I've build with GCC 4.8, but the linking with the C++ Runtime (libstdc++.so.6) carried with an old one! And it works!

Also a game developer need to write in the system requirements the minimal version of Raspberry Pi to run.

[1] http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/requirements.html#RLIBRARIES
[2] http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Desktop-generic/LSB-Desktop-generic/requirements.html#RLIBRARIES
[3]: http://refspecs.linuxfoundation.org/lsb.shtml

[aaronfranke]

@nebrassy "Imagine installing linux on your android phone, installing steam on it and play valve games, it would be amazing"

Well, you'll be able to run Steam and old games on Android soon now that Wine is being ported to Android! Give it a few years, it's currently early development.

[nicman23]

Wine is being ported

that is not how it works, it still requires x86

[avatar21]

I'm surprised that Steam don't bother supporting ARM devices till this far, it's definitely worth the effort, because by end of the day, ARM Linux might get better drivers compatibility (graphic, sound especially) ... which turn out to be more affordable and smother gaming experience. Not to mention the possibility of platform options we have when we supporting ARM.

[MichaelMackus]

I'd love for them to just release the live-streaming (guest) part for ARM. They already have it working for the Steam link.

Maybe even just a way to add games to the ARM library so you could play some (i.e. Nethack or DOOM) that compile on ARM.

[arrowgent]

ive used https://github.com/ptitSeb/box86 to install steam on raspberry pi 4
never played any games through the library, just tested that everything is working

which it doesnt, you can only use your library
no browsing, no friends, no activity, no profile etc.

box86 is good progress, but it would be better to compile a steam_armhf
let users figure out how to get box86 as a compatiblitytool for all linux games using proton

too much work im sure, steam uses far too many native x86 libraries in its bootloader runtime packages

[Xeddius]

which it doesn't, you can only use your library
no browsing, no friends, no activity, no profile etc.

This is because Steam uses an x64 based chromium engine for rendering most of the interface/browser. Box86 is x86 only. (32-bit) great for vintage games, not so much for anything modern.

[geerlingguy]

With the prevalence of more powerful ARM desktops and laptops, and even a slow buildup of Pis and other SBCs becoming fast enough to emulate a few-generations-ago game here and there... it would be neat to see Steam on ARM64, even if no games yet support the arch.

"If you build it, they will come" and all that.
And honestly, I just want to be able to play a couple of my early-00s games in my Steam library on a non-X86 PC :)

[ell1e]

I think some indie devs may also be interested in testing out ARM64 ports if steam is there for getting it to the users, if only to have a dedicated niche audience of buyers when nobody else bothers yet. Even if steam doesn't bother to include Proton or x86 emulation layers. So I'm sure some things would be available if just the client & store (since it'd need a separate SteamOS/Linux ARM64 platform in the store) moved there. The Raspberry Pi 4 is available with active cooling and heat sinks from third parties, a vulkan driver, and 8GB RAM, it surely would run a lot of 2D indie games. Same for Pinebook Pro.

[Heasterian]

Looks like atm box86 and box64 have working small mode, but all parts with new design are not working. Proton is beginning to work with builds from Proton GE (last working for me is 5.9 build). DXVK works with last versions of box86/64, but it's unstable and dependent on GPU drivers (ie Crysis 32-bit fails on Freedreno and works on Radeon Mesa driver, 64-bit works with Freedreno and fails on Radeon).

With steamcmd you can use many functions missing in normal client.

Also older Source games works well on my Poco F1 running mobian. Portal 2 with low setting 720p@30 fps consumes ~12-15% of battery per hour.

[ronlaws86]

been watching this issue for years and while at first it seemed kinda pointless for the most part, there's going to be more ARM powered general purpose consumer laptops and desktops in the coming years thanks in no small part to Apple and Microsoft, so this is kind of a big deal now.

[leetfin]

+1 to this, would love to see client ARM/Aarch64 support.

[RussianNeuroMancer]

There is wide range of ARM Chromebooks. Since Intel Chromebook will be supported soon - expending to ARM is now will cover only M1-based Macs and GNU/Linux running on ARM, but also ChromeOS running on ARM too. I am not even mention that ARM-based Windows laptops is released for three years already.

[jondycz]

Honestly, being able to run steamcmd on ARM servers not only offer better performance per dollar, but also saves the environment as such processors are way more efficient than traditional x86 processors.

[guyluz11]

So here are all the steam on arm people 😂😂

I would like to add several updates why this is the perfect time for you valve to add steam for arm support

1. Proton compatibility layer can in theory work to translate to arm, and StemDeck could benefit from price reduction (arm boards do not require big price cut on boards like Intel require) 💰.
2. New Mac m1+ chips are arm based and Linux can run on it (thanks Asahi Linux), so you already have strong and common platform to develop and test on 👾 (also probably more users in the future).
3. Plasma mobile (Kde on phone) can run Linux arm apps and it would be awesome to download steam arm snap from the store on the phone and play games on connected tv 🤯 (steam as store for mobile games anymore?).

[Thesola10]

With the announcement of Qualcomm's Oryon, ARM is looking increasingly like the future of computing, and Valve shipping Box86 and Box64 with Steam's default runtime on Linux would instantly propel it as the gaming platform of choice on what's essentially the next generation of computers

[ronlaws86]

I've been subbed to this thread for years now. At first it seemed like an ARM build would be a niche thing relegated to experimentation and minority cases, however a lot has changed in 8 years and ARM/RISC may well be the future architecture of computing for larger reasons like the performance per watt and the whole global effort to reduce power demands while maintaining performance, Longer battery life for portables etc.

ARM/RISC based systems are at the stage now where the Pentium MMX was for the x86 back in the early 90s when the desktop PC market was beginning to converge more seriously on to the IBM PC Compatibles in a really big way and it was becoming the architecture of choice. It may not yet quite be on par with current X86 systems, but it is getting very close; It is only a matter of time before it becomes the main player in the market, I think it's time to re-evaluate software design decisions and begin factoring in this architecture shift towards ARM/RISC based desktop systems more widely as the industry undergoes another shift, as it has done so in the past.

Don't get me wrong, X86 is probably going to be around for another 10 years more or less, but it will soon become a legacy architecture just like the 6502 and Z80 did which was the mainstay from the 80s computer market in its time before intel's 8x86 took over, just like ARM/RISC is starting to now. I think it's wise to use that transition time to really begin developing and maturing a proper solution.

ARM Native builds of the client would be the best step forward, legacy x86 application support can be provided by box86 and box64 and wrapped in to the steam runtime, like many have already mentioned, chip makers are already factoring in x86 emulation in to the design of their silicon with accelerator cores to better handle the workload of emulation.

All it would take is for these emulators (or a fork of them) to provide Vulkan pass-through to really seal it in and make Box# + Proton the killer runtime stack for Steam on ARM/RISC

[stevenlafl]

Replying to #4061 (comment)

That's what's so baffling. They've already done the work to make aarch64 compatible libs to run Mac (proprietary dylib), yet they don't offer compiled aarch64 linux binaries (so). Why? Is there some way that makes porting to aarch64 arm chips (mac) somehow significantly different than porting for... drum roll please... aarch64 arm chips (everyone else) ?

[MissPotato]

I would also like to add that there are already game servers that support ARM, like Terraria, available on steam. A lot of the time the issue with getting these games to run is SteamCMD itself. Again going back to Terraria when I was trying to host a tModloader server a year back, everything worked until tModloader tried to do anything steamAPI related. AFAIK this has been addressed in the rewrite of tModloader by them adding an no-steam toggle but I digress.

Really, I'm just adding my name to the list of supporters for this.

[neofeo]

I successfully ran several Steam games on ARM Linux utilizing Goldberg. Why Goldberg, you ask? Well, the Steam client introduces an additional overhead—not a major one in emulation, but the RAM usage is staggering. Unfortunately, you can't disable the web helper and are forced to emulate it. Having a Steam client for ARM with the Steam x86_64 libs (or better, also native libs) would significantly enhance game performance, especially when paired with box64 (or box86) if such an option existed. On the flip side, we desperately need a client with the disable browser environment variable reinstated.

This opens up a new frontier for Valve! Imagine Valve pioneering ARM64 SteamOS handhelds capable of flawlessly running x86_64 games with box64. The development cost seems reasonable—it's a solid bet. @gdrewb-valve @cboyd-valve, what are your thoughts?

Links:

box64
box86
ptitseb box86 steam script
pi apps (Raspberry Pi) Steam script with box86
This demo was conducted on low-end hardware, specifically the Pinebook Pro RK3399. Thanks to the latest Mesa Panfrost features (not used on this video), the performance has significantly improved. Check out the video demo here.

[Coll147]

If Steam launches to support ARM devices, it could be a pioneer in this sector, since there are no game launchers/stores for this architecture, which is increasingly being used in microcomputers (Raspberry Pi, Orange Pi), consoles (Nintendo Switch, AYN Odin 2), and some computers / laptops.
These are already reaching a level of power that if Valve released a Steam build for ARM they could run some games thanks to the x64 emulation of some systems such as Windows or Linux (with box64).
And some will say, why not also emulate Steam. Without further ado, Steam consumes a lot of resources in itself. And you also emulate it, because in the end you are left with Steam barely running to start playing. But if Valve gave even minimal support to ARM, things could change a lot. Things may change due to M1 Macs, etc. that use ARM. But we can only wait and see if our requests are heard.

[stevenlafl]

Things may change due to M1 Macs, etc. that use ARM. But we can only wait and see if our requests are heard.

Unfortunately, Valve has decided to make a special carveout for M1 dylibs but these are not compatible with linux. So, they likely already have the code changes necessary to work with ARM64 architecture, they are just intentionally not exporting linux libs.

I have an ARM64 reHLDS build of the Source engine that I can't test because it requires the steam client.

Source: https://steamcommunity.com/groups/steamworks/announcements/detail/2984186817523157399

[avatar21]

No close this please Valve, I beg you, because PlayTronOS is coming, and it will render you irrelevant from the industry!

[neofeo]

No close this please Valve, I beg you, because PlayTronOS is coming, and it will render you irrelevant from the industry!

No one is worried about such anyway.

We need a far more mem efficient client and an arm64 release with box64 and box86. Those are the fastest emulators.

[m1m1k4tz]

It would be cool to have a version of steam that supports games on arm using hangover x86-64 support is in the works as well

[m1m1k4tz]

It’s kinda relevant now that there’s powerful arm handhelds that run Linux other than just the raspberry pi (Asahi Linux)

[Heasterian]

Ayn Odin 2 and Ayn Odin seem more relevant as they have working Vulkan drivers that can run DXVK.

[System64fumo]

Personally i feel like now with the upcoming Qualcomm X Elite based machines getting steam working on ARM would be nice.

[m1m1k4tz]

Until then I’m just gonna use steam thru wine with krun + boxwine once they fix it with wow64