Vielleicht liegt bei OP ein grundlegendes Missverständnis bei der Entwicklung von WINE vor.
Die Entwicklung ist nämlich nicht monoton. Soll heißen: Wenn mit WINE 9.x eine Anwendung funktioniert, kann es gut sein, dass mit WINE 10.x die identische Anwendung nicht mehr funktioniert. Das hat man insbesondere bei stark mit dem Betriebsystem verdongelten Anwendungen, wie Office. Modernes Office funktioniert übrigens gar nicht mehr mit WINE, Felix hat es in allen Variationen probiert.
Daher wird jede Anwendung individuell betrachtet: Man fixiert eine bestimmte WINE-Version, man fixiert bestimmte Versionen für alle Abhängigkeiten, und sprinkelt dann noch einen Haufen DLL-Ersetzungen, Konfigurationseinstellungen und Registry-Einstellungen drüber (die letztern Sachen via WINE-Prefix). Jede Anwendung ist so gewisserweise nicht nur die Anwendung selbst, sondern auch der gesamte Dschungel an Abhängigkeiten gleich dazu. Das nennt sich dann eine WINE-Flasche (verstehste? verstehste? WINE wie in WEIN, also eine Weinflasche, wie die wo der Refosco drin ist! Eine WEINFLASCHE!). Jede unterschiedliche WINE-Version gibt es natürlich nur einmal auf dem System, wird jedoch mittels WINE-Flasche ausgewählt.
Wenn man nun Proton nimmt, wird das alles noch mal gesteigert. Dann hat man neben den WINE-Sachen auch noch eine Steam-Runtime (nicht der Steam-Klient! Suche nach "soldier", "sniper" etc., das bringt Sachen wie die glibc oder OpenSSL mit, insbesondere auch als 32-Bit-Versionen), DXVK, D3DVK, etc., alles in unterschiedlichen Versionen. Und dann hat man so Dinge wie den UMU-Launcher, welcher das alles irgendwie zusammendengelt, und dazu insbesondere Drölftausend Umgebungsvariablen setzt, weil die Spiele, die man über Steam und nicht via GOG etc. bezogen hat, auch gewisse Steam-Umgebungsvariablen einfach erwarten:
https://github.com/Open-Wine-Components/umu-launcher/blob/main/umu/umu_run.py#L821
Aber auch dort muss man alles einzeln für jedes Spiel unterschiedlich setzen, und ggf. noch mehr fixieren. Dementsprechend gibt es eine Datenbank an Fixier-Skripten:
https://github.com/Open-Wine-Components/umu-protonfixes/tree/master/gamefixes-steam
Und wenn man das alles so macht, dann kann man das auch ohne Steam-Klient spielen:
>Running non-Steam games with GE-Proton outside of Steam is only supported using umu
https://github.com/gloriouseggroll/proton-ge-custom
"Supported" heißt dabei nur, dass dafür Bug-Reports akzeptiert werden. Man kann sich das, was UMU macht, aber natürlich auch für jedes seiner Spiele mit einem Shell-Skript selber zusammendengeln. Dann funktioniert das mit entsprechendem Gefrickel natürlich auch, es ist nur "unsupported", aber funktionierend.
Hier noch der Teil, der verschwiegen wird: Wenn man ein Steam-Spiel hat, und das ohne Steam spielen will, muss man natürlich auch auf Linux + Proton-GE + UMU einen Kein-Dampf-Kräck (oder einen Steam-Emulator mittels DLL-Austausch) aus dem Internet dafür runterladen. Das wird natürlich verschwiegen, weil niemand sein Projekt in die Nähe davon stellen will, und sich am Ende noch Valves Zorn auf sich ziehen will.
Linux + Proton-GE + UMU ist jedenfalls die aktuelle Empfehlung.
>>163834Felix hat so ein Durchreichen an eine VM bei sich bislang nicht ausprobiert.
Von den Problemen mit der Intel iGPU hatte Felix bisher nichts gehört. Felix hörte immer nur, dass eine Kombination aus Intel iGPU (an dem dann auch tatsächlich der Monitor hängt) und eine durchzureichende AMD/Nvidia dGPU heutzutage fast gar keine Probleme mehr macht. Die Fenster-VM bzw. der Nvidia-Treiber in der Fenster-VM meldet in aktuellen Versionen noch nicht einmal mehr den Fehler 43. Ohne eigene Erfahrungen kann Felix dazu aber nichts sagen.