Asus Aura and OpenRGB not working

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.

I’m trying OpenRGB from this repo: https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.3/

There is an appimage from Releases · Adam Honse / OpenRGB · GitLab as well as a rpm, and a udev rules for a gazillion devices.

However, there is this warning from Adam Honse / OpenRGB · GitLab

  • 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.

Thanks,

Bruno

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 …

https://forums.opensuse.org/](https://forums.opensuse.org/showthread.php/556534-Asus-Aura-and-OpenRGB-not-working?goto=newpost)

Traduzir esta página

há 5 dias — I am working on getting patches submitted upstream, but for now you must patch your kernel with the provided OpenRGB.patch file.

But there is no such post here???

Ah, some progress!

From https://www.reddit.com/r/OpenRGB/comments/l2ramj/do_i_need_the_kernel_patch/ after modprobe i2c_dev openRGB recognizes the ASUS Aura SMBus device.

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.

Hi Bruno,

FWIW, on 15.2 it works with a Prime X570-P and this setup:

kasi@mars:~/Downloads> zypper se -i openrgb 
Repository-Daten werden geladen... 
Installierte Pakete werden gelesen... 

S  | Name                    | Summary                          | Type 
---+-------------------------+----------------------------------+------ 
i+ | OpenRGB                 | Open source RGB lighting control | Paket 
i+ | i2c-openrgb-kmp         | I2C patches for OpenRGB          | Paket 
i+ | i2c-openrgb-kmp-default | I2C patches for OpenRGB          | Paket 
kasi@mars:~/Downloads> 

Unfortunately, the patches ic2-openrgb-kmp* don’t seem to be available on 15.3, yet:

https://software.opensuse.org/package/i2c-openrgb-kmp

Maybe try and contact the package maintainer on OBS?

No, it is available: https://download.opensuse.org/repositories/home:/sp1rit:/testing/openSUSE_Leap_15.3/
Leap 15.3 have troubles with https://software.opensuse.org - see 1188365 – Unable to find packages for Leap 15.3 using software.opensuse.org

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).

Thanks

More worrisome, 12c_nvidia is not shown in lsmod anymore.

Removed both openrgb kmp modules with Yast, but still no i2c modules found. WTH?

Hi
Anything blacklisted? Did your rebuild initrd with mkinitrd

Hi, my mistake, I think. I could modprobe both i2c modules:

# lsmod | grep i2c
i2c_piix4              28672  0
i2c_dev                24576  0
# 

But, if I recall the name correctly, there was a third module called i2c_nvidia_smi that is still missing.

At least OpenRGB is working in the same limited way as before.

Thanks, malcolm. Do I need to mkinitrd to load these modules at boot, or is modprobe enough?

Hi
If there not loading at boot you would need to create a config file in /etc/modules-load.d/ see man modules-load.d for details.

Hi, Malcolm. It is loading after reboot, apparently modprobing once was enough.

dmesg after reboot today:

    8.033533] nvidia-gpu 0000:08:00.3: i2c timeout error e0000000
    8.034772] ucsi_ccg 2-0008: i2c_transfer failed -110
    8.035996] ucsi_ccg 2-0008: ucsi_ccg_init failed - -110
    8.037276] ucsi_ccg: probe of 2-0008 failed with error -110

Any idea on how to fix this?

Thanks

Hi
Might be a bug with the UCSI driver for Cypress CCGx Type-C controller <https://patchwork.kernel.org/project/linux-usb/patch/20181026163659.21590-3-ajayg@nvidia.com/&gt;

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).


gpustat

hostname                     Sun Jul 25 11:31:34 2021  470.42.01
[0] NVIDIA GeForce GT 1030 | 31°C,   0 % |     5 /  2001 MB | username(4M)

Ran that, i2c_nvidia_gpu is now loaded (I rebooted before checking, don’t know if it was necessary.

# lsmod | grep i2c
i2c_piix4              28672  0
i2c_nvidia_gpu         20480  0
i2c_dev                24576  0

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.

Alas, dmesg still shows the i2c errors:

[jul25 14:30] nvidia-gpu 0000:08:00.3: i2c timeout error e0000000
  +0,001250] ucsi_ccg 2-0008: i2c_transfer failed -110
  +0,001257] ucsi_ccg 2-0008: ucsi_ccg_init failed - -110
  +0,001248] ucsi_ccg: probe of 2-0008 failed with error -110
  +0,538826] nvidia: loading out-of-tree module taints kernel.
  +0,000018] nvidia: module license 'NVIDIA' taints kernel.
  +0,000001] Disabling lock debugging due to kernel taint
  

Hi
Just remember you will need remove the nvidia blobs and see if it duplicates the ucsi_cgg error, if it does then you could create a bug report…

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… :stuck_out_tongue:

Anyway, it appears to be working acceptably now. Thanks a lot for the help, Malcolm.