New to Linux. Installed Fedora KDE Plasma a couple weeks ago on my gaming PC. I have a lot of RGB components. Mouse, keyboard, case fans, CPU cooler, and RAM. I downloaded and installed OpenRGB through Fedora’s Discover. But when I first opened it, I was met with the following message:
“Some internal devices may not be detected: One or more I2C or SMBus interfaces failed to initialize. RGB DRAM modules, some motherboards’ onboard RGB lighting, and RGB graphics cards, will not be available in OpenRGB without I2C or SMBus. On Linux, this is usually because the I2C-dev module is not loaded.”
Also while researching this issue a little, I had read that sometimes OpenRGB had bricked people’s RAM, and it had something to do with the SMBus. Considering “SMBus” was mentioned in the error message it gave me, this made me nervous. How can I get OpenRGB working without bricking any of my components?
I’ve tried installing all the appropriate IC2 packages I need and enabling the drivers in the terminal, but I keep getting this pop when I open OpenRGB no matter what, and my RAM isn’t even detected in the program either. Any advice?
Unfortunately, OpenRGB doesn’t always have the necessary drivers for Linux, so some peripherals won’t work unlike in the Windows version.
I have a Zotac card that works with the Windows version, but on Linux, I have to patch the OpenRGB code using a merge request submitted by a developer on the OpenRGB GitLab.
Patches depend on the hardware.
When I have a device that isn’t working, I browse the GitLab merge requests to see if there is a proposal for my device—keeping in mind that a developer might have done the necessary work, but the request hasn’t been accepted yet.
The MR for my Zotac card was submitted in late 2024 but still hasn’t been merged; that is why I have to patch the source code.
Oh I see. This is starting to sound like it might be too advanced for me to solve, which is very disappointing. I’m loving Linux so far, but I wouldn’t know how to begin patching stuff to fix my specific hardware.
What you should do is check if there is a MR available for your hardware.
If so, it would be worth learning how to use the Linux patch command. There’s nothing complicated about it; you just need to understand the basic concept.
That’s good to know! Most of mine are detected inside the program, but my RAM is not.
Also when I try to edit my lighting by dragging sliders in the program, my lights turn off inside, and only a couple LEDs on a couple of my fans actually light up and change color. Though I think that may be because my internal components are plugged into a Nollie 16 RGB controller/hub so it can’t identify the correct LEDs for my fans and CPU cooler. Which is likely a whole separate issue to the I2C/SMBus issue I guess.
There are tools on Linux that allow you to check I2C ports (i2c-tools) using the i2cdetect and i2cdump commands.
I ran tests on my machine, and some of the I2C addresses are sending read timeouts, which explains the error messages, but I don’t have any problems with my RGB ports.
Oh! I appreciate you looking this up for me! Sorry to ask, but how can I go about safely applying this patch to my system? Is it with terminal commands?
I took a quick look at the code; the Nollie controller is a USB device.
You would need to send me the output of the lsusb command so I can check if OpenRGB supports it.
If it does, as soon as I have time, I’ll send you a patched RPM that you can simply install and test.
Ok I ran the lsusb command, and this is what I got:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0909:0018 Audio-Technica Corp. AT2020 USB
Bus 001 Device 003: ID 1b1c:1b11 Corsair K95 RGB Mechanical Gaming Keyboard
Bus 001 Device 004: ID 048d:5711 Integrated Technology Express, Inc. GIGABYTE Device
Bus 001 Device 005: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 007: ID 3061:4716 nollie.cn Nollie 16CH RGB
Bus 001 Device 008: ID 222a:0001 ILI Technology Corp. Multi-Touch Screen
Bus 001 Device 009: ID 3402:0c02 HYTE HYTE THICC Y70 LCD
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 046d:c539 Logitech, Inc. Lightspeed Receiver
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 009 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Unfortunately, the patch only applies to NOLLIE8, NOLLIE8_OS21, PRISM8_OS21, NOLLIE1, NOLLIE1_OS21, and NOLLIE28_12.
I have also read a bug reports indicating issues with the Nollie devices due to a poorly implemented protocol for Linux.
However, the good news is that the code was updated three weeks ago.
Ahh that’s really unfortunate. Thanks a lot for helping me with this though! I think I may just wait, cause I think trying to fix this myself might be a little too far over my head at the moment.
