👍

…then why are you setting Steam Deck launch options? You may want to clarify that.

Same basic premise though. Check your controller confirm for both Proton, and then in the game.

Try running: killall ibus-daemon before launching and see if that fixes it. I’ve run into this in a couple games.

There is no fundamental performance difference between these “gaming” distros and any other ones. Some minor kernel tweak maybe net a few percentage points here and there, but the gaming stack is still the same across the board, and very little can be done to squeeze more performance there without each just getting performance improvements.

Even still, you’d just install those same versions on any other distro and get those performance benefits.

You said this was on Deck, yeah? Check the Deck in-game controller settings. See what the mapping is supposed to be, versus how it’s behaving. If it was previously working, something with configs changed. Nothing about your launch settings should to be messed with.

Check the bindings in the game and remap it

Post the output of nvidia-smi when the fans start to engage. Will be helpful for next steps.

Edit: just some other tweaks to try and eliminate certain issues:

1. Try running with just a single monitor connected
2. Disable Steam Overlay
3. Close Discord if running
4. Add “-threads 4” to your launch options and see if that helps

Well if you don’t understand how to make the “ideal thing” work properly, it sounds like you need whatever the fuck works, no?

It’s a solution. Use it.

Try this: https://discuss.kde.org/t/how-do-i-calibrate-my-game-controller-in-kde-6/36299/4

What distro are you on? Make sure the kcm-joystick package is installed for KDE.

Start VPN, then launch game. I have no idea how this is complicated at all…

Didn’t that as a requirement, but sure you can. They have profiles for each location you want to use, so import the ones you want, set the client all as a non-Steam game, then just connect whatever locale you want. Works fine.

Platform doesn’t matter. It’s a simple OpenVPN profile. There’s nothing about Deck that makes this unusable.

If you’re not sure how to use this: https://gist.github.com/linuxkathirvel/dd5a28f48442466aa1d6ff305fba4782

https://nordvpn.com/blog/nordvpn-config-files/

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.

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.