They aren’t going to make their own desktop. That’s just not gonna happen. They’ll use KDE as before, and that’s just the facts. I’m not saying they will make anything other than a VR-style compositor to select standard 2D virtual desktops. That’s simple and effective, and doesn’t require building a whole new thing.
This is going to get downvoted to hell from the title, but it’s a joke: https://www.currentaffairs.org/news/why-i-am-dr.-peter-b.-jordanson-now
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
This should sidestep that and timeout pretty quickly: https://jshtab.github.io/guide/gvfs-autmount/
Grammar and formatting, ma dude. This is painful to read.
Not sure you’re getting it…
SteamOS runs KDE desktop. Frame will also have KDE Desktop, be use it’s just running the ARM build of the same SteamOS that will be on all of these devices.
Making a VR-reaey compositor display for this is fairly simple after this point, you just need to hook all the sensors into camera movement for the screen, and that screen can show many composite views…like the desktop, or a media screen, or the Steam Library.
It’s a basic function of VDD. It will definitely be in there.
Try going into your BIOS settings and disabling IOMMU for the USB and Chipset settings. Boot and see if it works then.
Your North and South (if you have one )bridge chip?
Open your machine and look at these ports.
Are they directly connected to the motherboard, or on the front of a case extended by a cable?
This has existed since the 5’s, to be fair. It’s much more efficient now, and we have whole home storage options of course, but this is insane at this price.
It’s not “trouble” if you’re already familiar with Linux. It’s not the way I would go as a user of 20+ years, but it’s not just for desktop use.
If you’re looking to build a platform for something, it’s perfect. Look at why Valve switched to use to for SteamOS. You have an underlying framework of a stable system, and you just create automation to slap it all together into the base layer of all the things you want without having to worry about specific things breaking the stack you’re building on top of it.
It’s like a blank page instead of a notebook with line guides.
It helps make more sense if you think of everything you’ve got to build on it already existing in a git repo. Merge > Build > Release. Makes perfect sense, and you save yourself creating an entire distro to maintain from scratch.
99% of all Windows games running Proton, and most perform better than on Windows, depending othe game.
For the specific games you mentioned, they all have Platinum rating in Proton, meaning flawless. You can see here in ProtonDB.
I’m not sure what your experience was in the past, but I write tons of Proton patches for games, and the only ones I’ve seen that don’t play well are the pre-DirectX9 games, which can’t plan on Windows XP or later anyway. Proton will soon be able to play these games without issue thanks to some Vulkan patches coming up.
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.”
That’s slightly different. That is mapping controllers to already existing inputs for a game, which steam-input already does.
Mapping all the sensors of a VR headset for motion and tracking is an entirely different thing, though kinda similar in some sense.
They’ve already said they’ll be using FEX: https://www.pcgamer.com/hardware/vr-hardware/steamos-launching-for-arm-fex-translation-layer/
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.