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

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.

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

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.

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.

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.

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.

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?

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 :(

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.

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.

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.

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.

Try using multi arch to install those packages

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

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

@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)

@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

👍

Open up the steam link, @Valve

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

@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.

Wine is being ported

that is not how it works, it still requires x86

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.

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.

Can't you compile the runtime from their GitHub page?

On Tue, Sep 12, 2017, 10:22 AM MichaelMackus [email protected]
wrote:

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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-328905677,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEXd3P-7U_2udO8CaOzvimk0jcQ7pNcks5shq-rgaJpZM4GNad4
.

I guess they have this, so perhaps it is possible to compile natively for another ARM device. I believe they are using a modified Linux kernel, though.

They've only published an SDK for making software that runs on top of the Steam Link, not anything for the Steam Link's OS itself.

I was talking about the runtime
https://github.com/ValveSoftware/steam-runtime

On Wed, Sep 13, 2017 at 11:03 AM Aaron Franke [email protected]
wrote:

They've only published an SDK for making software that runs on top of the
Steam Link, not anything for the Steam Link's OS itself.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-329232781,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEXd3vAvBuz4xLTCfkSnlDRcA0wf5m_ks5siArUgaJpZM4GNad4
.

One year ago I wrote a request about Steam client for GNU/Linux on ARM. @w23 said about a slow system bus of Raspberry Pi. So it's impossible to make this PC as the main platform for ARM.

A RPi is slow indeed. But I have exynos 4,5, 7 and soon 8, next to some
tegra. All with full featured gles, and H264 hardware video decoding. In
essence all of my (desktop) systems are faster than the link.
I also have a GPD Win, which is terribly slow (intel z8750, which feels
like an exynos 4 in performance, but burns like an i3 on full power). But
it is intel so it can run the steam client, and stream from my steam
machine, more or less.
But I want to have the desktop streaming like the link on my arm, or any
platform of my choosing.

Anyway: there might be a good reason for them to keep this proprietary: I
can stream all movies and netflix and stuff from my steam machine to the
steam link. This is only allowed if the steam link respects the DRM.

Hey guys! If you're somewhat tech savvy and still looking for something to stream Steam games to the RPI without a Link, try Parsec. It's doesn't care whether you have an AMD or Nvidia card, and its free. The RPI Parsec port is still in beta though and has quite a few bugs but things are coming along pretty well.

@ardje The pi 2 and 3 may be slow by the unfair comparisons placed against it, but it is actually faster than the Singe core CPU in the steamlink itself. It also has Hardware H264 decode built on to the chip (Neon) and a lot of people in this thread are overlooking this. Projects like the moonlight-embedded have taken full advantage of this capability with much success. Porting the stream client over from the Steamlink to the pi for example is only hard due to the unpublished source, library conflicts and lack of interest due to reasons and misconceptions mentioned above, but when you actually compare the two devices side by side, they share the same core architecture. (The steamlink uses a Marvell DE3005-A1 CPU)

I'd love to be able to stream games from my windows desktop to my raspberry pi since I also use it for kodi and would hate to run a HDMI cable from another room to the living. If I'd be able to buy linux titles for ARM as well that'd totally be awesome.

