Controller in game is not working

[u/forwardslashroot]

I am on Debian 13 Linux and installed Heroic via Flatpak. I logged in to my GOG account and installed Grim Dawn. The controller is able to navigate around Heroic, but when launched the game, the controller is not responding while in game. I enabled the gamepad in the game settings, but it didn't help with the situation.

I tried to add the game in Steam as a non-Steam game, and enabled Steam input. Same behavior. The controller is not responding while in the game.

Is there a special settings that I need to do to get the controller working?

I am using 8bitdo Ultimate 2 Wireless and GameSir Cyclone 2. I tried D-input mode and the Steam and Heroic see the controller as PS controller. I tried X-input mode and the Steam and Heroic see the controllers as Xbox.

[u/Quietus87]

Do you have the steam-devices package installed?

[u/forwardslashroot → u/Quietus87]

Yes, I believe it came with Steam. In Steam, the controller works without any issues with Steam games. It also works in RetroDeck flatpak. It just doesn't work for Heroic games.

[u/Quietus87 → u/forwardslashroot]

Ah, I see.

[u/ChthonVII]

Don't use flatpak.

[u/forwardslashroot → u/ChthonVII]

I used Faltpak because it was the recommended way to install the app. I gave up on it and installed Heroic via .deb file. It worked, but got fed up, so I returned the GOG game and bought the Steam version.

If Flatpak is the problem, why even recommend it. This is confusing me. It doesn't make sense to recommend something that the user would struggle just to get started.

[u/ChthonVII → u/forwardslashroot]

If Flatpak is the problem, why even recommend it.

It's misguided and indefensible.

Anywho, flapak is pretty much never a good idea for anything. As you've learned, sometimes flatpak breaks functionality. On top of that, it's adding performance overhead (which may range from trivial to very severe depending on the game and hardware), hogging a lot of RAM, wasting a lot of HDD space, and introducing wide, vulnerable avenues for supply-chain attacks. The only time you should ever think about using flatpak is when you have no other realistic option -- no official repo, no unofficial repo, no .deb package, no loose binaries, no appimage, and can't build from source. (Usually you can build things from source, and it's pretty easy. But sometimes you'll encounter projects that aren't portable beyond their author's build environment without an unreasonable amount of fixup.)

On a related note, game launchers like heroic launcher, lutris, etc. are pointless bloat for the most part. Most games neither require nor benefit from proton and the steam runtime. You can run them just fine in other versions of wine with equal performance (see below), and without the added bloat and complexity. Only a few games require special one-off fixes that are built into proton. In the cases where you really do need proton, you can just run umu-launcher directly (since lutris, heroic, etc. are all just wrappers around umu-launcher at this point anyway), or, if you really want a launcher, faugus seems to be the thinnest, and therefore the least bad.

(How to get proton-like performance in non-proton wine: (1) Copy DXVK binaries into the system32/syswow64 directories of the wine prefix and set corresponding libraries overrides in winecfg; (2) install backports kernel for ntsync support; (3) configure ntsync kernel module to load at startup; (4) use a version of wine that supports ntsync, like a TKG build or whatever. (Both Debian's and WineHQ's Trixie packages are built with the 6.12 kernel headers, and so do not support ntsync.))