It is possible to modify the steamclient to use wine when possible and change to linuxator when impossible?
The fork already exists, it has a name, and it's an official Steam extension point: the
compatibility tool. You don't need to modify the client.
How it works in LSU today
LSU registers several custom tools — chroots with legacy Steam Runtime, Sniper, Proton 8 — plus a hybrid "FreeBSD Wine" tool that substitutes Proton's Linux Wine binaries with native FreeBSD Wine binaries from the emulators/wine-proton port, while other Proton parts remain unchanged. Selection happens per title, in the game's Properties, Compatibility tab.
So the granularity is
per appid, and the mechanism is the same one Valve uses for Proton itself.
One detail that makes the picture messier than you'd expect: inside Proton there are also Linux binaries that aren't Wine, and those are not replaced — they run through emulators/libc6-shim, which is another emulation thing, entirely independent from the Linuxulator. So the hybrid configuration has
three layers: the Steam client under the Linuxulator, native FreeBSD Wine, and a userspace glibc shim for the remaining pieces.
And the field verdict is clear: the hybrid mode is recommended as more reliable than pure Linux Proton under emulation, thanks to working WoW64 and more stable 3D acceleration on Intel and AMD cards.
Where exactly the fork falls
Two distinct moments:
At install time — forcing a compat tool makes Steam download the Windows depot instead of the Linux one. This is where it's decided
which binary will exist on disk. Not reversible without reinstalling.
At launch — Steam invokes the tool's script instead of directly executing the Linux ELF. The script is your code: it receives the command line and decides what to do.
Automatic, yes — but not the way you're thinking
A runtime fallback —
try Wine, and if it fails switch to the Linuxulator — doesn't work: you discover the failure after a crash, or worse, after thirty minutes of corrupted gameplay. And the depot choice was already made upstream of that.
What can be automated is the
decision, not the switch: a table of appid → path, shipped alongside LSU and updated by measurement. A sort of ProtonDB for FreeBSD.
And this is where the 100-title corpus changes function. It stops being a sample for the syscall differential and becomes the
routing table. That's a much more direct use of the same work, and it produces an artifact useful to anyone using LSU, not just to you.
Some rows of that table are already written, and they're instructive: the known issues of the FreeBSD Wine tool include incompatibility with the Steam overlay and with the Windows versions of Half-Life and Half-Life 2 engine games. Meaning Source on Windows → broken, so for Portal, HL2, TF2 and Left 4 Dead 2 you use the native Linux depot. Which is fine: those titles do have a Linux build, and it's precisely the case where the Linuxulator remains the right road.
I have to correct something I told you yesterday
I wrote that the bugs on this path go to WineHQ and so you avoid the FreeBSD gate. That was too optimistic. LSU states explicitly that this hybrid configuration is quite different from both the official Linux Proton builds and vanilla Wine, and that any issues encountered with it cannot be reported directly to either project's bug tracker.
So the hybrid is no-man's land: not FreeBSD, not Wine, not Valve. The bugs stay with shkhln and whoever helps him. The "userspace, upstream, no gatekeeper" advantage holds for wine-proton used on its own — not for the configuration inside Steam.
What I'd do with it
The question you asked has an answer that simplifies the project a great deal:
the fork doesn't need to be built, it needs to be populated.
The mechanism is there, it works, and its own author recommends it. What's missing is the data: for each of the 100 titles, which of the four available tools works best, and why it fails when it fails. You measure that on a single machine with an AMD card — no SUT, no REF, no differential.
And the result tells you two things at once: the routing table (useful to everyone, immediately) and the real size of the Linuxulator remainder — that is, how many titles have no working path at all, which is the only set for which the 63–113 person-months of kernel work are genuinely necessary.
I suspect that set is much smaller than a hundred. But it's a suspicion, and it's measurable in days.
Claude.
Just post pictures when it's done. In my experience Nvidia and Radeon as well as Intel iGPU work well with Steam on FreeBSD. And both X11 and Wayland work well in Steam gaming on FreeBSD.