Yea, the rpi (especially newer 2 & 3 versions) are very powerful for a SBC. It can run almost all n64 games (well, those that run in an emulator, at least - it's definitely a strange architecture). Also, PS1 games, and of course all the old SNES/Genesis (emulatable) games.

Also, don't just limit the discussion to the Raspberry Pi - that does ARM a huge disservice. There are already more powerful ARM chips out there capable of more processing power. Not to mention all the FOSS support for ARM atm since x86 is largely out of the picture.

Thanks @googleygoggles - I've been looking for something like that!

EDIT: Unfortunately, looks like only Rpi3 download is available. I'm not even sure if it is OSS, but if so theoretically it could compile on other platforms... Might be easier to just use X11 forwarding at that point, though.

I have a CS 1.6 server currently running on a Raspberry Pi with AMX mod installed, using this :

https://eltechs.com/product/exagear-desktop/

It will cost about 30$ and it gives you 2 licenses. Runs quite well.

For those still interested, there is now a Steam Link app for the RPi, currently in beta: https://steamcommunity.com/app/353380/discussions/0/1743353164093954254/

I would suggest closing this bug as won't fix, since I don't think anyone educated about the issue of binary (in)compatibility between architectures sees a point in this endeavour.

(No, having the Steam client on ARM would not automatically let you play any game. If that's what you wanted, you can stop asking.)

(Seriously, it's like you're asking for NASA to go get a slab of rock from the moon so you can stand on it and experience low gravity — you're asking for someone else to do something very hard and expensive based on a fundamental misunderstanding of how things work.)

I am in agreement with the last comment, a steam link client is now available which will allow you to do a decent job of gaming through the pi in a way that is practical and fully compatible. While exagear does a good job of running older x86 windows games on a pi with good binary translation, you are still limited by the power of the pi cpu and fairly basic GPU. Asking it to run more demanding games even if they were native just isn't possible. Streaming from a PC is just the better way to go, and with the aforementioned steam link package release now out from valve, this issue is technically solved.

As an exercise, I decided to try rewriting the comment from joaormatos without being condescending.

"For those interested in an alternative to native ARM, there is now a Steam Link app for the RPi, currently in beta: https://steamcommunity.com/app/353380/discussions/0/1743353164093954254/

I would suggest closing this bug as won't fix, since there is an alternative."

Wow, that was a lot easier than I thought it would be!

As an exercise, I decided to try rewriting the comment from joaormatos without being condescending.

"For those interested in an alternative to native ARM, there is now a Steam Link app for the RPi, currently in beta: https://steamcommunity.com/app/353380/discussions/0/1743353164093954254/

I would suggest closing this bug as won't fix, since there is an alternative."

Wow, that was a lot easier than I thought it would be!

Your neutered version fails to capture the fact that the Steam Link app is not an alternative that satisfies the desires of the people who wanted Steam on ARM so they could run their library of x86 games on ARM devices.
It only satisfies those who wanted an ARM Steam client so they could use the RPi as an in-home streaming client.

My intent was not to be condescending, but to help some people realize that what they were asking is fundamentally impossible in practice and not just a matter of nobody being willing to "put in the work."

Regardless of what you claim your intent was, your result was condescension. "Help some people realize" is a pretty fine definition of condescension that a person who was being condescending would write. In fact your hyperbolic NASA example is the equivalent of saying "You're so ignorant you don't even understand how gravity works" and then you just outright tell people they have no "real" understanding and that they aren't educated. Maybe go back and really carefully re-read what you wrote?

calm the heck down, if you want to use steam just use qemu ;)

On Fri, Dec 14, 2018 at 10:30 PM Mike Caprio [email protected]
wrote:

Regardless of what you claim your intent was, your result was
condescension. "Help some people realize" is a pretty fine definition of
condescension that a person who was being condescending would write. In
fact your hyperbolic NASA example is the equivalent of saying "You're so
ignorant you don't even understand how gravity works" and then you just
outright tell people they have no "real" understanding and that they aren't
educated. Maybe go back and really carefully re-read what you wrote?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-447539079,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEXd3XWGlMJu6f8aKuhZ8ZpJK9we0XDks5u5IjggaJpZM4GNad4
.

Steam on Switch Linux when? XD

I'd very much like if some of the first half-life games and possibly Half-Life 2 could be ported to ARM. Given that Apple is Officially migrating to ARM it's going to be required if Valve and Steam wish to continue providing games on MacOS in the future. The added benefit would be that steam could quite easily share some of their games on Android as well as Raspberry Pi 4.

Hopefully work on this can begin soon, otherwise anyone buying the new Apple Silicon Macs will be out of luck.

In case anyone missed latest news (besides Apple) here is short recap:

1. Hardware

On Windows side there is Snapdragon-based laptops with Core i5 level of performance for native (aarch64) binaries, such as Lenovo Flex 5G and Microsoft Surface Pro X, and soon there also will be Exynos-based laptops with GPU based on Radeon RDNA architecture.

On Linux side there is wide range of hardware from cheap, but quite performant for it's price, devices such as ODROID-N2+ and Pinebook Pro, to powerful workstations that support dedicated GPU, such as SolidRun HoneyComb LX2K and Ampere eMAG Workstation.

So, unlike MacOS, Linux and Windows already have consumer ARM hardware available, today.

1. Emulation

In case of MacOS emulation performance allow to play AAA games.
In case of Windows for now there is only i386 emulation (no amd64 support) but it also works quite well.
In case of Linux there is box86 which could be integrated into Steam Proton. Also, some sort of wrapper that would allow to call for aarch64 libraries of Steam Runtime from x86 games binaries most likely will improve performance even while x86 game will have to be emulated on qemu. This is why I would like to see Steam for Linux to be ported to ARM - because better integration of emulation layer into Steam will improve games performance. I guess this is exactly the reason why we see x86 builds of Asphalt 9 and Shadow of Tomb Raider running on ARM without noticeable slowdown.

Another interesting idea is to provide publishers set of tools that would allow conversion of x86 binaries to aarch64 binaries, based on this software. In this case emulation will be not involved at all and games will run on aarch64 at native speed.

Another interesting idea is to provide publishers set of tools that would allow conversion of x86 binaries to aarch64 binaries, based on this software. In this case emulation will be not involved at all and games will run on aarch64 at native speed.

Theres no need for conversion since Rosetta 2 is already performant enough and Rosetta 2 already converts the x86 binary when the application boots up. Apples strange obsession with Metal also prevents MacOs from playing AAA games as they no longer support the newest versions of OpenGL and probably arent going to allow Vulkan apps. The Asphalt 9 and Shadow of the Tomb Raider games that are released on MacOS use Metal, and thus a different build all together.

Although it would be nice to have a native arm64 version of Steam and libsteam_api, getting said version wouldnt be as simple as a ,well, simple conversion. I'm sure Valve is making use of some embedded x86 assembly to speed things up that we dont know about or their build process needs x86 at some point. We are also talking about massive code bases here...

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

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.

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 :)

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.

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.

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.

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

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.

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.

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?).

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

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

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-1677634139

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) ?

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.

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.

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.

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

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

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.

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

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

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

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

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

