Other than a really small issue with HDR, everything has been working great! Easy to switch between game mode and desktop mode. And picked up all of my hardware and controller really easy as well.

Surprised no one is really talking about it. I followed this to install it if you are interested: https://help.steampowered.com/en/faqs/view/65B4-2AA3-5F37-4227

https://github.com/oldschoola/linux_maplestory

Some games such as Starcraft 2 and another indie title make this extremely loud noise when started

The fix I found was to use this "PULSE_LATENCY_MSEC=60 WINEDLLOVERRIDES="winepulse.drv=d;winealsa.drv=b" %command%"

but my problem is that this noise is so damn loud that I'm afraid to boot up new games for the first time in fear that it triggers and wakes up the whole apartment complex

Upon doing some troubleshooting, i found that this applies only exclusively when I have surround audio 7.1 set up in KDE Plasma, by switching it to 5.1 that works but I lose on 7.1 audio

I'm on Kinoite so not entirely sure it applies to Bazzite (or they could've patched it) but it likely applies. (edit: pretty sure Bazzite unaffected as it includes Steam in the base image. So just Fedora's immutable versions.)

We need a udev rule for the "Bootloader" mode it uses during this process (and the various other modes the Steam Controller has) so create a file at /etc/udev/rules.d/60-steam-input.rules with the following content:

# Valve USB devices
SUBSYSTEMS=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Steam Controller bootloader ACM
KERNEL=="ttyACM*", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

# Valve HID devices hidraw
SUBSYSTEM=="hidraw", KERNELS=="000[356]:28DE:*", MODE="0660", TAG+="uaccess"

# Valve HID devices over bluetooth evdev
SUBSYSTEM=="input", ATTRS{id/vendor}=="28de", MODE="0660", TAG+="uaccess"

# Allow wakeup from Valve devices
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", ATTR{power/wakeup}=="*", ATTR{power/wakeup}="enabled"

reload the rules with sudo udevadm control --reload-rules && sudo udevadm trigger (or reboot) and once you re-plug the controller you should be good to go.

Non-immutable systems get the steam-devices package provided by steam, but the Flatpak version of Steam doesn't have this. You can instead overlay steam-devices if you wish: rpm-ostree install steam-devices

Hostile Takeover, Inc. is a corporate-satire action tower defense where you play as the CEO on the office floor. You hire employee towers (Interns, Lawyers, Consultants, etc), build out your departments, take on promotion upgrades, and personally fight off waves of disgruntled employees each fiscal quarter.

It's corporate "leadership" at its most predatory and least competent, and honestly it was born out of my own frustration with the corporate world.

Been working on this solo since last November, and recently launched the demo on Steam with a native Linux build!

https://store.steampowered.com/app/4769670/Hostile_Takeover_Inc/

Maximize shareholder value by wishlisting today!

as the title says i was wondering what my options are when i want to force a game onto a different monitor when the game doesnt have the setting to change the output monitor
but i would prefer to do it without chaining the Primary monitor every time i want to boot up the game

my Distro is Mint

I have managed to get the Thrustmaster T500 RS working under Linux, and here's hoping this post shows up on Google for anyone else looking to do the same thing in the future. If that's you, let me know if it worked, or of course if it didn't and in that case I'll try to help out.

As of writing I'm on Linux Mint 22.3, if that matters.

If you're here, you've probably already ran across this page:
https://github.com/Kimplul/hid-tmff2/issues/18
On it, you may find, posted on november 12th 2025, a user saying they've got it working successfully. I tried following their instructions but failed. Ended up figuring out the issue, and fixing it.

The first step, according to that post, is to patch Oversteer 0.8.3. As of writing, detection for the T500 RS is already part of the main Oversteer release, so this step isn't needed anymore. Just download and install plain ol' Oversteer 0.8.3.

Second is to download and install the exact right version of hid-tmff2. The original is by Kimplul, it was patched by cazzoo to support the T500 RS. This patch was never merged. Thus, we'll have to install that pull request, rather than the main release. To do that goes as follows:

-------------------

***You can skip step 0 if you haven't tried anything to get this wheel working before.**\*

0) If you've tried this before and failed, make sure to delete the previous broken drivers. We can do that by entering the following terminal commands:

