Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsValve reagiert auf Bugreport: Steam unterstützt ARM-Hardware nicht offiziell
Der Steam-Client für Linux wird derzeit nicht offiziell auf ARM-Hardware unterstützt. Das bestätigt ein Valve-Mitarbeiter im Rahmen eines Bugreports zum ARM64-Client auf einem AYN Odin 3 unter Armada OS. Den entsprechenden Fehlerbericht über ein Problem mit einem Videocodec hat Valve daher wieder geschlossen.
Alternative zu ArmadaOS wäre noch DroidDeck falls jemand Steam auf seinem Android Gerät ausprobieren will ohne ein OS einrichten zu müssen.
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Ich glaube die haben aktuell genug Baustellen mit der Frame und SteamOS sowie Proton.
Je nachdem wie weit die Frame dann mal vorangeschritten ist, wird das sicherlich auch noch kommen.
Siehe die Entwicklung von SteamOS. Bei Release des Decks, wurde ja auch bei Tests immer wieder erwähnt, das es noch viele Baustellen gibt. Schaut man sich heute die alten Tests an, sieht man wieviel sich dahin gehend schon weiterentwickelt hat.
Nur bedingt verwunderlich - Arm-Hardware ist ja leider ein extremer Wildwuchs. Device-Trees, viel zu oft kein Upstream-Support, selbst nach 15 Jahren ist ACPI nicht flächendeckend unterstützt. Dagegen ist die x86-Welt wunderbar homogen und einfach zu supporten
Ich will gar nicht nörgeln, sehe aber den Neuigkeitswert nicht ganz. Es gibt keinen offiziellen ARM-support. Ja, das kann man in 1-2 Minuten Recherche rausfinden. Und dass sie ein spezielles, eigenes Produkt supporten, heißt eben nur genau das. Was ist daran nun neu / erstaunlich?
Ist für die Leute, welche sich trotz A.I. Suche noch hierhin verirren, sowie jene, welche einfach casual-mäßig auf Steam spielen, sich aber weniger mit den genauen Entwicklungen beschäftigen, von belangen.
Ich bin da persönlich eher auf der Seite, jener, welche sich wohl etwas mehr auskennen (auf den Dunning Kruger-Berg wage ich mich kaum zu bewegen), doch eben drum weiß ich, dass Bugreports da relativ wenig bringen.
Vielleicht liegt das aber auch daran, dass ich von Linux und FOSS gewöhnt bin, dass ein Bugreport für Floorp unter Mint nichts bei den Leuten von openSUSE bringen würde, wenn das eigentliche Problem bei Mozilla und Firefox liegt.
Im Prinzip schon, ja. Allerdings ist meines (gefährlichen Halb-)Wissens nach der Anteil an SoCs bzw SBCs, welche Upstreamsupport und ACPI haben, deutlich höher als im Arm-Bereich. Ob das natürlich so bleibt, wenn sich RISC-V weiter verbreitet, bleibt abzuwarten - zu hoffen wäre es natürlich
Ist bei RISC-V potentiell genauso und potentiell sogar noch gravierender. Denn bei RISC-V ist das ISA bewusst modular ausgelegt, so dass dort (durchaus gewollt) viele optionale oder herstellerspezifische Erweiterungen des ISA gibt. Bei x86 ist das ISA dagegen sehr homogen und bei ARM zwar weniger homogen, aber durch die Architekturversionen/-profile definiert und nur sehr eingeschränkt herstellerspezifisches Extensions.
Valve macht wirklich viel für die Linux und Open Source community. Davon auszugehen, dass sie nun aber auch inoffizielle Forks supporten, geht dann vielleicht aber doch ein bisschen zu weit.
Wenn das Betriebssystem tatsaechlich von Valve ist und im Alpha-status, dann ist es eigenartig, dass der Bug Report geschlossen wird. Eigentlich sind Alpha- und Beta-Releases ja dazu da, damit das Produkt breiter getestet wird und die dabei gefundenen Fehler behoben werden, bevor der offizielle Release kommt.
Alpha oder Beta heißt aber auch nicht, dass alles Mögliche ein valider Bug ist. Das Ziel der aktuellen Entwicklung ist ja nicht die allgmeine Unterstützung von ARM und daher sind dahingehende Inkompatibilität schlicht auch kein Bug, sondern quasi gewollt.
Wenn Valve irgendwann Richtung allgemeiner ARM-Unterstützung geht, wird es dafür entsprechend eine eigene Alpha-/Betaphase geben, wo man dann solche Bugs melden kann.
Bei einem Spiel im Early Access, welches für x86 (und Windows) entwickelt wird, meldet man es ja auch nicht als Bug, wenn es auf einem Mac mit ARM-SoC nicht läuft.
Nur bedingt verwunderlich - Arm-Hardware ist ja leider ein extremer Wildwuchs. Device-Trees, viel zu oft kein Upstream-Support, selbst nach 15 Jahren ist ACPI nicht flächendeckend unterstützt. Dagegen ist die x86-Welt wunderbar homogen und einfach zu supporten
Steam als Software im Userspace sollte mit Devicetrees nichts am Hut haben. Das ganze Hardwaregeraffel zu abstrahieren ist Aufgabe vom Betriebssystem. Erwähnt wird hier V4L2[1], was eine ebensolche, abstrahierte Schnittstelle ist.
RISC-V ist erstmal nur eine ISA, also definierte Befehle/Verhalten für eine Prozessorarchitektur und ist großartig unabhänig von einer Verhaltens-/Schnittstellendefinition wie es ACPI ist. Der Offenheit geschuldet kann ein Jeder die RISC-ISA nehmen und die wildesten Dinge damit implementieren.
Grundlegend gibt es aber Spezifikationen[2], wie sich RISC-V Implementierungen verhalten sollten, die "große"[3] Betriebssysteme unterstützen sollen. BSR-I ist quasi ein "System initialisiert sich über UEFI, übergibt ans Betriebssystem und dieses kann unter Nutzung von ACPI alles an Hardware initialisieren was zum Booten notwendig ist". Hardwaregeraffel, welches nicht zwingend zum Booten notwendig ist, ist davon aber nicht berührt.
BSR-B ist dann der ACPI ist optional Wildwuchs. Der lustugerweise auf die ARM EBBR Spec verweist (Embedded Base Boot Requirements).
[2] https://docs.riscv.org/reference/brs/v1.0/recipes.html
[3] RVA20 ist eine Spezifikation, die mehrere ISA-Erweiterungen vorschreibt, die als notwendig angesehen werden können um Linux, BSD und Ähnliches sinnvoll nutzen zu können.
@Piktogramm Genau das meinte ich ja, wollte es nur fürs grobe Verständnis nicht technisch detailiert ausführen. Bei RISC-V ist es halt, durchaus gewollt, so, dass die Hersteller von RISC-V CPUs/SOCs halt abseits der einheitlichen, aber überschaubaren, Kernspezifikation recht viel eigene Süppchen kochen, was ihre CPU darüber hinaus kann/macht.
Die Problemtaik sieht man auch ganz gut an Ubuntu. Sie unterstützen zwar mittlerweile offiziell auch RISC-V als Architektur, aber eben nicht allgemein, sondern nur ein paar ganz bestimmte Modelle. Bei ARM ist das dann nicht ganz so extrem, da man dort mit dem Bedienen einer Architekturversion bzw. einen Profil (bspw. ARMv7, AArch64) direkt ARM-CPUs von diversen Herstellern abdeckt, die diese Version bzw. diese Profil implementieren.
Naja Termy hat mit ACPI/DTs angefangen, was an der Stelle des Problems aus der Meldung keine Rolle spielt. Du hast das ganze um ISA-Profile erweitert, was bei ACPI/DTs keine Rolle spielt und auch bei Problem der eigentlichen Meldung nicht. Die Darstellung von irgendwas "Groben" samt Bezug verwürfelt halt witzig Dinge und ist so einfach falsch.
V4L2 hat mit ACPI/DTs nix zu tun
An sich haben damit ARM/RISC-V Profile damit nix zu tun
Die ISA hat schlicht wenig bis nichts mit der Nutzung von ACPI/Devicetrees zu tun.
Steam unter ARM hat Problemchen V4L2 vollumfänglich zu nutzen.
mibbio schrieb:
Architekturversion bzw. einen Profil (bspw. ARMv7, AArch64)
Bei X86 gibts ebenso Targets v1, v2, v3, v4. Bei RISC-V wären es dann RVA20 (Minimum für die Bootspec) oder RVA23 (Minimum von Ubuntu).
mibbio schrieb:
an Ubuntu. Sie unterstützen zwar mittlerweile offiziell auch RISC-V als Architektur, aber eben nicht allgemein, sondern nur ein paar ganz bestimmte Modelle.
Die aktuellen Ubuntu Images wollen halt RVA23 als Profil. Das Profil wurde Ende 2024 verabschiedet und es gibt einfach sehr wenige RISC-V CPU Designs, die das Profil voll unterstützen. Das liegt also nicht am Mangel an Profilen bei RISC-V, sondern ist ein Effekt der Voraussetzung eines eben solchen Profils.
Wobei die RISC-V CPUs ganz witzig sind beim Booten. Das Uefi stellt die DTs dem Betriebssystem bereit anstatt, dass das OS die DTs vorhalten muss. Wäre zwar schöner, wenn es gleich ACPI Tabellen gäbe, aber immerhin gibt es so etwas Flexibilität.
Steam? AV1 support? Bei mir läuft das steam recording noch mit h.264 weil der keinen hardware encoder für h.265 findet und software garnicht anbietet. Von AV1 ist da nirgends was zu sehen.
Mit OBS funktioniert auch AV1 (via vaapi). Scheint als würde Steam da auch kein AMD unterstützen.
Anfangs dachte ich noch ok, die 9070 ist ja neu und so. Aber das ist schon eine weile her und bei Steam hat sich nichts daran geändert.
Wenn OBS jetzt noch einen ton von sich gäbe wenn die aufnahme anfängt, oder gar ein popup im steam overlay dazu :/
alternativ könnte steam natürlich auch mal nachziehen, an sich wäre das integrierte feature ja nett wenn es denn nicht auf einem 15 Jahre alten video codec hängen geblieben wäre. Sieht halt echt nicht hübsch aus mit den möglichen einstellungen auf h.264.
