First of all, there are two different drivers for the DS4 - hid_sony and hid_playstation. hid_playstation is a relatively new one, developed by Sony. hid_sony is an older one which had been reverse engineered years earlier. There was a good stretch of time where hid_sony worked perfectly for me, but now I seem to need hid_playstation. On Gentoo, since about a year ago, I have had to manually enable hid_playstation in the kernel menuconfig (which required enabling an additional LED driver first) and use it instead of hid_sony to get my DS4 working. Otherwise I had problems where it would work some nights, not work at all others, or just the trackpad would work for some reason.

Basically, on Fedora you are a guinea pig for whatever new tech Red Hat (now IBM) is considering rolling out. It is a well polished distro and I have set it up on several people’s computers, but they will be among the first to just foist a whole new replacement subsystem on their users. Can be interesting if you like experimental shit (and what comes to Fedora tends to stick around [i.e. PulseAudio, systemd], unlike a lot of the shit Canonical has tried to introduce [i.e. Upstart, Mir]). Can be a major headache if you are trying to use something which requires iptables and they have jumped into nftables with both feet (for instance).

You can pry gentoo from my cold dead hands. The ability to do things like mix LTS and git HEAD packages at will is yuuge, as well as the dynamic dependency graph based on enabled features. Some newer distros like Nix and Guix come close, and even offer the ability to skip compilation via their package caches, but they have a number of pain points in my personal experience.

The Distro isn’t super important, since Valve started shipping their own runtime (for Linux ports) and Proton (for Windows games). Anything modern outside of the strictly free-software distros (things like Ututo, Guix, etc. which do not ship proprietary firmware or drivers of any kind) will suffice.

There are a few different approaches to playing Windows games. Some have direct ports. Games like Doom, Quake, were open-sourced a long time ago and have dozens of ports with all sorts of features. Other games, like CS:GO, Kerbal Space Program, X-Com: Enemy Unknown, etc. are not open source, but have ports produced by either the developer or the publisher. A LOT of indy games have ports available, and most modern game engines like Unreal, Unity, Godot, etc support Linux targets (whether the publishers give a shit is another story.) These typically target the Steam Runtime (a collection of specific versions of graphics, audio, and auxiliary libraries that Steam will install). These libraries are also provided by distributors, but the distribution libraries will typically be newer. This is normally a good thing, but commercial ports don’t receive frequent updates and are likely only tested against the Steam Runtime.

If there is no port available, the next option is Wine. Wine is a Windows compatibility layer which is capable of loading Windows PE format executables on Linux and dynamically linking them to a large collection of substitute DLLs which implement Windows functionality on top of Linux. Proton is the version of Wine shipped by Steam, with a bunch of tweaks specifically focusing on graphics performance. Most of the time, games will work in Proton, but there are a handful of cases where they work in Wine/Wine-Staging but not in Proton.

If the game requires an anti-cheat component, it will almost certainly not work in WINE/Proton, because the whole basis of getting Windows games to work on Linux operates using the same mechanism as cheats: replacing “genuine” components of the Windows operating system with 3rd party code to intercept system calls and do something other than intended.

A much more complicated route would be to set up a virtual machine. A virtual machine is a full blown PC-emulator, except since the host machine shares the same instruction set as the guest, it is a lot faster. This is not enough not yield good performance in games though, because games also require direct access to the video hardware. To do this, you need a SECOND graphics card for the guest operating system, then you can try to configure PCI-e passthrough (so the video driver in the guest OS talks directly to the video hardware). This is probably the most complicated approach, but you end up running genuine Windows virtualized on real hardware. In addition to the second GPU, you need to make sure you have the overhead in CPU / RAM / storage to run multiple operating systems concurrently such that gaming performance won’t be substantially impacted. Additionally, you probably need a second monitor if you want to interact with both the guest and host operating system simultaneously.

Finally, if none of that works, it may be worth looking into whether ports for other platforms exist. If you struggle running a dated Windows game in WINE, you might have better luck emulating a release for PS2/3, GameCube/Wii/WiiU/Switch, etc. The state of Nintendo platform emulation in particular is phenomenal, and it is trivial to increase the video resolution beyond what the official hardware supports if your machine has the horsepower for it.