Steam Link app now available for the Linux desktop

Quoting: aokamiI've never had great use on my Steam Link, but that's always nice seeing improvement over there! :)
Despite discontinued is the Steam Link hardware still being updated with latest software updates ?

Steam Link (Hardware) still gets regular updates and keeps adding new controller support. All the latest console controllers have had support added and I think you can even use the Google Stadia controller with it now. I use mine all the time for couch gaming.


Last edited by MagicMyth on 3 March 2021 at 1:48 pm UTC

Good news, at least for those hosting their games on Windows or on linux with an Nvidia GPU. Linuxusers owning an AMD GPU are still out of luck with steam remoteplay because it is still lacking GPU based hardwareencoding for videostreams via VAAPI.


Last edited by ripper81358 on 3 March 2021 at 2:05 pm UTC

Quoting: ripper81358Good news, at least for those hosting their games on Windows or on linux with an Nvidia GPU. Linuxusers owning an AMD GPU are still out of luck with steam remoteplay because it is still lacking GPU based hardwareencoding for videostreams via VAAPI.

Streaming fine from an Ubuntu KVM guest using an AMD graphics card (soft encoding works fine)

Quoting: libgradev

Quoting: ripper81358Good news, at least for those hosting their games on Windows or on linux with an Nvidia GPU. Linuxusers owning an AMD GPU are still out of luck with steam remoteplay because it is still lacking GPU based hardwareencoding for videostreams via VAAPI.

Streaming fine from an Ubuntu KVM guest using an AMD graphics card (soft encoding works fine)

Softwareencoding might work on a system with a more highend CPU and a wired networkconnection. In my case it stopped working in a decent way after switching from Nvidia to AMD. Since remoteplay was never an ideal solution for me because of several games not working correctly i stopped using it. I am connecting my rig directly to my A/V Receiver for now.

Quoting: Hori

Quoting: slaapliedje

Quoting: MayeulCThis is huge, especially the bit about they releasing it on flathub.

I wish they built it for ARM as well, though maybe it is usable in qemu-binfmt? Is it using HW-accelerated decoding with VA-API or similar?

I also wouldn't be surprised if it ends up reverse-engineered.

They've had a Steam Link App for ARM for quite some time.. You can install it within retropie quite easily.

https://www.reddit.com/r/RetroPie/comments/a2va0q/how_to_add_steamlink_to_emulationstation/

Kind of. Technically yes, it's ARM all right, but it only works on a Raspberry Pi.
While the Pi is probably the most widely used ARM device for Linux, this is not always the case. ARM is growing in market share, slowly but surely, and is likely to eventually become the standard on most laptops.

For example, there are ARM laptops such as the Pinebooks, which are Linux-first, as well as the Macbook M1 and some Windows ARM laptops, which you can install Linux on. Steam Link doesn't work on those.