It looks like box64 is adding support for 32 bit Linux programs so in the near future you should be able to run steam thru it with no issues. The only problem would be proton not using the new wow64 mode yet. Box64 also got avx support recently so some newer games that require it should be able to run.

I would like to run the SteamLink client on a MiSTer.

Isn't ARM support way overdue in 2025?

@crion66 Yes, but Valve is very slow to adopt new standards. There still isn't even a 64-bit Steam client for Windows/Linux.

Real Mac support would be appreciated

https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-2322721657

@m1m1k4tz, via box64 isn't possible on OS-replaced AOSP-by-default tablets and smartphones, because box64 doesn't compile on musl, per https://github.com/ptitSeb/box64/issues/2012#issue-2646073845, yet PMOS is the sole alternative where device trees must be utilised in the stead of absent [U]EFI implementations. ^1

  [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17353#note_524486:~:text=this%20would%20ship%20with%20Box64&text=However%2C%20it%20seems%20like%20Box64%20currently%20can't%20be%20built%20on%20musl.

https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-147535925

@gdrewb-valve, hopefully, that answers your question.

you can very easily spin up a glibc environment through distrobox for example on musl libc distributions, that complicates the setup but it's doable and even documented if you click through the links on https://wiki.postmarketos.org/wiki/Steam.

UEFI and devicetrees can also be combined which is the case on the 2024 Qualcomm Snapdragon X Elite ARM64 laptops when booting any non-Windows OS including Linux due to some unfortunate omissions from the ACPI tables provided as Windows-only PEP drivers, regardless not sure why that was mentioned since it's really meaningless for userspace.

Given recent announcements, what's the future of this 10 year old issue request? It seems that Steam on ARM64 is actually officially implemented and is coming with X86 to ARM translation baked in now with FEX?

Given recent announcements, what's the future of this 10 year old issue request? It seems that Steam on ARM64 is actually officially implemented and is coming with X86 to ARM translation baked in now with FEX?

You mean x86 to arm? I assumed so and just made a docker base image for FEX. It works well. I tried a HLDS server and it works fine so far.

https://github.com/stevenlafl/fex-docker
https://hub.docker.com/r/stevenlafl/fex

And here I was hoping we would get the Steam Client and the Steam Linux Runtime built for ARM64, natively 😔

And here I was hoping we would get the Steam Client and the Steam Linux Runtime built for ARM64, natively 😔

That would be nice for dgx spark.
Anyways, is coming surely due that stream vr comes with qualcomm

steam frame will be using FEX to realtime dynamic recompile (dynarec) run the x86_64 version of steam on aarch64 arm64

box64/FEX do work very well

until steam can run x86/x64 games through a container recompiler (FEX) while running steam natively as aarch64/arm64

these are the two ways to do this currently.

1. run steam x86_64 with all subprocesses under FEX on aarch64
2. run steam as aarch64 and all subprocess games/packages with FEX

the last least likely to occur:
3) require games to be released natively as aarch64

which #3 could be a useful benefit for newer games, it is unlikely to be the case for 10+ 30+ year old games.

Hey everyone, good news ✨️.

We finally have an official installation of Steam on arm that also runs non arm games.

To install just run

sudo snap install --candidate steam

It's there a arm64 steam client lib? That's what I really need right now.

