|d3162ea2e8||3 years ago|
|Controllers||3 years ago|
|RGBController||3 years ago|
|dependencies||3 years ago|
|i2c_smbus||3 years ago|
|i2c_tools||3 years ago|
|net_port||3 years ago|
|qt||3 years ago|
|serial_port||3 years ago|
|super_io||3 years ago|
|wmi||4 years ago|
|.gitignore||3 years ago|
|.gitlab-ci.yml||3 years ago|
|.gitmodules||3 years ago|
|99-openrgb.rules||3 years ago|
|LICENSE||4 years ago|
|NetworkClient.cpp||3 years ago|
|NetworkClient.h||3 years ago|
|NetworkProtocol.cpp||3 years ago|
|NetworkProtocol.h||3 years ago|
|NetworkServer.cpp||3 years ago|
|NetworkServer.h||3 years ago|
|OpenRGB.cpp||3 years ago|
|OpenRGB.h||3 years ago|
|OpenRGB.patch||3 years ago|
|OpenRGB.pro||3 years ago|
|ProfileManager.cpp||3 years ago|
|ProfileManager.h||3 years ago|
|README.md||3 years ago|
|cli.cpp||3 years ago|
|main.cpp||3 years ago|
One of the biggest complaints about RGB is the software ecosystem surrounding it. Every manufacturer has their own app, their own brand, their own style. If you want to mix and match devices, you end up with a ton of conflicting, functionally identical apps competing for your background resources. On top of that, these apps are proprietary and Windows-only. Some even require online accounts. What if there was a way to control all of your RGB devices from a single app, on both Windows and Linux, without any nonsense? That is what OpenRGB sets out to achieve. One app to rule them all. OpenRGB is still in its early stages and already supports quite a few products. I'm always on the lookout for good deals on more popular RGB devices to add support for.
See the Project Wiki for the current list of supported devices.
This project provides a tool to probe the SMBus. This is a potentially dangerous operation if you don't know what you're doing. Exercise caution when clicking the Detect Devices or Dump Device buttons. There have been reports of Gigabyte motherboards having serious issues (bricking the RGB or bricking the entire board) when dumping certain devices. On the same lines, exercise the same caution when using the i2cdump and i2cdetect commands on Linux, as they perform the same functionality. OpenRGB is not liable for damage caused by improper SMBus access.
As of now, only Gigabyte RGB Fusion 2.0 boards have been reported to have issues.
Pre-built binaries are available under the Releases section on GitLab.
If you wish to build the application yourself:
- Download the latest Visual Studio Community Edition and Qt Creator.
- Open the OpenRGB.pro project in Qt Creator.
- Use the MSVC compiler kit, either 32- or 64-bit, to build the application.
- Run the project from Qt Creator. If you want to use your custom build standalone, download the latest matching Release package and replace the OpenRGB.exe in it with your new build.
You must run the application as Administrator the first time to allow InpOut32 to set up. It can be run as a normal user afterwards
- Some USB devices (especially keyboards and mice) require installation of the WinUSB driver. You can do this with Zadig:
- Download Zadig: https://zadig.akeo.ie/
- Select "list all devices" from the menu
- Select the last interface of your device
- With "WinUSB" selected, click Install
Pre-built binaries are not currently available for Linux
You can build the project using Qt Creator or on the command line. The commands listed here work for Debian-based distros.
- sudo apt install build-essential qtcreator qt5-default libusb-1.0-0-dev libhidapi-dev pkgconf
- git clone https://gitlab.com/CalcProgrammer1/OpenRGB
- cd OpenRGB
- qmake OpenRGB.pro
- make -j8
Run the application with ./OpenRGB
SMBus access is necessary for controlling RGB RAM and certain motherboard on-board LEDs.
If you are not trying to use OpenRGB to control RGB RAM or motherboard LEDs, you may skip this section.
ASUS and ASRock motherboards have their RGB controller on an SMBus interface that is not accessible by an unmodified Linux kernel (for now). I am working on getting patches submitted upstream, but for now you must patch your kernel with the provided OpenRGB.patch file.
Allowing access to SMBus:
Load the i2c-dev module:
sudo modprobe i2c-dev
Load the i2c driver for your chipset:
sudo modprobe i2c-i801
sudo modprobe i2c-nct6775- Secondary controller for motherboard LEDs (requires patch)
- Unmodified kernel will have one interface, patched kernel will have two. The first at 0x0B00 and the second at 0x0B20. The 0x0B20 interface is for motherboard LEDs.
Instructions on patching the kernel:
Some Gigabyte/Aorus motherboards have an ACPI conflict with the SMBus controller.
acpi_enforce_resources=laxto your kernel command line and reboot. The controller should now show up.
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, for instance:
sudo chmod 777 /dev/i2c-0
- List all SMBus controllers:
USB devices require udev rules to access as a normal user.
You can run OpenRGB as root to detect all USB devices.
Udev rules are included in this repo:
- Copy the 99-openrgb.rules file to /etc/udev/rules.d/
- Reload rules with
sudo udevadm control --reload-rules && sudo udevadm trigger
- Add your user to the
sudo adduser username plugdev
- Add your user to the
sudo adduser username i2c
Qt-Plus (ColorWheel): https://github.com/liuyanghejerry/Qt-Plus
AMD ADL Libraries: https://github.com/GPUOpen-LibrariesAndSDKs/display-library
While no code from these projects directly made its way into OpenRGB, these projects have been invaluable resources for protocol information.
Aura Addressable Header Controller: https://gitlab.com/cneil02/aura-addressable-header-controller