What ties it to the Pi? (asking as I don't know) as it's just an armhf .deb package. I don't know why you couldn't set it up on any debian based distro on something that supports armhf packages.

Quoting: slaapliedjeWhat ties it to the Pi? (asking as I don't know) as it's just an armhf .deb package. I don't know why you couldn't set it up on any debian based distro on something that supports armhf packages.

People tried it before, but it doesn't work. It actually seems to check for some OS specific things and if you spoof these it fails with a very specific issue related to the highly uncommon GPU utilized in the RasberryPI type SBCs.

There is probably some sort of technical reason (likely a short-cut), but with Collaboras support this could definitely be solved I think.

Quoting: ripper81358

Quoting: libgradev

Quoting: ripper81358Good news, at least for those hosting their games on Windows or on linux with an Nvidia GPU. Linuxusers owning an AMD GPU are still out of luck with steam remoteplay because it is still lacking GPU based hardwareencoding for videostreams via VAAPI.

Streaming fine from an Ubuntu KVM guest using an AMD graphics card (soft encoding works fine)

Softwareencoding might work on a system with a more highend CPU and a wired networkconnection. In my case it stopped working in a decent way after switching from Nvidia to AMD. Since remoteplay was never an ideal solution for me because of several games not working correctly i stopped using it. I am connecting my rig directly to my A/V Receiver for now.

You do need more CPU horsepower, yes, but it does work - your post stated it didn't

Quoting: slaapliedjeWhat ties it to the Pi? (asking as I don't know) as it's just an armhf .deb package. I don't know why you couldn't set it up on any debian based distro on something that supports armhf packages.

As far as I understand, it was made directly for the Pi GPU. Not something you can just quickly port over to a different ARM board.

Quoting: libgradev

Quoting: ripper81358

Quoting: libgradev

Quoting: ripper81358Good news, at least for those hosting their games on Windows or on linux with an Nvidia GPU. Linuxusers owning an AMD GPU are still out of luck with steam remoteplay because it is still lacking GPU based hardwareencoding for videostreams via VAAPI.

Streaming fine from an Ubuntu KVM guest using an AMD graphics card (soft encoding works fine)

Softwareencoding might work on a system with a more highend CPU and a wired networkconnection. In my case it stopped working in a decent way after switching from Nvidia to AMD. Since remoteplay was never an ideal solution for me because of several games not working correctly i stopped using it. I am connecting my rig directly to my A/V Receiver for now.

You do need more CPU horsepower, yes, but it does work - your post stated it didn't

Yes it can work but the chance to get it running across different hardwareconfigurations are way more limited with an AMD GPU because of the lack of gpubased videoencoding. So since VAAPI is able to do h264 encoding it should be enabled for steam remoteplay.

Quoting: Liam Dawe

Quoting: slaapliedjeWhat ties it to the Pi? (asking as I don't know) as it's just an armhf .deb package. I don't know why you couldn't set it up on any debian based distro on something that supports armhf packages.

As far as I understand, it was made directly for the Pi GPU. Not something you can just quickly port over to a different ARM board.

Which has always been my problem with ARM platforms. I wasn't awaer of Steam Link's issue with this, but others for sure. Kind of weird they wouldn't just use dynamic libraries though.
But this is why I think ARM is not great for general computing.

https://snapcraft.io/steamlink
There's a snap of it now if anyone is interested

Quoting: Ananace

Quoting: fagnerlnIt's surprisingly that they are using flatpak, they should release Steam officially on flatpak or create a sandbox solution with their Steam Runtime, most of the users of rolling distros are having problems on CSGO because of the new glibc, which not happens with the flatpak version.

Steam has their Pressure Vessel system, called the "Steam Linux Runtime" in Steam itself, which is based on Flatpak - which is also why the Flatpak package of Steam has trouble using it.
They have a public gitlab project for pressure vessel at https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/master/pressure-vessel

And they are also working on improving support of the Flatpak package of Steam;
https://github.com/flatpak/flatpak/issues/3797
https://github.com/flatpak/flatpak/pull/4018
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/203

Sure, but even using the runtime, csgo doesn't work. Looks like it's on a higher level than flatpak. Maybe if the steam itself run under the pressure vessel, would be more interesting.

And pretty nice links, I liked the concept of sandbox in a sandbox

my god it works! I can finally play Gloomhaven and Solastra on linux

Quoting: sgtnasty369my god it works! I can finally play Gloomhaven and Solastra on linux

Pretty sure Gloomhaven already works through Proton?

Quoting: fagnerlnIt's surprisingly that they are using flatpak, they should release Steam officially on flatpak or create a sandbox solution with their Steam Runtime, most of the users of rolling distros are having problems on CSGO because of the new glibc, which not happens with the flatpak version.

Ignoring all of the people in the "I Hate Canonical" camp, a decision by Valve to officially release Steam as a Flatpak could start to sway developers towards Flatpak; given how fragmented the "next-generation package manager" field is at the moment, this would be a good thing.

There's not really all that much difference between most of the "next-generation package managers" (Snap / Flatpak / AppImage / etc...), but there is an awful lot of fragmentation and it is incredibly annoying to either be stuck using many "unofficial" ports if you stick to one particular package manager (e.g. Snap); or maintain a Frankenstein-like system, if you stick to the "official" ports via the bazillion different package managers (i.e. some apps as Snaps, others as Flatpaks, etc).

You're never going to get everyone using the same package manager "officially" - but you could sway most developers towards Flatpak, with a major company like Valve behind it... That in turn would likely lead to less fragmentation, which is a good thing.

Quoting: 3zekielGood new is, they did not use snap package, so everyone can have access to it already, and without all snap issues.

Here we go... And what issues are you talking about? Snap seems to work fine for me.

Stop spreading FUD - Snap and Flatpak are almost on par with each other in most areas, with the only significant difference being that the latter is slightly more "open" (which is a good thing and in my opinion, makes Flatpak the superior option).


Last edited by Cyba.Cowboy on 15 March 2021 at 9:19 pm UTC

Quoting: Cyba.CowboyThere's not really all that much difference between most of the "next-generation package managers" (Snap / Flatpak / AppImage / etc...)

Well there is at least a huge difference between AppImage and the others (AppImage being merely a huge dump of files that are uncompressed at a specific location and run from there).

But overall I don't think the fragmentation is that bad because:
* AppImage is clearly not the way to go and I think most developers knows that
* Snap is basically Ubuntu-only
* Flatpak is cross-distributions

So it's just a matter of time before Flatpak will take the lead. Or, as usual, Canonical will ditch Snap and take Flatpak at some point, like any other in-house tech they've made so far.


Last edited by Creak on 15 March 2021 at 11:47 pm UTC

Quoting: CreakWell there is at least a huge difference between AppImage and the others (AppImage being merely a huge dump of files that are uncompressed at a specific location and run there).

Meh.

I meant similar in the sense that AppImage loosely has similar goals... There are of course, some obvious differences (such as the fact that it doesn't usually provide libraries, it's not isolated, etc...); but the general idea is the same.

It is quite clearly the "most" different of the three, though...

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Snap is basically Ubuntu-only

Not really.

According to Wikipedia, Snaps are supported "out of the box" by at least:
* Ubuntu (plus most of its deviations)
* Gallium OS
* Manjaro
* Zorin OS
* KDE Neon
* Solus
* Li-f-e

I'm not familiar with some of those operating systems, but Manjaro are KDE Neon are certainly big names, and Snaps can be optionally added to a MUCH bigger list of operating systems... In theory, it can run under almost any Linux-based operating system.

So no, not Ubuntu-only.

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Flatpak is cross-distributions

Snap is too, so I don't understand your point.

As I wrote above, FlatPak is slightly more "open" - which is the primary reason why I think it is the superior of the two (though I find the performance much better under Snap); but it is certainly not the only one of the two that has cross-distribution support.


Last edited by Cyba.Cowboy on 16 March 2021 at 12:10 am UTC

I didn't know Snap was installed by default on that many distros, I stand corrected.

EDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support


Last edited by Creak on 16 March 2021 at 12:46 am UTC

Quoting: Cyba.Cowboy

Quoting: CreakWell there is at least a huge difference between AppImage and the others (AppImage being merely a huge dump of files that are uncompressed at a specific location and run there).

Meh.

I meant similar in the sense that AppImage loosely has similar goals... There are of course, some obvious differences (such as the fact that it doesn't usually provide libraries, it's not isolated, etc...); but the general idea is the same.

It is quite clearly the "most" different of the three, though...

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Snap is basically Ubuntu-only

Not really.

According to Wikipedia, Snaps are supported "out of the box" by at least:
* Ubuntu (plus most of its deviations)
* Gallium OS
* Manjaro
* Zorin OS
* KDE Neon
* Solus
* Li-f-e

I'm not familiar with some of those operating systems, but Manjaro are KDE Neon are certainly big names, and Snaps can be optionally added to a MUCH bigger list of operating systems... In theory, it can run under almost any Linux-based operating system.

So no, not Ubuntu-only.

Quoting: CreakBut overall I don't think the fragmentation is that bad because:
* Flatpak is cross-distributions

Snap is too, so I don't understand your point.

As I wrote above, FlatPak is slightly more "open" - which is the primary reason why I think it is the superior of the two (though I find the performance much better under Snap); but it is certainly not the only one of the two that has cross-distribution support.

Huh, I would be shocked if 'out of the box support' equals 'installed by default'. Especially for Manjaro.

The main issue with snaps is that they are not decentralized, Canonical controls tge store. Where flatpaks and AppImages are open. AppImages are basically the same as the Mac's DMG files, so there is that.

Quoting: CreakEDIT: looking at Flatpak's wikipedia page, the support out-of-the-box seems as important if not more than for Snap:
https://en.wikipedia.org/wiki/Flatpak#Support

Quoting: slaapliedjeWhere flatpaks and AppImages are open.

Well I have repeatedly stated above that this is the reason I think FlatPak is the superior "next-generation" package manager... I find that Snaps have noticeably better performance and they have certain technical advantages over FlatPak; but at the end of the day, being more "open" is more usually more important in the Grand Scheme of Things (at least in my opinion, anyway).