News Herr der RGB-Ringe: OpenRGB erreicht Version 1.0

Erkennt mein MB und damit den 4PIN Anschluss seit einem Bios Update leider nicht mehr. Armory Crate lädt nicht beim Start ubd ich muss die Farbe immer händisch setzen. RGB nervt mich daher. Selbst wenn es mal funktioniert hat, ging das dann plötzlich zwei Tage später nicht mehr.
 
will-lee schrieb:
Erkennt mein MB und damit den 4PIN Anschluss seit einem Bios Update leider nicht mehr. Armory Crate lädt nicht beim Start ubd ich muss die Farbe immer händisch setzen.
Du versuchst Armory Crate und OpenRGB gleichzeitig zu benutzen? Der Sinn von OpenRGB ist, auf solche herstellereigenen Lösungen komplett verzichten zu können.
 
  • Gefällt mir
Reaktionen: conglom-o
@xexex Nein, sorry. Falsch ausgedrückt: Hab Armoury Crate genutzt, nachdem openRGB nicht mehr ging.
Hab aber für Armoury Crate eine Lösung gefunden. Man muss die LastProfile.xml auf Read Only setzen. Damit geht es bei mir.
 
  • Gefällt mir
Reaktionen: xexex
Hatte es vor einer Weile mal ausprobiert. An sich ein guter Ersatz, leider bietet es bei der Effekt-Logik nicht so viel Spielraum, wie ich gerne haben würde - bspw. Tasten in einer Farbe, und dann eine andere Farbe mit Fade-out bei Tastendruck... konnte ich zumindest nicht so einstellen wie bei der Hersteller-Software selbst. Werde es in Zukunft nochmals ausprobieren.
 
DarkSoul schrieb:
Nö, nicht zwingend.
Ich schrieb ja auch:
Wer natürlich nur seine Beleuchtung abschalten will oder statisch in einer Farbe leuchten lassen will, der ist vermutlich mit OpenRGB besser beraten.
Keine Frage für mich, für anständige Spieleunterstützung oder umfangreiche Effekte ist SignalRGB die erste Wahl, aber viele wollen einfach nur irgendwelche unnützen Lämpchen abschalten.
 
Shotaro schrieb:
Gibt zahlreiche Berichte über gefraggte RAM Module durch schreiben falscher Werte ins SPD.
Das kann eigentlich nur passieren, wenn man im BIOS Schreibzugriff auf den SPD gewährt, bei manchen Boards über eine Einstellung wie "SPD Write Disable = false". Das sollte in jedem Fall IMMER unterlassen werden, da dieser Schreibzugriff grundsätzlich ein Risiko darstellt und vermutlich nur für Extrem-Übertakter und Tester, die während der Laufzeit solche Werte manipulieren wollen, interessant ist. Regulär sollte der SPD "Read-Only" sein. Mir ist kein Board bekannt, bei dem dieser Schreibzugriff standardmäßig aktiviert ist.
 
SaschaHa schrieb:
Das kann eigentlich nur passieren, wenn man im BIOS Schreibzugriff auf den SPD gewährt, bei manchen Boards über eine Einstellung wie "SPD Write Disable = false". Das sollte in jedem Fall IMMER unterlassen werden,
Korrigiere mich wenn ich falsch liege, aber meines Wissens läuft die Ansteuerung von RGB RAM Modulen genau darüber. Schaltest du es ab, gibt es keine RGB Effekte.
 
@xexex
Meines Wissens nach wird nur auf den SMB zugegriffen, über den dann die Steuerung läuft. Dieser ist sowohl mit dem SPD, als auch mit dem RGB-Controller verbunden, und nur letzterer ist für die Steuerung relevant. Wenn aber der Schreibzugriff auf den SPD aktiviert ist und falsche Parameter an den SMB gesendet werden, kann es zu solchen Beschädigungen kommen, ansonsten nicht.

Eine Korrektur an meiner vorherigen Aussage muss ich aber vornehmen: Die BIOS-Einstellung für den Schreibschutz des SPD scheint nicht zwangsläufig bei allen Boards zu existieren, und ob der Schreibschutz standardmäßig aktiviert oder deaktiviert ist, kann ich auch nicht abschließend sagen, da im Netz unterschiedliche Informationen diesbezüglich existieren. Bei den meisten Boards scheint es diese Option wohl zu geben und der Schreibschutz scheint dort auch standardmäßig aktiviert zu sein, aber festlegen kann ich mich aufgrund der widersprüchlichen Angaben nicht. Boards, bei denen dieser Schreibschutz also nicht existiert bzw. nicht aktiviert ist, sind also tatsächlich potenziell gefährdet. Das dürfte wohl vor allem ältere Boards mit alten BIOS-Versionen betreffen.
 
