

Interesting…
I think we only knew about the arm64 but, but not androidarm64. Sounds like they’re leaving the option open for Android developers to make their APK distributions compatible with Steam to play on Frame.


Interesting…
I think we only knew about the arm64 but, but not androidarm64. Sounds like they’re leaving the option open for Android developers to make their APK distributions compatible with Steam to play on Frame.


Maybe you don’t understand how RTSP works, but it’s just a protocol for sending video and time information in a stream.
Try VLC if you just want to view the stream.


If it’s a generic controller without a known equivalent HID compliant profile (this one detects as a Switch), it’s likely not going to work well for a variety of reasons.
Maybe give this a shot: https://github.com/DanielOgorchock/joycond
It should make controllers aligned with Switch work with steam-input.


Just don’t run this version of Proton with this game.
The reason they make all versions of Proton available at all times is because the rolling Proton version may break game configs for various reasons, in this case it looks like a Vulkan rendering queue issue where the call is blocking: https://docs.vulkan.org/refpages/latest/refpages/source/vkQueuePresentKHR.html
You can check ProtonDB to see if anyone has a workaround for newer versions of Proton, but it’s mostly unnecessary unless there’s some specific features a specific point release you care about. Just pin the game to a working version and go.


I mean…once they have this going, there’s nothing stopping that. It’s essentially the same thing, except the hooks for Mac/Win for the desktop. Linux will already be ready to go. I just haven’t heard them mention it is a point of release is all.


I’m…not sure what you mean. They’ve just compiled SteamOS and it’s base for arm64. There was nothing stopping that from happening previously. The majority of the client code is closed, and that entire piece of SteamOS is weaved into the OS itself. So they’re just distributing arm64 builds if SteamOS with the client code, not commiting to a standalone client being distributed, unless you’ve seen that somewhere.


Support meaning in their build system. They’ve already added that as a build option awhile ago. Just means you can set a flag to build for more platforms now, and they have arm64 machine types to handle the builds.
Devs still need to do optimizations to support this in most cases. Some games based on open frameworks won’t have much to do but flip the switch.


No, they are building a translation framework for x86


Grammar and formatting, ma dude. This is painful to read.


If you’re reading reviews on Software Manager, you don’t want to be messing with jails.
Just use Flatpaks, and install Flatseal for permissions control over individual packages. They are sandboxed, but with permissive defaults set by the devs, so you can use Flatseal to lock them down, then set permissions you’re comfortable with. If it breaks something in that one Flatpak, then just reverse your permissions changes. Simple.


“We’re expecting console numbers this time, and then they developers will have to support it.”


I think you probably need to understand the underpinnings of what Valve accomplished over the past few years to understand why the Frame is useful.
Essentially, it’s a Deck strapped to your face. Same OS, same everything, just different hardware platform.
Valve spent the time to revamp SteamOS in order to make it more portable to various devices, which are now launching. Couple that with their efforts on Proton, and you have an entire ecosystem with very little in the way of preventing people from adopting these devices with their ease of use.
Steam Deck was just sort of the appetizer and test launch to gauge interest and build a fully functional hardware development and support vertical in the company, and it was wildly successful. I guarantee (if they can get the price right) that the Frame will sell WAY more units than the awful Vision Pro. I honestly think people might adopt this over buying another version of the Deck if it’s comfortable.
Some things I expect to happen with the Frame launch:


Sounds awful and tedious


Opentofu is Terraform 🤣 I generally don’t throw that out there to prevent confusing people, but I prefer it, honestly.
Packer builds images you can upload to cloud platforms.
Terraform/Opentofu executes API calls to orchestrate spinning things up and down.
Cloudinit is the native built-in bootstrap framework of instances themselves that all the major cloud providers support. It’s what executes as “userdata” as some call it. Check your cloud provider docs for how to hook it in.


Use Terraform + Cloudinit scripts if you’re using a cloud platform, and make sure you version everything or use Packer to make versioned images.


Don’t use “echo”. That’s akin to saying “Print everything after this echo command to the terminal”, so it’s just outputting the stuff after echo as if it were text.


All day everyday. Why click through a GUI when I can slam out a command in 1/4 of the time to see what my resources or doing, or if something is acting weird. Watching logs tail in a terminal is always going to be faster and smoother than GUI as well. Debugging things as well.


👍


It may not be config related, by libraries missing or in the wrong location, hence, why I’ve been asking for logs from Sunshine.
Yes, that’s what I’m saying. Running Android on Linux is one thing, and that only requires Waydroid and has nothing to do with Steam.
Having an SDK stack specifically for androidarm64 means there are extensions there to hook into the Steam client, meaning Android apps that use Steam platform for…something. This was never announced or discussed.
It has nothing to do with Frame specifically, because you don’t need an entire SDK entry point for one device that has nothing to do with Android anyway.
So it must mean that they intend to give the option to hook in to Steam for game devs that already have Android builds and distribution or something. Like Netflix games, Rockstar, Bethesda…etc.