On Sun, Jan 18, 2026, 5:17 AM Guy Luz @.***> wrote:

guyluz11 left a comment (ValveSoftware/steam-for-linux#4061)
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-3765230667

Hey everyone, good news ✨️.

We finally have an official installation of Steam on arm that also runs
non arm games.

To install just run

sudo snap install --candidate steam

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-3765230667,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATL4VGIZX5HD44OA7TBZSD4HN2UNAVCNFSM4BRVU54KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TGNZWGUZDGMBWGY3Q
.
You are receiving this because you commented.Message ID:
@.***>

We finally have an official installation of Steam on arm that also runs non arm games.

To install just run

sudo snap install --candidate steam

A couple of important things to note here:

1. Even though the Snap is "verified" it is maintained by Canonical, not Valve.
2. The client itself is still x86, the Snap just bundles Fex to run it.

It's there a arm64 steam client lib? That's what I really need right now.
…

From https://discourse.ubuntu.com/t/call-for-testing-steam-snap-for-arm64/74719:

Since the Steam client for Linux is currently only available for amd64, we’ve bundled amd64 Steam along with FEX in our arm64 snap, which is used to emulate amd64 for Steam.

Whatever. I'll shim it by specifically running the ELF binary and nothing
else through x86 emulator just to spite these *people.

On Sun, Jan 18, 2026, 6:39 AM Samq64 @.***> wrote:

Samq64 left a comment (ValveSoftware/steam-for-linux#4061)
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-3765301883

From
https://discourse.ubuntu.com/t/call-for-testing-steam-snap-for-arm64/74719
:

Since the Steam client for Linux is currently only available for amd64,
we’ve bundled amd64 Steam along with FEX https://github.com/FEX-Emu/FEX
in our arm64 snap, which is used to emulate amd64 for Steam.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/4061#issuecomment-3765301883,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATL4VHEZODL7ZKM3LLTQVD4HOEKZAVCNFSM4BRVU54KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TGNZWGUZTAMJYHAZQ
.
You are receiving this because you commented.Message ID:
@.***>

Whatever. I'll shim it by specifically running the ELF binary and nothing
else through x86 emulator just to spite these incompetent people.
…

Imagine calling developers incompetent just because they don't have time to implement a feature YOU request and rather invest their time into features and fixes they find more important.

Though a world where no code is proprietary and everything is open source so that anyone can contribute would be nice. In such world, there would be no excuse to blame devs for not making a requested feature since anyone could do it themselves.

We finally have an official installation of Steam on arm that also runs non arm games.
To install just run
sudo snap install --candidate steam

A couple of important things to note here:

1. Even though the Snap is "verified" it is maintained by Canonical, not Valve.
2. The client itself is still x86, the Snap just bundles Fex to run it.

What a bucket of cold water 😅. I was hoping for an ARM64 client and client lib.
And that on Windows too ;-)
Or open source Dota 2 🤣 so I can build an ARM64EC binary.

so... technically its not arm64
its x86_64 with FEX running steam.

"it works" but its not the actual native arm64 solution

and i'd tend to agree
just run steam x86_64/amd64 yourself using FEX/box64 on your system.

calling the snap package "official" is a misnomer also
its only official by canonical/ubuntu
its not a steam valve official release.

Here's my adventure with steam on arm64 https://github.com/CypherpunkArmory/UserLAnd/issues/1000#issuecomment-4123363295

In short, must have newish Linux kernel to run FEX. On Mobile, Android, newish phones might not ship meeting the requirements for FEX. 🙁 Maybe something ultra super new would work? 🤷‍♂️

Looking further, there are hardware restrictions according to the GitHub documentation.
https://github.com/FEX-Emu/FEX?tab=readme-ov-file#prerequisites

• Hardware must use ARMv8.0+

Ubuntu 22.04 is the oldest Ubuntu version listed as compatible, it has the minimal kernel version needed for FEX (maybe it's the oldest one that meets the requirements 🤷‍♂️). You can see the kernel version listed on he release notes.
https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668

In my example, linked comment, the phone has a snapdragon 6 gen 1 and the instruction set is arm8 from my understanding currently...
https://www.pcmag.com/reviews/t-mobile-revvl-7-pro-5g
https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_systems_on_chips

french accent: 11 years later.
I Still get emails from this issue and it's still open which I personally find nuts, at this point is it eligible for the worlds longest unresolved GitHub issue with active comments?

https://interfacinglinux.com/community/sbcsoftware/native-steam-client-for-arm-linux/

It's happening 👀