OpenRGB Setup

netzgestaltung

Captain
Registriert
Jan. 2020
Beiträge
3.226
Hi,

also bei mir will OpenRGB nicht so richtig laufen.

Installiert ist es derzeit als RPM-Paket via Copr Repo: https://copr.fedorainfracloud.org/coprs/name/OpenRGB/
Ebenfalls probiert wurde Installation als Flatpak.

Jedenfalls bin ich ansonsten diesen Guide durchgegangen: https://gitlab.com/CalcProgrammer1/OpenRGB#linux incl UDEV rules und Kernel Parameters. Das letzte Mal (von ~3 Versuchen) ist aber schon eine Weile (1-2 Jahre) her.

Was gäbe es zu beleuchten oder auszuschalten(!):
  • CPU Kühler (Prism Wraith? Hörte letztens da gibts unterschiedliche Boxed Kühler, welchen hab ich?) - konnte den im Bios(UEFI) irgendwie ausschalten, der hat immer Rot geleuchtet.
  • Graka: ASUS DUAL-RX6700XT-O12G https://geizhals.at/asus-radeon-rx-6700-xt-dual-90yv0g83-m0na00-a2616100.html - leuchtet weis...
  • Der Soundblaster-Z "Sound Core3D[Sound Blaster Recon3D/Z-Series](SB1570 SB AudigyFx)" leuchtet rot, würd ich auch gern mal ausschalten.
  • Mobo: Asus Prime B450-Plus
  • Maus: Logitech G502 Hero

Klicks auf irgendwas bewirken irgendwie nichts, es setzt sich immer wieder auf diesen Zustand zurück.

Das zeigt mir OpenRGB:
1673694076480.png


1673694087035.png


1673694109607.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: polyphase
netzgestaltung schrieb:
Das zeigt mir OpenRGB:
Hast du mal links ein Gerät ausgewählt und dann zusätzlich die gewünschte Zone?
 
Also für den anfang hab ich mal selbst auf https://copr.fedorainfracloud.org/coprs/name/OpenRGB/ gelesen:
Attention!

This Copr is deprecated as Fedora now includes OpenRGB in its main repository. Please disable this Copr and install the Fedora version:
sudo dnf copr disable name/OpenRGB; sudo dnf reinstall openrgb
werd ich später probieren, erwarte mir davon aber keine Lösung.
Ergänzung ()

Die Screenshots sind mit ausgewähltem Gerät, das Zone Dropdown ist leer -> [ ] da gibt es keine Auswahl (genauso wie das LED Dropdown)

Bash:
sudo dnf copr disable name/OpenRGB
sudo dnf reinstall openrgb
hab ich gleich mal erledigt, brachte keine änderung.
 
Zuletzt bearbeitet:
Hi,

beim COPR Paket steht:

This Copr is deprecated as Fedora now includes OpenRGB in its main repository. Please disable this Copr and install the Fedora version:


sudo dnf copr disable name/OpenRGB; sudo dnf reinstall openrgb

Gesehen?

Ansonsten folgt, wie ich es bei mir eingerichtet habe:

Vorwort:
Ich habe ein MSI Board und Fedora 37.

1. OpenRGB als RPM Paket über dnf von Fedora Repo installiert, Aktuelle Version ist 0.8, Build Date 28.11.22
2. Gemäß der Anleitung auf Gitlab:

  • Load the i2c-dev module: sudo modprobe i2c-dev
  • Load the i2c driver for your chipset: sudo modprobe i2c-piix4 (für AMD)
  • List all SMBus controllers: sudo i2cdetect -l
Anmerkung: Damit der dritte Befehl funktioniert, musste ich zunächst i2c-tools aus dem Fedora Repo installieren

Screenshot_20230114_135032.png

  • Laut Anleintung sind die wichtigen Einträge für AMD die mit PIIX4, ich habe 3. Einträge merken.
  • Give user access to those controllers: sudo chmod 777 /dev/i2c-xx (bei mir i2c-09, i2c-10 und i2c-11)
  • Neustart
  • Rescan Devices beim OpenRGB
Screenshot_20230114_135457.png

Je nach Mode kannst du zusätzlich Zonen/einzelne LEDs ansteuern. Bei Rainbow z.B. sind die oberen Felder leer, was logisch ist. Wähle ich z.B. den Mode "Direct", kann ich alle einzelnen LEDs auswählen und steuern etc.

Screenshot_20230114_140443.png