Zuletzt bearbeitet:
SaschaHa schrieb:
Meines Wissens nach wird nur auf den SMB zugegriffen, über den dann die Steuerung läuft.
Es wird über den SMBus in den SPD-EEprom geschrieben damit RGB Effekte erzeugt werden. Der Grund wieso irgendeine Version von OpenRGB irgendwelche RAM Module geschrottet hat, kam nicht daher weil die Software willkürliche Speicheradressen beschreibt, sondern weil scheinbar die Ansteuerung eines solchen Moduls fehlerhaft war.

Ich bin völlig bei dir mit der Aussage, man sollte die Schreibfunktion im UEFI deaktivieren, wobei das zumindest bei ASUS immer standardmäßig der Fall ist. Der Grund wieso einige Nutzer die Funktion aber aktiviert haben, ist weil sie für die Blinkeffekte notwendig war.

Ich kenne jetzt nicht jeden Hersteller und jedes Modul einzeln, bei Corsair heißt es aber zum Beispiel auf der Webseite.
Wenn Sie die RGB-Steuerung über den RAM auf Ihrem ASUS Z690-Motherboard aktivieren möchten, müssen Sie SPD Write im System-BIOS aktivieren.
....und auch.
Hinweis: Ab iCUE 4.29.203 erfordert die DRAM-Beleuchtungskonfiguration nicht mehr, dass Benutzer den SPD Write-Zugriff im BIOS aktivieren, um die volle iCUE-Funktionalität zu erhalten.
https://help.corsair.com/hc/de/arti...ich-SPD-Write-auf-Ihrem-ASUS-Z690-Motherboard

Es war also zumindest dort noch vor zwei Jahren notwendig und es wird vermutlich noch immer Module/Hersteller geben, wo es bis heute der Fall ist.
 
  • Gefällt mir
Reaktionen: SaschaHa
@xexex
Das Thema scheint mir sehr komplex zu sein, daher habe ich meinen letzten Antwort-Ansatz verworfen. Wie die Hardware-Hersteller RGB implementieren, scheint proprietär zu sein. Bei meinen G.Skill-Modulen wird RGB glücklicherweise ohne SPD-Zugriff angesprochen (so, wie es sein sollte), weshalb diese Module "safe" sind. Bei manch anderen Modulen scheint das anders zu sein, damit ist dein Warnhinweis natürlich berechtigt und sinnvoll.

Ich versuche mal, unsere beiden Argumentationen auf einen Nenner zu bringen:
  • ohne SPD-Schreibschutz geht man (generell) Risiken ein, die man nicht eingehen sollte
  • mit SPD-Schreibschutz ist man auf der sicheren Seite, aber die LED-Beleuchtung bestimmter RAM-Module lässt sich dann möglicherweise nicht mehr steuern (egal mit welcher Software)
  • Software wie OpenRGB, die auf Reverse-Engineering setzt, birgt (ohne SPD-Schreibschutz) höhere Risiken als Hersteller-Software
  • dieses proprietäre Wirrwarr, das unnötige Risiken oder Einschränkungen birgt, ist Mist
 
  • Gefällt mir
Reaktionen: xexex
Man muss den Entwicklern schon mal gratulieren, nach all den Jahren der Entwicklung hat man die Software nun endgültig zu Schrott verwandelt.
Ich werde in Zukunft auch Software (Fan Control, OpenRGB) meiden, die auf diesen PawnIO-Mist aufsetzt. Einen Kerneltreiber über dessen Sicherheitslücken, die dieser reißt, nichts bekannt ist.
OpenRGB ist somit keine Empfehlung mehr!
 
Wie willst du wissen dass da Lücken drin sind wenn keine bekannt sind? Jede Software kann Lücken haben und die wird dann behoben und gut ist es.
 
Lass mal gut sein....
Das reicht mir schon......
FanControl undd OpenRGB werde ich zukünftig nicht mehr nutzen.
Screenshot 2026-09-18.png


https://github.com/namazso/PawnIO.Setup/issues/1
 
Find ich gut, das Ding unterstützt jetzt auch das Mystic Light von meinem X870 Tomahawk.
Ich musste zwar ein bisschen rumprobieren, bis ich die richtige Anzahl LEDs und den richtigen Anschluss für den Heatkiller auf meine 5090 gefunden habe, aber jetzt kann ich endlich das blöde MSI-Center runterschmeißen, das ich nur für die Graka-LEDs noch in Betrieb hatte.
 
Hatte eine alte 0.9 Version die bestimmt ein Jahr alt ist mit der lief eigentlich alles und alle kommenden danach 0.9 ginge nicht mehr mit meinem Mainboard. Die 1.0 geht jetzt auch wieder
 

Ähnliche Themen

Gamescom
Zurück
Oben