

Same as it is on Deck. It’s just a Deck in a different form factor from the user standpoint. Everything will operate the same.


Same as it is on Deck. It’s just a Deck in a different form factor from the user standpoint. Everything will operate the same.


Quite awhile ago, but that’s not the barrier here.


The PS5 is essentially just a PC anyway, you just need to get through the Hypervisor BS as this guy did. It has AMD CPU/GPU inside, so it’s just a matter of making the kernel drivers detect what I imagine to be standard AMD RDNA2, but a custom identifier GPU detect and go to work.
Nice job though.


Nah, it’s not that risky if your tooling and process is solid. I have thousands of edge devices out in the field doing firmware updates on carrier boards from a specific manufacturer and have never had one fail or brick in update. Why? Because their tooling is absolutely fantastic and pretty bulletproof.
Even a simple {checksum>transfer>checksum>write>checksum} is pretty safe, UNLESS…you know the carrier you’re flashing doesnt have the ability to do so, in which case, you definitely put a warning like this on your product because you know it has a penchant for failure.


When they do this, they know they have a problem with their flash utils and process 🤣
I’d leave it alone.


Not being bristly at all. Your comments seem to assume: 1) People don’t already know (check the thread you’re in) 2) Valve is doing something wrong, and/or 3) They are somehow at fault for something, like stolen valor or not giving credit where credit is due.
You suggested your comment was pedantic, and I confirmed, and it’s because of your tone. I’m not rage replying to your comments, just correcting the context because I feel you have the wrong take.


Nope. Anything ARM. Meaning tablets can run x86 games with Proton+FEX if that be the case. Also getting the MacOS segment back into the fold. ARM laptops, hell, maybe even Apple portable devices, who knows.
It’s not just about their own hardware, but my thinking is that the Deck 2 will be ARM for power consumption reasons, so this all makes a lot of sense. The Frame isn’t really just a VR devices, it’s also going to be SteamOS, so that means a virtual desktop and all the usual Linux apps and such. I’m sure it will sell on its own as a productivity device as much as a gaming device. No reason it can’t fill the market gap that awful Apple headset screwed up so poorly.


Yes, pedantic. Wine existed before Proton, and Valve made it more suitable for use in its own ecosystem with funding and developer time, but also still open and usable for the community writ large.
They’ve also been funding FEX since it’s inception, and likewise commiting development resources for the same purpose, to further their product reach on a wider array of devices.
They aren’t simply gobbling up these fledgling FOSS projects for use in their products as you seem to suggest, they’ve had a long term plan to make milestones and goals that have gotten them to where they are now. That’s the point.
They aren’t gatekeeping anything. They simply have the resources to give these projects they are interested in a boost.


This is specifically about ARM64 if you read the posting. The only other ARM hardware out there that runs Proton are these random Chinese brands that make emulation focused handhelds. That’s not a segment of the user base that EA would care about.
Now, Valve is turning the entire ARM ecosystem on its end by building out an entire suite of tools to make an emulation layer that makes running Proton on ARM almost entirely possible for the full range of games that already run on Steam, which is huge. That means any ARM device can now run Steam, Proton, AND FEX without much in the way of a barrier. This brings Steam on mobile potentially into olac, MacOS back to the table…etc.
It’s not about Linux users and SteamOS singularly, but the coming expansion into the ARM space.much larger than 4-8%.


This is certainly driven by upcoming Valve hardware. I don’t think any of the smaller devices out in the wild really sell enough units to make them go this far.


If you’re specifically asking because of memory use, there is no need. Memory management in Linux is extremely efficient, and since everything is a process, a properly killed process doesn’t block reclaim of that memory as you see a lot in Windows. You may see your “free” memory as being low, but that’s kind of a misnomer as you should be paying attention to claimed vs unclaimed/cached memory, which will be “recycled” into other processes that request it. If you run into memory issues on Linux or BSD, you’ll know it.
That being said, if your machine isn’t suspending or cleeping, then you’re just wearing your components out by leaving them on 24/7, so shutting down or suspending would be good practice to extend the general lifespan of your machine.


Well, you’re now blaming the OS. You chose Nobara, and that’s a “you” problem.
If this was running in Windows, you’d have the guarantees that everything works all the time? Same with MacOS, BSD, Android…it’s software. You don’t seem to get that.
If you’re unable to debug and tell what’s going on , and expect that to NOT be the norm…buddy, you’re in the wrong place.
Go back to Windows or whatever you previously using and be happy…oh wait…you don’t do that because of your higher standards.


It’s free software, ma’dude. You work it like any other software. When you have regressions, you go back to a working version.
You expecting everything to work all the time and being bitchy about is entitled as hell.


Just go back to the working version then?


There have been rumblings about this for a year or so, and it’s interesting because Nvidia doesn’t have any large hardware inclusions in the gaming space, aside from Switch 2. Nvidia has NVM as an API abstraction for their hardware, so I assume this job is about working on improving performance or support on that end.
Now, the big question is…why? It’s unlikely they would do this to squeeze about more performance out of their existing hardware for PC and Switch users alone. I think the general speculation would be that they are planning a product launch of some sort, and from the sound of the posting, I’m guessing they’ve got something to compete with AMD in the handheld market that isn’t Tegra.
They’ve also been saying for years they intend to hop into the ARM space, but keep fumbling it with delays. Their N1X(?) is supposed to finally launch “soon”, but with component prices the way they are right now, I’d expect them to delay again. Their Grace chips were kind of a joke, and they didn’t come anywhere near the power efficiency of other SoC options in the market.
All this to say: I think they’re hiring a small dedicated team to improving mobile or ARM gaming chips for…something, and that’s what these jobs are for. They need to squeeze some more juice from these chips to make them attractive at market.


Instead of writing a novel here, tried to find a post to explain what I think is happening.


Out of curiosity, does this machine in question have a hostname that falls under the domain you’re using for DNS resolution?
Also, what are the contents of /etc/nsswitch.conf and /etc/resolv.conf?


Switch those CNAME records to A records, clear your cache, then see how it works.
I can promise you this is not a resolved issue. If it was, you’d be seeing posts like this everywhere. It’s behaving as it should.
Your setup on the Firewalls is not what I would call a “standard” setup. There is both a proper DNS forwarded, AND what they are calling “DNS Filtering” at play with that service. I can’t see your record setup, but depending on which gives the defacto answers when you make a request, you may get conflicting responses, so I would just do away with any kind of non-A records in your setup and see what happens since their docs specifically say it’s only meant for those records and not CNAME or Alias.
CNAME gives you no benefit to what you’re doing here anyway since you only have the couple machines and not MANY records pointing to various places or using named hosts requests or something.


Yes, because it would actually as an accidental Round-Robin return in the case that there is a conflict with a wildcard A record, and a CNAME which isn’t supposed to be working.
This is a combo of your DNS setup being misconfigured, and DNS caching working differently on Windows vs Linux.
Resolution is just fixing your DNS to work properly.
Same way you made it work on Deck, again. SteamInput will map controllers to input devices detected by Dolphin, and you map to whatever you need to map to in whatever way you want.