Über das Systray Icon kann ich mit dem Eintrag "Lights off" RGB komplett ausschalten. Über den Punkt Profiles mein Profil laden und RGB wieder aktivieren. Einen "einfachen" On Switch gibt es so nicht. Man braucht ein Profil. In den Optionen habe ich eingestellt, dass er beim Login OpenRGB starten und mein Profil automatisch laden soll.


Hast du die Anmerkungen bzgl. Asus in der Anleitung gesehen und gegebenenfalls befolgt?

ASUS and ASRock motherboards have their RGB controller on a secondary SMBus interface and requires a Linux kernel > 5.7 commit
 
Zuletzt bearbeitet:
schM0ggi schrieb:
siehe #3
Code:
user@localhost:~$ uname -r
6.0.18-300.fc37.x86_64

die Befehle schau ich später durch
 
Also:
Code:
user@localhost:~$ uname -r
6.0.18-300.fc37.x86_64
user@localhost:~$ sudo modprobe i2c-dev
[sudo] Passwort für user:
user@localhost:~$ sudo modprobe i2c-piix4
user@localhost:~$ sudo i2cdetect -l
i2c-0    i2c           AMDGPU SMU 0                        I2C adapter
i2c-1    i2c           AMDGPU SMU 1                        I2C adapter
i2c-2    i2c           AMDGPU DM i2c hw bus 0              I2C adapter
i2c-3    i2c           AMDGPU DM i2c hw bus 1              I2C adapter
i2c-4    i2c           AMDGPU DM i2c hw bus 2              I2C adapter
i2c-5    i2c           AMDGPU DM i2c hw bus 3              I2C adapter
i2c-6    i2c           AMDGPU DM aux hw bus 0              I2C adapter
i2c-7    i2c           AMDGPU DM aux hw bus 1              I2C adapter
i2c-8    i2c           AMDGPU DM aux hw bus 2              I2C adapter
i2c-9    i2c           AMDGPU DM i2c hw bus 0              I2C adapter
i2c-10    i2c           AMDGPU DM i2c hw bus 1              I2C adapter
i2c-11    smbus         SMBus PIIX4 adapter port 0 at 0b00    SMBus adapter
i2c-12    smbus         SMBus PIIX4 adapter port 2 at 0b00    SMBus adapter
i2c-13    smbus         SMBus PIIX4 adapter port 1 at 0b20    SMBus adapter

in der Gitlab Anleitung steht:
Give user access to those controllers. If you have not installed OpenRGB from a package (e.g. deb, RPM or from the AUR) then most likely you need to install the UDEV rules.

Es steht da nix von 777 oder wie auch immer access gewährt werden soll und wozu ich die nummern(i2c-11, i2c-12, i2c-13) notiere. Was ich auch normal nirgends vergeben würde. Alternativen zu "jeder darf alles" und wird das nicht von einem Dist-Upgrade überschrieben? Woher weißt du das der Ort /dev/i2c-xx ist?
Ergänzung ()

Habe jetzt als alternative gefunden, meinen User der i2c Gruppe hinzuzufügen, da diese oft Gruppenberechtigungen für /dev/i2c* hat
Bash:
user@localhost:~$ sudo usermod -a -G i2c user
[sudo] Passwort für user:
usermod: Gruppe »i2c« existiert nicht.
user@localhost:~$ groups
user wheel video vboxusers fuse
user@localhost:~$ sudo groups
root vboxusers
Quelle: https://raspberrypi.stackexchange.com/questions/51375/how-to-allow-i2c-access-for-non-root-users

Aber:
Bash:
user@localhost:~$ ls -l /dev/i2c*
crw-rw----+ 1 root root 89,  0 13. Jän 08:09 /dev/i2c-0
crw-rw----+ 1 root root 89,  1 13. Jän 08:09 /dev/i2c-1
crw-rw----+ 1 root root 89, 10 13. Jän 08:09 /dev/i2c-10
crw-rw----+ 1 root root 89, 11 13. Jän 08:09 /dev/i2c-11
crw-rw----+ 1 root root 89, 12 13. Jän 08:09 /dev/i2c-12
crw-rw----+ 1 root root 89, 13 13. Jän 08:09 /dev/i2c-13
crw-rw----+ 1 root root 89,  2 13. Jän 08:09 /dev/i2c-2
crw-rw----+ 1 root root 89,  3 13. Jän 08:09 /dev/i2c-3
crw-rw----+ 1 root root 89,  4 13. Jän 08:09 /dev/i2c-4
crw-rw----+ 1 root root 89,  5 13. Jän 08:09 /dev/i2c-5
crw-rw----+ 1 root root 89,  6 13. Jän 08:09 /dev/i2c-6
crw-rw----+ 1 root root 89,  7 13. Jän 08:09 /dev/i2c-7
crw-rw----+ 1 root root 89,  8 13. Jän 08:09 /dev/i2c-8
crw-rw----+ 1 root root 89,  9 13. Jän 08:09 /dev/i2c-9
zeigt root als gruppe an, nicht i2c.

