Hobbinho
Kabelverknoter(in)
Dann ergänze ich gerne weil ich das gedanklich implizierte:
Secure Boot läuft auch.
Special Steam unter Linux: Mehr Leistung durch Proton-Startoptionen
- Ersteller PCGH_Sven
- Erstellt am
Secure Boot läuft auch.
Registrierzwang
Software-Overclocker(in)
Hobbinho
Kabelverknoter(in)
Habe nicht geschrieben das ich das Problem so gelöst habe, um mal deinen Kommentarstil aufzugreifen.
Hyourinmaru
Komplett-PC-Käufer(in)
Spielt keine Rolle, man muss nur die Distro für Secure Boot hinbekommen und dann ist man für diese Boot-Kette selbst der Root-of-Trust. Ein installiertes Windows funktioniert weiterhin mit der Microsoft-CA und deren Zertifikate, wenn die Microsoft-Schlüssel im UEFI beibehalten werden.
Dann hätte man Secure Boot damals in der UEFI Spezifikation so beschreiben müssen, dass der Benutzer gar nicht die Möglichkeit hat, die aktiven Variablen zu verändern.
Da stimme ich dir zwar zu, allerdings ist die assistierte Methode mit
sbctl wesentlich angenehmer und einfacher als das alles uständlich per Hand zu machen. Ich weiß, wovon ich Rede, denn ich hab das selber so gemacht.Am einfachsten wäre es, wenn die Zertifikate und Schlüssel von Ubuntu, Debian, Fedora und openSUSE, mit denen GRUB und der Kernel signiert werden, direkt ins UEFI reingeladen würden, über fwupd oder was auch immer.
Das CachyOS-Wiki bietet aber schon eine ziemlich gute Anleitung. Wie gut die für Anfänger aber geeignet ist, sei mal dahingestellt.
TeSla67
Freizeitschrauber(in)
Was SecureBoot bei CachyOS angeht finde ich das relativ einfach zu händeln.
Knackpunkt war eher das BIOS in den Setup Mode zu bekommen, hat sich aber mittlerweile auch erledigt weil die Anleitung nachgebessert wurde. Hab's heute dann zum zweiten mal gemacht und das ganze hat gefühlt 1 min gedauert.
Knackpunkt war eher das BIOS in den Setup Mode zu bekommen, hat sich aber mittlerweile auch erledigt weil die Anleitung nachgebessert wurde. Hab's heute dann zum zweiten mal gemacht und das ganze hat gefühlt 1 min gedauert.
Tekkla
Volt-Modder(in)
Also dann bitte auch ein Windows Test ohne DirectX!
Hyourinmaru
Komplett-PC-Käufer(in)
Ist denn Wine anstelle von Proton erlaubt?
joecnstr
Freizeitschrauber(in)
Hmmm also auf Proton zu verzichten wird sehr schwer. Wie andere bereits sagten: Ggf nur mit Wine gamen? Oder geht es dir um native Linux Spiele (also ELF binaries statt "exe", mit Linux Bibliotheken statt DirectX etc)?
Für mich spricht wenig gegen die Nutzung von Proton. Ja, es kommt von Steam/Valve, aber es ist ja auch ohne Steam nutzbar. Sogar Open Source.
Was übrigens auch für Proton und gegen native binaries spricht: Die Linux Varianten der Spiele werden oft nur kurz und schlecht gewartet. Viele haben zum Beispiel jetzt schon Probleme mit neuen SDL libs. Es wird tatsächlich eher empfohlen die Windows Version + Proton zu verwenden...
inhuman_nature
Software-Overclocker(in)
Oja, oder: wie laufen native Linux Spiele(-Versionen) unter Windows ...Also dann bitte auch ein Windows Test ohne DirectX!
ChrisMK72
PCGH-Community-Veteran(in)
Ich find' es megaklasse, dass ich auch AMD Anti-Lag ohne Framegeneration einschalten kann.
Ohne das command:
Mit command:
Geilomat!
^^
Hab für meinen Fall diese commandzeile zurechtgefriemelt:
ENABLE_LAYER_MESA_ANTI_LAG=1 PROTON_FSR4_UPGRADE=1 MANGOHUD=1 %command%
(Für 9000er GPU)
Ohne das command:
Mit command:
Geilomat!
^^Hab für meinen Fall diese commandzeile zurechtgefriemelt:
ENABLE_LAYER_MESA_ANTI_LAG=1 PROTON_FSR4_UPGRADE=1 MANGOHUD=1 %command%
(Für 9000er GPU)
_Oskar_
Software-Overclocker(in)
Ich sach ja, langsam langsam entwickelst Du dich zu einem guten Linuxer, und das Du voll bei der Sache bist und vieles ausprobierst und tüftelst und nicht aufgibst, richtig so !
TOP
Denk immer daran: Aufgeben ist niemals eine Option. ^^
Sooo, nun ein Kühles Bierchen
inhuman_nature
Software-Overclocker(in)
Cool, dass Anti-Lag aktivierbar ist und zu funktionieren scheint! Sehr schön! Ist es beim Zocken zu sehen/spüren?Ich find' es megaklasse, dass ich auch AMD Anti-Lag ohne Framegeneration einschalten kann.
Ohne das command:
Anhang anzeigen 1517559
Mit command:
Anhang anzeigen 1517570
Geilomat!
Hab für meinen Fall diese commandzeile zurechtgefriemelt:
ENABLE_LAYER_MESA_ANTI_LAG=1 PROTON_FSR4_UPGRADE=1 MANGOHUD=1 %command%
(Für 9000er GPU)
Cleriker
PCGH-Community-Veteran(in)
Weil?Also dann bitte auch ein Windows Test ohne DirectX!
Klar.
Ne, mir geht's nicht um native Linux Spiele.
Mir geht's darum zu sehen wie gut Linux selbst inzwischen zum spielen geeignet ist, nicht irgendwelche zusätzliche Software bei der man sich anhängig von bestimmten Herstellern macht.
Also was leistet Linux selbst?
Ich traue valve bedeutend weniger als Microsoft und denen traue ich schon nicht weit. Deshalb interessiert mich, wie gut es ohne valve geht. Auf windows ist es nicht tragisch, darauf zu verzichten. Valve ist der Grund warum wir heute DRM haben und es überhaupt zu sowas wie kernelaccess Lösungen kommen konnte und ich fände es sehr schade wenn Linux auch dahin gebracht wird.
Das ist auch mein Eindruck, aber wie es eben so mit Eindrücken ist, sind die subjektiv und mich würde eine neutrale Bewertung interessieren.
Mit wine habe ich schon viel Erfahrung gesammelt über die Jahre. Angefangen mit dem gothic 3 Release damals 2006.
Zuletzt bearbeitet:
RetroSchrauber
Komplett-PC-Käufer(in)
@PCGH_Sven Das ist mir jetzt erst aufgefallen aber der Tipp zu ProtonForge kommt von @The_Invisible84 und nicht von mir!
joecnstr
Freizeitschrauber(in)
Also ich bin immer noch nicht sicher, ob ich verstanden habe was du meinst.
"Also was leistet Linux selbst" : Wenn Linux "es selbst leisten" soll beim Gaming, dann verstehe ich es so, dass die Frage wäre, ob es APIs gibt um Games unter Linux entwickeln / laufen lassen zu können - klar gibt es das:
Für die Grafik wäre es OpenGL (gibt es schon ewig für Linux) oder, moderner, Vulkan. Ist einfach wie DirectX, nur halt nicht von Microsoft, vereinfacht gesagt. Für den Sound gibt es ALSA/Pipewire. Für Eingabegeräte evdev / SDL.
Das Problem ist: Nur wenige Entwickler fokussieren sich auf Linux. Und eigentlich würde es schon enorm helfen, wenn z.B. die Engines einfach Vulkan statt DirectX verwenden würden... Aber genau genommen hält dich niemand davon ab, Games direkt und optimiert für Linux zu entwickeln.
Beim Thema "kurz und schlecht gewartet": Ja, das ist ein Eindruck von mir, der aber offenbar häufig bestätigt wird. Persönlich kann ich zB. nennen: Tomb Raider (LInux Version) lief nicht mehr bei mir out-of-the box und Guacamelee eingschränkt (ohne Controller). Wie erwähnt, es liegt oft an den SDL libs (siehe z.B. https://steamcommunity.com/app/203160/discussions/0/1640917196998417668/?ctp=11#c2257935717969075935 )
Amüsant finde ich deine Aussage, dass du Valve weniger traust als Microsoft. Du weisst schon, warum Valve diese riesige Investition in Linux / SteamOS macht? Richtig - weil es katastrophal für ihr Geschäftsmodell ist, komplett vom Goodwill von Microsoft abhängig zu sein. Hat MS mal keine Lust mehr auf Steam könnten sie es ja problemlos aussperren und Valve stände mit heruntergelassenen Hosen da. Oder man stelle sich mal vor, MS führt ein Abo-Modell für Windows ein... Die Gamer würden den PC scharenweise verlassen.
Bezüglich DRM und Steam möchte ich, wie jedes mal wenn dieser Punkt kommt, festhalten: Die Publisher entscheiden, welchen DRM sie auf Steam verwenden. Das kann alles zwischen gar kein DRM sein (jaaaa, das gibt es...) und Kernel Level Anti-Cheat. Dieses wird übrigens niemals in Linux gelangen weil das fundamental gegen die Paradigmen des Kernels ist (Userspace bleibt Userspace und Kernelspace bleibt Kernelspace)
Und wie gesagt, Proton ist open source. Was wir jetzt haben, kann uns nicht mehr genommen werden. Gib einfach "git clone https://github.com/ValveSoftware/Proton.git" ein und Proton, in seinem aktuellen Stand, ist dein.
Kann ich leider auch nur bestätigen.
joecnstr
Freizeitschrauber(in)
Aber nochmal zurück zum Thema Startoptionen, mir ist da aufgefallen dass ich Mangohud bisher ein bisschen anders integriere als hier beschrieben.
Bisher habe ich immer "mangohud %command%" verwendet (also den manghud-Befehl) statt "MANGOHUD=1 %command%" (also die Umgebungsvariable).
Ist das gleichwertig oder sollte man die eine oder andere Variante bevorzugen?
Bisher habe ich immer "mangohud %command%" verwendet (also den manghud-Befehl) statt "MANGOHUD=1 %command%" (also die Umgebungsvariable).
Ist das gleichwertig oder sollte man die eine oder andere Variante bevorzugen?
Gute Frage. Tippe mal, dass es gleichwertig ist. Ich kann mir schlecht vorstellen, dass Proton noch mal eine Extrafassung von MangoHUD im Gepäck hat und würde davon ausgehen, dass einfach die im System vorhandene gestartet wird. Müsste man wohl mal auf einem System testen, auf dem kein MangoHUD installiert ist.
joecnstr
Freizeitschrauber(in)
Also vermutlich ist die Variante "MANGOHUD=1" stabiler/sicherer. Denn wenn z.b. mangohud nicht sauber funktioniert, könnte es das Spiel ggf. nicht starten oder durch mangohud crashen (Bei "mangohud %command%" sollte ja, wenn ich mich nicht täusche, das Spiel durch mangohud geforked werden). Mit der Umgegungsvariable "MANGOHUD=1" würde halt schlimmstenfalls einfach nix passieren, das Spiel aber trotzdem starten.
Aber bei mir funktioniert beides problemlos, ist wohl eher eine akademische Frage
Ich glaube nicht, dass es wirklich einen anderen Weg gibt, MangoHUD zu nutzen und würde vermuten, dass auch Proton unter der Haube nichts anderes macht, als den Befehl voranzusetzen, wenn die Variable gesetzt ist.
Solange es tut, was es soll, könnte man das wohl durchaus sagen.Aber bei mir funktioniert beides problemlos, ist wohl eher eine akademische Frage
Ähnliche Themen
