For anyone having this problem, I found out the common denominator.

First off, yes, if you're using KDE Plasma, you should double-check that "Allow using as pointer and keyboard" is disabled in your controller settings. However, 9/10 times, that will not fix the problem, especially if you are running the game under a native Wayland window or compositor.

The root cause stems from the fact that Steam can't track window focus for Wayland clients. When a game runs under winewayland.drv via PROTON_ENABLE_WAYLAND=1, Steam never sees the game window take focus, so Steam Input falls back to the global Desktop Layout. This layout maps your controller to mouse/keyboard, which is why the touchpads either do nothing useful in game or start moving your cursor around. Another common symptom is rapid flickering between mouse/keyboard and gamepad glyphs for games that support switching between controller and mouse/keyboard dynamically (i.e., ELDEN RING, Lies of P).

GloriousEggroll fixed this upstream in proton-ge-custom by calling steam://forceinputappid/<appid> right before the game starts and resetting it to 0 on exit, which pins Steam to that game's controller configuration instead of letting it fall through to the Desktop Layout. The commit also changes self.env.setdefault("PROTON_NO_STEAMINPUT", "1") to a plain self.env["PROTON_NO_STEAMINPUT"] = "1" on winewayland, and adds a Wine patch that hides Steam virtual controller records from SetupAPI and Configuration Manager enumeration so DirectInput/XInput can't open a second, dead controller path.

However, this is not a true fix, since it sets Steam Input to disabled from within the Proton layer itself. So, if you did try to set PROTON_USE_SDL=0 PROTON_NO_STEAMINPUT=0 along with -steamos3 in the command-line arguments (which is what people did before SDL 3.0 came out last month), it wouldn't do anything, since PROTON_NO_STEAMINPUT would just become enabled again.

If you're fine with using SDL as the backend, this should be an okay change for you, and it will hopefully become the standard on subsequent releases of proton-ge. However, for those using the Steam Controller 2, which defaults to using Steam Input as the backend for controls in all games, this is not a good workaround. Or even if you're using proton-cachyos (not sure how they plan on approaching this issue, since it's pretty niche to begin with). Or even worse, if you're like me and running into both problems (I use a Steam Controller 2 and I prefer using proton-cachyos). Ordinarily, this leaves you with a couple of options, which aren't true "solutions" in my mind:

1. Running the game in an XWayland window. Solves the problem with Steam Input compatibility but unfortunately ruins HDR compatibility.
2. Using SDL as the backend. Technically works, but for newer hardware that doesn't have SDL compatibility, like the Steam Controller 2, this will not work. Also, you lose access to controller reconfigurator input remappings.
3. Continuing to use Steam Input, but not granting Steam Flatpak access over input devices. Technically still works, but I don't think input remappings from controller reconfigurator will work (at least, it didn't for me), and Gyro doesn't work either (at least, I don't remember it working for me). Also, you get bombarded by "grant Steam access to input devices" occasionally, which is a pretty annoying dialog box to close mid-session. It kinda kills the immersion. I don't know how this would be accomplished on non-Flatpak Steam. But I know that I kept getting prompted for Steam to control my input devices, and I just never granted Steam that access.

Luckily, I found a solution to this issue a couple of minutes ago on the latest Steam Flatpak on proton-cachyos on KDE Plasma 6 Wayland! In theory, this should work on other desktop environments and on non-Flatpak Steam, too. My approach uses two things:

1. Setting PROTON_USE_SDL=0 PROTON_NO_STEAMINPUT=0. This only works on forks that still use setdefault for that variable on winewayland, which proton-cachyos still does. Since proton-ge-custom changed it to a plain assignment, it's not recommended that you use it as a compatibility layer (though I don't think it's in the official proton-ge releases yet).
2. A wrapper script (proton-game-wrap.sh) that fires steam://forceinputappid/<appid> before the game starts and sets it back to 0 when the game exits. This was inspired by GloriousEggroll's commit, and it is what stops Steam from falling back to Desktop Layout. The only difference in my approach is that I'm doing it from a launch wrapper rather than from inside Proton itself. This effectively keeps Steam Input enabled and Steam finally recognizes the game window, so it won't try to turn on Desktop Layout over and over!

Put together, my launch options look like this:
PROTON_USE_SDL=0 PROTON_NO_STEAMINPUT=0 /path/to/proton-game-wrap.sh gamemoderun %command%

Some caveats about the script:

• The wrapper script also flips HDR on/off for my ASUS monitor when the game starts/ends, respectively. This doesn't have anything to do with the Steam Input fix. If you don't want that, you could set WRAP_NO_HDR=1 in your launch options to skip it entirely, change WRAP_HDR_OUTPUT if your HDR display isn't called DP-2, or just delete the hdr() function and its two call sites.
• On Flatpak Steam, the steam binary is not on PATH at the moment your game launches, because the script technically runs inside the Steam Linux Runtime container (pressure-vessel). A bare steam steam://... call just returns 127, while from the outside the game launches perfectly normally and looks like everything worked. The invocation that actually lands is flatpak-spawn --host flatpak run com.valvesoftware.Steam <url>, which requires org.freedesktop.Flatpak=talk permissions from Steam Flatpak.
• This method does not survive a controller reconnect. If your controller turns off, or you start the game with the controller off and turn it on afterward, Steam re-registers the controller from scratch and quietly drops the forced appid. I couldn't figure out how to solve this, so any advice (or even a better version of the existing script) would be greatly appreciated!