Hier wird als Gruppe video genommen, der Zusammenhang erschließt sich mir nicht:
https://ask.fedoraproject.org/t/openrgb-is-not-working-i2c-piix4-is-not-detected-loaded/20816/4
 
Zuletzt bearbeitet:
Es steht, dass du User Rechte für die, bei AMD, PIIX4 Controller vergeben musst, wenn du nicht mit root arbeitest (was in der Regel der Fall ist). 777 war ein Beispiel und ist aus der älteren Anleitung von Github entnommen.

https://github.com/fjardon/OpenRGB#smbus-access
Give user access to those controllers, for instance: sudo chmod 777 /dev/i2c-0

Es reicht natürlich aus, wenn du 666 nimmst. Damit fügst du ja den bestehenden Rechten rw für den Rest hinzu (also auch deinem User).

You'll have to enable user access to your SMBus if you don't run as root.
  • List all SMBus controllers: sudo i2cdetect -l
  • Note the number for PIIX4, I801, and NCT6775 controllers.
  • Give user access to those controllers. If you have not installed OpenRGB from a package (e.g. deb, RPM or from the AUR) then most likely you need to install the UDEV rules.

root ist in den Berechtigungen dort standardmäßig hinterlegt (zumindest bei mir), daran würde ich auch nix drehen.
 
Ich würde das eigentlich so organisieren, das die controller in einer anderen gruppe "i2c" zugehören sollten:
Bash:
crw-rw----+ 1 root root 89, 10 13. Jän 08:09 /dev/i2c-10
--- vs ---
crw-rw----+ 1 root i2c 89, 10 13. Jän 08:09 /dev/i2c-10
dann würde ich mich und root der Gruppe i2c hinzufügen

und dann würde ich auf 660 stellen, 666 kommt wie 777 nicht in frage.

Nur gibts bei Fedora die i2c Gruppe nicht. Ich könnte Sie erstellen. Anderswo wird bei Fedora aber die Gruppe plugdev oder auch video genannt. Welche wäre die Richtige?

Befehle:
Bash:
sudo groupadd --system i2c
sudo chown root:i2c /dev/i2c*
sudo usermod -a -G i2c root
sudo usermod -a -G i2c user
sudo chmod 660 /dev/i2c-xx
Aus diese Quelle und anderen zusammengebastelt: https://www.ddcutil.com/i2c_permissions/
 
Zuletzt bearbeitet:
Laut deinen Infos und den Links sollte bei Installation von i2c-tools die Gruppe i2c erstellt und i2c file zugeordnet werden. Das ist z.B. bei mir gar nicht passiert. Ob das so korrekt ist oder es an dem Fedora Paket liegt... keine Ahnung. Aber dein Weg sollte eigentlich funktionieren mit der Gruppe und den Mitgliedern root und deinem User. Es sei denn hierfür muss an den UDEV Rules noch etwas gedreht werden.
Die UDEV Rules von OpenRGB beinhalten, soweit ich das überblicken kann, keine Gruppen.
https://gitlab.com/CalcProgrammer1/...nrgb.rules?job=Linux+64+AppImage&inline=false
Wobei ich mich damit zu wenig auskenne, um da etwas konkretes sagen zu können. Die Anleitung besagt ja, dass die UDEV Rules bei Installation über Fedora dabei sind.

Ansonsten beziehst du dich bei deinen Links auch auf ddcutil was ja eigentlich für die Steuerung von Monitoren(?) gedacht ist und zunächst wenig mit OpenRGB zu tun hat. Weiß nicht, ob es hier 1:1 übertragen werden kann was Gruppen usw. betrifft.

Ich bin letztendlich einfach den Weg gegangen, wie es die Anleitung auf Github vorgeschlagen hat mit 777 bzw. 666 in meinem Fall für die entsprechenden Controller.
 
Ja in die UDEV datei hab ich auch vorher reingeschaut gehabt.
ich hab das mal so durchgeführt, schau mir das Ergebnis beim nächsten Neustart, morgen oder so, an.

Des weiteren werd ich noch eine Nobara VM aufsetzen und mal reinschaun wie es da aussieht.
 
Zurück
Oben