I’ve googled around but couldn’t find any relevant info on opensuse + my mobo.
Mobo is an ASUS Prime B450M-Gaming_BR, with a led strip connected to the four-pin RGB header. RGB works OK in dual-boot windows 10 with Asus Lighting_Control_1.07.84 app, soon to be deprecated, but working for now.
When rebooting to LEAP 15.3 KDE Plasma, regardless of the lighting pattern set in windows, at start-up the color that was cycling before reboot stays fixed, for instance, green.
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.
So apparently the udev rules are not relevant to my mobo (not sure), and I’d need to patch the kernel, which is above my head.
So, has anybody had experience with controlling an asus mobo leds?
Is there a patched kernel for LEAP 15.3? openSUSE Software only list and official package dor Tumbleweed.
This is totally weird. I just googled for opensuse openrgb kernel patch and the fourth search result points to this thread and includes a text from 5 days ago with a response:
LEAP 15.3 Asus Aura and OpenRGB not working - openSUSE …
Now I can set a color cycling pattern like Rainbow, Spectrum, etc., but all single-color modes like static, breathing, etc. are green, regardless of what color is applied.
There are also only six primary colors to choose from, very different from the dozens of colors that are shown in screen captures on the internet.
Perhaps this is due to the missing kernel patch. Or not.
Installed i2c-openrgb-kmp-default, i2c_dev was removed from lsmod list.
Rebooted, with errors:
# dmesg | grep Failed
1.641111] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
1.641313] systemd[1]: Failed to start Load Kernel Modules.
9.064122] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
9.064285] systemd[1]: Failed to start Load Kernel Modules.
OpenRGB shows no devices. With i2c_dev it did see Asus SMBus.
Added i2c-openrgb-kmp, so both modules are installed. Now the two remaining i2c modules (i2c_piix4 and another I don’t recall) do not show in lsmod too, and I can’t insert them, probably because they were removed by the OpenRGB modules install scripts.
OpenRGB still not seeing any device.
Rebooted, same results.
Any ideas? If not, how do I reinstall the i2c modules (they don’t show in yast software manager anymore).
May be, I’ll check it out. But the thing is that the i2c_nvidia_smi module was installed before I tried the openRGB module from the sp1rit testing repo, now I can’t find/install it.
That’s the law of unintended consequences… Perhaps if I reinstall the nvidia blob? There is an update on leap 15.3 repo that I’ve blocked due to secure boot MOK keys, but maybe it would reinstate the module?
The only change I’ve noticed is that nvidia-settings>thermal settings says that fan speed (RPM) is unsupported, and the fan speed (%) is fixed at 23%, regardless of the GTX 1650 utilization (but I didn’t do a stress test, just a bunch of concurrent glxgears not sync’d to vblank)
Hi
Try running as root user to see if it finds it again;
sensors-detect --auto
Is the nvidia card the only gpu in use? I would run something like vkmark or glmark2 and check, I use nvtop here (needs compiling locally), I also have gpustat (alas Tumbleweed only).
I rebooted because when I came back after lunch the audio source was switched to HDMI/DP, before it was set to analog, and my 2nd monitor connected to the HDMI port was no longer receiving a video signal.
After reboot the HDMI monitor returned to normal, but the GPU fan speed (RPM) is still “Unsupported” and stuck at 23%. I’ll try some other video stress test to see if this changes.
Note: sensors-detect took an unusually long time (10 or 20 seconds, all others took less than 1 second) probing NVIDIA GPU I2C adapter (i2c-2), in bold below:
Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-piix4' for device 0000:00:14.0: AMD KERNCZ SMBus
Next adapter: SMBus PIIX4 adapter port 0 at 0b00 (i2c-0)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Next adapter: SMBus PIIX4 adapter port 2 at 0b00 (i2c-1)
Do you want to scan it? (YES/no/selectively):
**Next adapter: NVIDIA GPU I2C adapter (i2c-2)
Do you want to scan it? (YES/no/selectively): **
Next adapter: SMBus PIIX4 adapter port 3 at 0b00 (i2c-3)
Do you want to scan it? (YES/no/selectively):
Next adapter: SMBus PIIX4 adapter port 4 at 0b00 (i2c-4)
Do you want to scan it? (YES/no/selectively):
Next adapter: SMBus PIIX4 adapter port 1 at 0b20 (i2c-5)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter 3 at 8:00.0 (i2c-6)
Do you want to scan it? (yes/NO/selectively):
Next adapter: NVIDIA i2c adapter 5 at 8:00.0 (i2c-7)
Do you want to scan it? (yes/NO/selectively):
Next adapter: NVIDIA i2c adapter 6 at 8:00.0 (i2c-8)
Do you want to scan it? (yes/NO/selectively):
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `k10temp' (autoloaded):
* Chip `AMD Family 17h thermal sensors' (confidence: 9)
No modules to load, skipping modules configuration.
Unloading cpuid... OK
Ah, the joys of modern computing…
Anyway, it appears to be working acceptably now. Thanks a lot for the help, Malcolm.