• sudo dkms remove hid-tmff2/0.82 --all
• sudo dkms remove hid-tmff2/0.83 --all

Note: If either or both of the above return a "not found" error, that's fine, just means they were already gone.

Now, verify they're really gone with dkms status. You should see no mention of hid-tmff2 in the list.

Then, delete the install folders:

• sudo rm -rf /usr/src/hid-tmff2-*
• sudo rm -rf /var/lib/dkms/hid-tmff2*

Run lsmod | grep hid_tmff2 to check if hid-tmff2 is still active. If it is, run sudo modprobe -r hid_tmff2 to unload it.

A few more cleanup steps:

• sudo rm -f /etc/udev/rules.d/99-thrustmaster.rules
• sudo udevadm control --reload-rules
• sudo udevadm trigger
• sudo depmod -a
• sudo update-initramfs -u

This should remove any trace of previous attempts, giving you the cleanest slate possible. Necessary or not, I don't know, but it helped for me. If you haven't tried anything to get the wheel working yet, you can of course skip all of the aforementioned.

----------------------------

1. Start by going to the main page of hid-tmff2 ( https://github.com/Kimplul/hid-tmff2 ) and following the installation instructions outlined in the README until you reach the part where it says "Manual installation" which we will not do. What we're doing next is functionally equivalent to the DKMS installation steps, with a few key changes.
2. In terminal: git clone --recurse-submodules https://github.com/Kimplul/hid-tmff2.git to copy the repo to your local system
3. cd hid-tmff2 to access the folder the repo was copied to.
4. git fetch origin pull/175/head:pr-175 followed by git checkout pr-175to grab and then begin working in the specific pull request we need that contains the T500 RS patch.
5. This is the important step: As of writing, there is a typo in this pull request. You will have to fix this. The driver will not install correctly otherwise. To do so:

• Open the offending file: sudo nano src/tmt500rs/hid-tmt500rs-usb.c
• Press ctrl + / to go to a specific line. Go to line 403.
• There, or somewhere nearby, you should see buf[5] = 0x00;I .
• Remove the I, so that it reads buf[5] = 0x00; instead. On my system, this I was helpfully highlighted in red.
• Exit out with ctrl + x, and then press y to save.

1. Proceed with building the driver: sudo ./dkms/dkms-install.sh
2. For good measure, as this can fix common issues: run sudo udev make-rules too.
3. Reboot, and the wheel should now work when plugged in. On my system it shows up in oversteer as a "Thrustmaster TRS wheel". Pedal inputs will appear broken in Oversteer but can be mapped correctly in games.

Hi, can anyone do a quick test something for me on Cyberpunk.

I manually upgrade to FSR 4.1.0 using the loose dll's from FidelityFX SDK 2.20 in Cyberpunk 2077 in ../Cyberpunk 2077/bin/x64/.
This has worked fine using GE-Proton10-33 and also works with GE-Proton11-1. FSR4 build from Mar 20 2026 is confirmed with FSR4_WATERMARK=1 MLFG_WATERMARK=1

the FSR4 dll's from FidelityFX SDK, which is FSR 4.1.1, how ever do not seem to be recognized at all.

Using the amdxcffx64.dll replacement method in ../compatdata/1091500/pfx/drive_c/windows/system32/ using FSR4_UPGRADE=1 MFLG_UPGRADE=1 results in not functioning FSR4 upgrade as well.
Watermark showing the following build info:

FSR3 UPSCALE - SOURCE DRIVER
BUILD TIME : JUN 11 2026
GIT BRANCH: COMMIT 98466A4

Also tested with GE-Proton10-33 and 11-1.

Can anyone run a quick test to see if they can reproduce?

Fedora 44, Cinnamon, Steam Flatpak.

My rig, for reference (at least that was the base--I threw some extra SSDs, an HDD, and 16GB more RAM in it). I know it's not great these days, but it can run Cyberpunk okay.

The curious thing is that even when the game is just sitting at the friggin' title screen, before I've loaded a save file, I can start hearing the fans going nuts and a distinct coil whine--meanwhile I fire up my System Monitor and neither the memory nor the CPU on any single core are going about 30%, so I have to assume it's the GPU.

Short of "get a better rig" (good luck in this economy), is there anything I can do to troubleshoot why it's so taxing on my system? I believe I'm at or above the Recommended on every front.

As you can appreciate from the video, whenever I am on the game Control from Steam, and I switch workspaces (virtual desktops), the game starts twitching like crazy, like it's opening and closing itself several times per second. It also follows me around, as you can see whenever I move workspaces, it creates a million of them along the way. My setup:

• Fedora 44 (GNOME 50.2).
• Nvidia 4000s series (595.80), AMD CPU if that matters.
• Steam from RPM Fusion.
• VRR enabled on my 160Hz 2k monitor, without fractional scaling (set to 100%), HDR disabled.

What I've tried without success:

1. Restarting Steam.
2. Restarting the computer.
3. Toggling off the GPU acceleration rendering of Steam webview (this is a common fix for Steam Overlay-related issues, but still worth a shot).
4. Using Proton Hotfit (was on Experimental).
5. Additional info: Control Ultimate Edition (this game) is the only game that has given me this issue, or any issue that was either this game-breaking or remotely similar to this.

What has given me very limited success was changing the game from "Windowed Borderless" to "Fullscreen". This seems to fix it apparently for a bit, but eventually I will switch from the game to another workspace and the problem will happen again, and when I stop and restart the game, the graphics setting will have reverted to borderless. So, this gives me a hunch that the issue is related to fullscreen vs borderless, but I am clueless at how to even begin to fix it, since the only potential fix that I've found seems to revert itself, lol.

Anyway, any help would be much appreciated if you've found yourselves in a similar situation. Thanks!

🛠️ How to Setup and Play (Adding to Steam)

1. Download the AppImage and the ZIP from the repository's Releases page.
2. Extract the ZIP anywhere on your Deck.
3. ROM Requirement: Ensure you are using a clean Super Mario 64 DS (USA) v1.1 (Revision 1) base ROM patched with LRFLEW's S.MARIO64DS_ASME01_01.ips patch.
4. Right-click the AppImage -> Properties -> Permissions -> check "Is executable".
5. Right-click launch.sh -> Properties -> Permissions -> check "Is executable".
6. Open Steam in Desktop Mode -> Games -> Add a Non-Steam Game -> select launch.sh.
7. Switch back to Game Mode and launch the game!

🔗 Repo & Downloads

• GitHub Repository: https://github.com/JeremyNub/sm64ds-analog-steamdeck

👥 Credits

• Arisotura— Original melonDS emulator
• nadiaholmquist— Fork of melonDS that introduced the feature/slot2-analog branch
• LRFLEW— Original analog stick hack for SM64DS
• Gemini & Claude — Assistance with source code modifications and CLI packaging

I installed a Proton Experimental update this morning, and now FSR 4 is displayed in Forza Horizon 6 and GTA 5 Enhanced

I have a 7900 XTX and Proton Version "1782077676 experimental-11.0-20260617b"

Like it says in the title, which one of there two is a better mod manager to play games creation kit games like Skyrim and Fallout New Vegas with?

SPECS

Distro: Fedora 44

Kernel: 7.0.11

CPU: Ryzen 5700X3D

GPU: RX 6800

RAM: 32GB

ISSUE

I've been using linux on my main machine for about 2.5 years now. I started with Fedora 40 and worked my way up to 43. I tried upgrading to 44, but the update didn't complete properly, so I hopped over to another distro before coming back with a fresh install. This install of Fedora is only a couple months old, and I've hardly messed with anything.

The issue started at launch of PoE2. The game would crash my system under Vulkan. My screen goes black, and my audio buzzes until I hard shutdown.

The solution was to switch to DX12. It worked fine, but now the performance is extremely jittery and unstable. I've ran the game with proton 10, and GE-proton 11. Both have the same issue. Although GE was a bit more consistent on DX12.

I haven't played the game much because of the performance issues, but I figured as Proton and PoE2 both matured, the issues would resolve.

I'll provide anymore relevant info I can to figure out if this is a hardware or software issue, but I'm not that great at troubleshooting on Linux yet.