NVIDIA I2C driver issues about open-gpu-kernel-modules

[aritger]

Hi @CalcProgrammer1 I'm sorry you didn't receive a response to your linux-bugs email. I agree this merits investigation. Reopening.

[PAR2020]

Hello gentlemen,
To get the best focus for our open source effort, we would like to keep the focus of these GitHub issues to the Open GPU Kernel Modules components. As you may know, we do have a Linux Forum (https://forums.developer.nvidia.com/c/gpu-graphics/145) where more generic issues should be discussed. Submitting the issue through [email protected] get directly to the team of developer, QA, and triage folks who are able to resolve them best.
So respectfully, we will close this issue and direct you to continue using the forum for these types of problems/discussions.

[aritger]

My apologies, this fell off my radar. Thanks to @CalcProgrammer1's diagnosis in #41 (comment), hopefully this is fairly easy to resolve. I've filed NVIDIA internal bug 4396674 for the always-blue symptom.

[CalcProgrammer1]

I2C is part of the kernel components...

https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/nvidia/nv-i2c.c

And as I stated in the original post, I emailed this to [email protected] months ago and never got a reply.

[CalcProgrammer1]

I actually think removing the block of code at line 191 here would do the trick, as without the I2C_SMBUS capabilities provided by NVIDIA's driver, the kernel will fall back to using the non-SMBus I2C calls through emulation, using an interface we have confirmed working (raw I2C block transfers).

https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/kernel-open/nvidia/nv-i2c.c#L191

The issue is why do I2C SMBUS word operations fail when going through NVIDIA's implementation?

[devilsclaw]

So I went and tried the patch.

I manually applied the patch to /usr/src/nvidia-510.73.05/nvidia/nv-i2c.c
which is the current install proprietary nvidia driver.

after that I did:
cd /usr/src/nvidia-510.73.05
sudo make modules -j24
sudo make modules_install
sudo update-initramfs -c -k $(uname -r)

I originally added a printk("DC: Testing\n"); to the code as well so that I could do a dmesg and grep that string. I was able to see that string so it shows that the code and the patches took. after that I removed the print statement and did the same thing as the above.

I ran the patched version of openrgb and I also ran the one I patched which is really no difference. Sadly the patch did not fix it for my video card.

Below is what that section of the code currently looks like.
case I2C_SMBUS_WORD_DATA:
if (read_write != I2C_SMBUS_READ)
{
//data->block[1] = (data->word & 0xff);
//data->block[2] = (data->word >> 8);
u16 word = data->word;
//printk("DC: Testing\n");
data->block[1] = (word & 0xff);
data->block[2] = (word >> 8);
}

NOTE: If need be I can switch to the open-gpu-kernel-modules version of the nvidia driver. It might take me a bit to get it running on ubuntu but I am sure I can get it done.

[PAR2020]

Looks like we finally have an internal repro of this issue.
As stated, using Nouveau works fine (proper version reported, LEDs can be changed).
Using the 515.57 driver (monolithic or OpenRM) with OpenRGB 0.7 shows the card is detected but the LEDs cannot be changed, version field is garbage.
System being used for dev triage.

[MG-5]

My apologies, this fell off my radar. Thanks to @CalcProgrammer1's diagnosis in #41 (comment), hopefully this is fairly easy to resolve. I've filed NVIDIA internal bug 4396674 for the always-blue symptom.

Is there some progress to the bug 4396674?

I also can confirm the same problem described in #41 (comment) on ASUS ROG STRIX 3070Ti

[CalcProgrammer1]

Unfortunately, as I said earlier in this issue thread, I personally do not have a compatible GPU to test this on. I'm working based on feedback from other users on the OpenRGB Discord server. I asked a week or so ago if anyone was available to test, but I don't know if the users who had the issue are familiar enough with Linux to patch the modules.

I can ask again. If anyone here has an ASUS RTX 3 series card with Aura lighting, it would be awesome if you could test the above patch. All you would need to do is launch the latest OpenRGB (version 0.7 or newer) with the patched module loaded and then check the version string in the Information tab. If it is garbage (non-ASCII characters) then the patch did not work.

Put out a request for testers on Discord and Twitter. Hopefully someone with the right card will respond.

[aritger]

Thank you for testing the patches, @rskaliotis. The fix will be included in our next release branch series, 520.xx, though I don't have a firm ETA.

@ZetaPhoenix: I think this code handles both smbus word writes and reads.

If there are other problems/requests, let's please track those as separate Issues. I think they're distinct from the 16-bit smbus problem originally reported here.

[aritger]

Sorry, the patch I mentioned above should also contain the fix mentioned earlier in this thread. Here is an updated patch that contains both:
0001-fix-I2C_SMBUS_WORD_DATA-reads-and-writes.patch.txt

[atta2022]

Can confirm its still NOT working for me:

atta2k22@atta2k22-BTC-B250:~/LINUX/bzminer$ sudo openrgb -l
Attempting to connect to local OpenRGB server.
Connection attempt failed
Local OpenRGB server unavailable.
Running standalone.
[i2c_smbus_linux] Failed to read i2c device PCI device ID
[i2c_smbus_linux] Failed to read i2c device PCI device ID
0: Gigabyte RTX3060 EAGLE OC 12G V2
Type: GPU
Description: RGB Fusion GPU
Location: I2C: /dev/i2c-23, address 0x63
Modes: [Direct] Breathing Flashing 'Dual Flashing' 'Color Cycle' 'Spectrum Cycle'
Zones: 'GPU Zone'
LEDs: 'GPU LED'

1: Gigabyte RTX3060 EAGLE OC 12G V2
Type: GPU
Description: RGB Fusion GPU
Location: I2C: /dev/i2c-18, address 0x63
Modes: [Direct] Breathing Flashing 'Dual Flashing' 'Color Cycle' 'Spectrum Cycle'
Zones: 'GPU Zone'
LEDs: 'GPU LED'

2: ASUS TUF RTX 3080Ti O12G GAMING
Type: GPU
Description: ENE SMBus Device
Version: AUMA0-E6K5-0107
Location: I2C: /dev/i2c-28, address 0x67
Modes: Direct [Off] Static Breathing Flashing 'Spectrum Cycle' Rainbow 'Chase Fade' Chase 'Random Flicker'
Zones: Unknown
LEDs: 'Unknown LED 1' 'Unknown LED 2' 'Unknown LED 3' 'Unknown LED 4'

3: ASUS ROG STRIX 3090 O24G GAMING
Type: GPU
Description: ENE SMBus Device
Version: AUMA0-E6K5-0107
Location: I2C: /dev/i2c-12, address 0x67
Modes: Direct [Off] Static Breathing Flashing 'Spectrum Cycle' Rainbow 'Chase Fade' Chase 'Random Flicker'
Zones: Unknown
LEDs: 'Unknown LED 1' 'Unknown LED 2' 'Unknown LED 3' 'Unknown LED 4' 'Unknown LED 5' 'Unknown LED 6' 'Unknown LED 7' 'Unknown LED 8' 'Unknown LED 9' 'Unknown LED 10' 'Unknown LED 11' 'Unknown LED 12' 'Unknown LED 13' 'Unknown LED 14' 'Unknown LED 15' 'Unknown LED 16' 'Unknown LED 17' 'Unknown LED 18' 'Unknown LED 19' 'Unknown LED 20' 'Unknown LED 21' 'Unknown LED 22'

Sun Nov 13 12:23:44 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.53 Driver Version: 525.53 CUDA Version: 12.0 |
|-------------------------------+----------------------+----------------------+

[aritger]

Thanks for the all the discussion.

If I understand correctly, the issues @atta2022 and @NoX1De mention are different than what was originally reported here. I'd like to avoid this Issue turning into an unbounded "OpenRGB+NVIDIA doesn't work" thread that morphs over time and stays open forever.

Given @SapphirusBeryl's test results, I think the originally-reported problems are resolved, and anything else can be treated as separate Issues.

I'll give it another day or two for any other feedback that suggestions the original problems tracked here are still not working correctly with 525.35.

[wyatt8740]

The only way I have ever been able to get I²C or DDC working on my nvidia card has been to put:

options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100

... in /etc/modprobe.d/nvidia.conf, or else set up an xorg.conf containing something like:

Section "Device"
        Identifier      "Device0"
        Driver          "nvidia"
        VendorName      "NVIDIA Corporation"
        BoardName       "GeForce GTX 750 Ti"
        Option          "RegistryDwords"        "RMUseSwI2c=0x01; RMI2cSpeed=100"
EndSection

I prefer the first method. Have you tried either of these?

I have been using this to control my monitor via DDC (which is I²C) for a year or two. My assumption is that this will also work for on-card lighting (if present), since it's probably all on one bus. I've seen this brought up before relating to Nvidia cards, so I assume it's the same issue.

Note that this driver seems not to support the 750 Ti or other Maxwell GPU's, but I suspect this fix may also work on newer cards.

[CalcProgrammer1]

The lighting controller is usually on an unused I2C bus (one not connected to a display output for DDC). I can communicate with the controllers on many cards just fine, so I don't think it has to do with I2C speed. It seems to be related to the SMBus subset of the I2C functionality in that word and block transfers do not occur correctly (but byte transfers do). I don't personally have an affected card unfortunately, it's an issue that I had others who owned an appropriate card test. The ASUS RTX3xxx series are the most affected as the lighting controller they use requires 16-bit (word) SMBus writes.

[atiensivu]

This explains what I saw when I was fiddling with my ASUS 3090. Interesting.

[ZetaPhoenix]

EVGA 30xx cards use I2C_SMBUS_I2C_BLOCK_DATA commands to talk to the RGB controller and this is not supported under Linux but is supported through nvapi.dll

See this patch that works under Windows for OpenRGB to talk to EVGA cards through NVIDIA's .dll but will fail under Linux: https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/752

Support for I2C_SMBUS_I2C_BLOCK_DATA commands is also missing in this code.

[CalcProgrammer1]

Also look into

open-gpu-kernel-modules/kernel-open/nvidia/nv-i2c.c

Line 58 in 69791e9

/* we only support basic I2C reads/writes, reject any other commands */

Comment indicates "we only support basic I2C reads/writes, reject any other commands"

[amrit1711]

We have filed a bug 3646481 internally for tracking purpose. You can refer it for status update.

[aritger]

@CalcProgrammer1: can you test whether the following change fixes the problem for you?

$ git diff
diff --git a/kernel-open/nvidia/nv-i2c.c b/kernel-open/nvidia/nv-i2c.c
index f227d180e149..8bc6cf6314e7 100644
--- a/kernel-open/nvidia/nv-i2c.c
+++ b/kernel-open/nvidia/nv-i2c.c
@@ -140,8 +140,9 @@ static int nv_i2c_algo_smbus_xfer(
         case I2C_SMBUS_WORD_DATA:
             if (read_write != I2C_SMBUS_READ)
             {
-                data->block[1] = (data->word & 0xff);
-                data->block[2] = (data->word >> 8);
+                u16 word = data->word;
+                data->block[1] = (word & 0xff);
+                data->block[2] = (word >> 8);
             }
 
             rmStatus = rm_i2c_transfer(sp, nv, (void *)adapter,

(the same change should apply to both the open kernel modules here and to the proprietary driver)

[amrit1711]

@CalcProgrammer1
Can you please help to test the change fixe as suggested in last comment and share results.

[rockowitz]

Like @CalcProgrammer1, I too lack a device to test this on. Because of the difficulties presented by the proprietary driver, I have not purchased a Nvidia based card in years. Also, ddcutil does not use I2C SMBUS ioctl's, and tries to avoid even probing a /dev/i2c device that appears to be a SMBUS device, both for efficiency and because of the potential for lockups.

[Chr1sNo]

Further to @devilsclaw's comments it's worth noting that the same GPU (10DE:220A 1043:886E) has been confirmed as working on Windows.

[devilsclaw]

Removed everything except the drm failing thing, not sure if it could be causing problems.

Will add a butter dump in next comment.

[ 11.651031] [drm:nv_drm_master_set [nvidia_drm]] ERROR [nvidia-drm] [GPU ID 0x00000900] Failed to grab modeset ownership

[devilsclaw]

Here is a dump:

[ 57.761987] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00
[ 57.762610] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA0 : BYTE 0x00
[ 57.763227] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA1 : BYTE 0x01
[ 57.763865] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA2 : BYTE 0x02
[ 57.764480] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA3 : BYTE 0x03
[ 57.765101] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA4 : BYTE 0x04
[ 57.765715] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA5 : BYTE 0x05
[ 57.766331] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA6 : BYTE 0x06
[ 57.766948] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA7 : BYTE 0x07
[ 57.767560] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA8 : BYTE 0x08
[ 57.768183] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xA9 : BYTE 0x09
[ 57.768791] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAA : BYTE 0x0A
[ 57.769416] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAB : BYTE 0x0B
[ 57.770020] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAC : BYTE 0x0C
[ 57.770635] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAD : BYTE 0x0D
[ 57.771250] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAE : BYTE 0x0E
[ 57.771860] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0xAF : BYTE 0x0F
[ 57.771871] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.772953] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x8C
[ 57.772962] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.774040] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x80
[ 57.774048] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.775773] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0xC5
[ 57.775783] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.777650] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x80
[ 57.777660] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.779338] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x8C
[ 57.779345] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.780814] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x80
[ 57.780821] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.782100] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.782108] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.783491] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.783498] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.784832] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.784838] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.787136] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.787144] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.788692] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.788699] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.790054] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.790062] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.791563] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.791570] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.792716] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.792723] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.793788] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.793797] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.794921] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.794929] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.796019] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.796027] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.797103] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.797110] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.798222] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.798229] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.799417] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.799424] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.800505] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.800511] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.801599] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.801607] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.803293] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.803300] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.805161] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.805169] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.806638] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.806658] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.808284] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.808296] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.809634] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.809655] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.811024] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.811034] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.812773] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.812780] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.814813] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.814828] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.816183] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.816194] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1010 : BYTES 0x10,0x10
[ 57.817460] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x23
[ 57.817471] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.818733] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.818742] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.820916] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.820925] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.822297] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.822307] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.823612] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.823622] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.824992] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.825003] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.826373] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.826381] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.827558] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.827565] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.828973] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.828979] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.830253] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.830261] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.831632] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.831638] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.833060] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.833068] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.834317] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.834324] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.835611] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.835618] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.837458] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.837464] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.838555] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.838562] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.839836] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.839843] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.840940] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.840952] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.842137] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.842146] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.843299] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.843306] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.844370] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.844377] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.845936] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.845944] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.847024] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.847030] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.848119] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.848125] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.849202] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.849214] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.850293] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.850301] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.851381] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.851390] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.853369] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.853378] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.855111] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.855117] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.856589] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.856596] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.858180] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.858191] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.859637] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.859652] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.860978] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.860988] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.862331] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.862340] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.863594] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.863601] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.864915] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.864922] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.866295] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.866303] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.867539] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.867547] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.868630] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.868641] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.870678] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.870688] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.871804] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.871813] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.873013] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.873021] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.874112] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.874120] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.875544] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.875554] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.876954] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.876962] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.878030] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.878037] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.879114] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.879120] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.880193] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.880200] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.881274] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.881281] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.882347] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.882354] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.883506] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.883518] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.884657] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.884667] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.887194] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.887202] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.889020] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.889027] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.890518] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.890525] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.892369] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.892380] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.893806] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.893814] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.895358] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.895366] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.896726] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.896732] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.897993] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.898001] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.899565] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.899573] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.900831] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.900843] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.902189] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.902196] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.904177] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.904184] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x1C1C : BYTES 0x1C,0x1C
[ 57.905902] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0x00
[ 57.905972] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x8080 : BYTES 0x80,0x80
[ 57.908247] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0xAA
[ 57.908254] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x8080 : BYTES 0x80,0x80
[ 57.909759] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0xAA
[ 57.909771] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x8080 : BYTES 0x80,0x80
[ 57.911281] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0xAA
[ 57.911291] DC: I2C_WRITE_SMBUS_WORD_DATA: addr 0x67 : CMD 0x00 : WORD 0x8080 : BYTES 0x80,0x80
[ 57.912571] DC: I2C_READ_SMBUS_BYTE_DATA: addr 0x67 : CMD 0x81 : BYTE 0xAA
[ 57.932933] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00
[ 57.957259] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00
[ 57.977866] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00
[ 57.978786] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00
[ 57.979330] DC: I2C_WRITE_SMBUS_BYTE: addr 0x67 : BYTE 0x00

[emko]

just moved to Linux and now can't control leds, if you need someone to test i am willing

[ZetaPhoenix]

Seems like i2ctransfer commands work to talk to the EVGA 30 series GPUs:

# Initialize LED control
i2ctransfer -y 5 w6@0x2d 0xb2 0x04 0xc6 0xeb 0xea 0x15
# Command control for ALL OFF
i2ctransfer -y 5 w11@0x2d 0xc0 0x09 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0x00

Maps to this command here: https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Controllers/EVGAAmpereGPUController/EVGAGPUv3Controller.cpp#L297

void EVGAGPUv3Controller::initCard()
{
    // This command needs to be sent before the card will respond to OpenRGB commands
    // NvAPI_I2CWriteEx: Dev: 0x2D RegSize: 0x01 Reg: 0xB2 Size: 0x05 Data: 0x04 0xC6 0xEB 0xEA 0x15
    uint8_t data_pkt[5] = {0x04, 0xC6, 0xEB, 0xEA, 0x15};
    bus->i2c_smbus_write_i2c_block_data(dev, EVGA_GPU_V3_REG_ENABLE, sizeof(data_pkt), data_pkt);
    LOG_TRACE("[%s] Sending SW int packet", evgaGPUName);
    return;
}

Should i2c_smbus_write_i2c_block_data be mapped to the i2ctransfer command or is there another fix to allow block commands to be used?

[gardotd426]

Seems like i2ctransfer commands work to talk to the EVGA 30 series GPUs:

# Initialize LED control
i2ctransfer -y 5 w6@0x2d 0xb2 0x04 0xc6 0xeb 0xea 0x15
# Command control for ALL OFF
i2ctransfer -y 5 w11@0x2d 0xc0 0x09 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0x00

Maps to this command here: https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Controllers/EVGAAmpereGPUController/EVGAGPUv3Controller.cpp#L297

void EVGAGPUv3Controller::initCard()
{
    // This command needs to be sent before the card will respond to OpenRGB commands
    // NvAPI_I2CWriteEx: Dev: 0x2D RegSize: 0x01 Reg: 0xB2 Size: 0x05 Data: 0x04 0xC6 0xEB 0xEA 0x15
    uint8_t data_pkt[5] = {0x04, 0xC6, 0xEB, 0xEA, 0x15};
    bus->i2c_smbus_write_i2c_block_data(dev, EVGA_GPU_V3_REG_ENABLE, sizeof(data_pkt), data_pkt);
    LOG_TRACE("[%s] Sending SW int packet", evgaGPUName);
    return;
}

Should i2c_smbus_write_i2c_block_data be mapped to the i2ctransfer command or is there another fix to allow block commands to be used?

@ZetaPhoenix I have an EVGA XC3 Ultra RTX 3090, am I correct in my reading of your comment being that following your steps should allow lighting control of this card on Linux? I want to confirm this is what you're saying before I actually test it. Yes, I'm aware that this is all potentially risky and if I run anything it's at my own risk, but that's exactly why I want to confirm that's what you're saying beforehand.

As others have said, even though it seems like it might be a different underlying issue, EVGA Ampere GPUs seem to also be controllable on Windows via OpenRGB but not on Linux, just like the ASUS cards.

@amrit1711 @aritger as I said above, I do have hardware myself I can test this on, and I believe I can try patching the modules without much trouble (though I do use DKMS, I don't imagine that should cause any issues?)

[ZetaPhoenix]

Yes, according to other users on the OpenRGB discord, these commands work to turn off the RGB. The settings will not persist as the save command is not sent. See the rest of the OpenRGB controller code for the command if you want to save.

OpenRGB will attempt to load the firmware version from the card and if that fails (due to i2c_smbus_read_i2c_block_data not returning successfully) then the card will not be added.

[gardotd426]

Yes, according to other users on the OpenRGB discord, these commands work to turn off the RGB. The settings will not persist as the save command is not sent. See the rest of the OpenRGB controller code for the command if you want to save.

OpenRGB will attempt to load the firmware version from the card and if that fails (due to i2c_smbus_read_i2c_block_data not returning successfully) then the card will not be added.

Ah, so so far it's only possible to turn the RGB off?

[gardotd426]

@ZetaPhoenix No dice, unfortunately:

sudo i2ctransfer -y 5 w6@0x2d 0xb2 0x04 0xc6 0xeb 0xea 0x15  
Error: Adapter does not have I2C transfers capability

Until a couple weeks ago I had a single-GPU passthrough Windows VM that I used for Apex Legends, and through that using EVGA Precision X1 I was obviously able to control lighting. I'm not sure what more info I can provide but I'm happy to provide anything else needed to help get this figured out

EDIT: I'm still getting this error when trying to run i2cdump as well:

sudo i2cdetect -l

i2c-0	i2c       	NVIDIA i2c adapter 1 at f:00.0  	I2C adapter
i2c-1	i2c       	NVIDIA i2c adapter 5 at f:00.0  	I2C adapter
i2c-2	i2c       	NVIDIA i2c adapter 6 at f:00.0  	I2C adapter
i2c-3	i2c       	NVIDIA i2c adapter 7 at f:00.0  	I2C adapter
i2c-4	i2c       	NVIDIA i2c adapter 8 at f:00.0  	I2C adapter
i2c-5	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter
i2c-6	smbus     	SMBus PIIX4 adapter port 2 at 0b00	SMBus adapter
i2c-7	smbus     	SMBus PIIX4 adapter port 1 at 0b20	SMBus adapter

sudo i2cdetect 0

WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- 2d -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         

sudo i2cdump 0 0x2d i

Error: Adapter does not have I2C block read capability

Now, this is without patching the driver, I'm assuming I need to use the patch listed above? Or should this work regardless?

[gardotd426]

Eh even with patching the nv-i2c.c file and rebuilding and reinstalling the module it still gives the same results. I'm able to test whatever needs testing but I'm swamped right now trying to finish all the work required for the Arch port of Regolith DE moving to v2.0 (I'm the sole - and apparently now official - developer/maintainer of the Regolith DE port to Arch Linux, and v1.6 -> v2.0 basically changed everything from the ground up on a fundamental level regarding how it works, so I basically have to redo the whole thing). So I don't know how much time I'll have for deep dives in the Discord, but as soon as I finish the 2.0 transition I'll have more time. In the meantime I'm open to any guidance

[amrit1711]

@CalcProgrammer1
I tried to repro issue locally with ASUS Lightning 3050 card on below configuration setup but could not repro issue.

Alienware-Area-51-R4 + Intel(R) Core(TM) i7-7900X CPU @ 3.30GHz + kernel 5.15.0-41-generic + RTX 3050 + Driver 515.43.04 + Display GBT AORUS FI27Q-P

Repro Steps Tried -

1. Executed openrgb command and got the warning saying One or More I2C/SMBus interfaces failed to initialize.
2. Under Information Tab, I can see version as 0.7.
   However as per your earlier comment, version should be a garbage value in case of repro scenario but I can see correct version. --- NO REPRO

Request you or someone else to please share reliable test case along with steps.

[ZetaPhoenix]

Please make sure to load the udev rules and try with the pipeline version. Adding -vv will print more data to the console and launching with --loglevel 6 will create a verbose log file in ~/.config/OpenRGB/logs

FYI, that card does seem to have been added to the controller so it will skip: https://gitlab.com/OpenRGBDevelopers/OpenRGB-Wiki/-/blob/stable/Supported%20Devices/Supported%20Devices.md

Does it have RGB?

[ZetaPhoenix]

Good to hear.

Are there any patches to test for the block writes (EVGA GPU's)? That seems possible in some instances with i2ctransfer.

[PAR2020]

Not yet. The current patch reported here does not work in the repro case. Will advise if a new one is proposed.

[aritger]

I think this patch should resolve the issue:
0001-fix-I2C_SMBUS_WORD_DATA-reads-and-writes.patch.txt
I'd appreciate if anyone here could confirm that this fixes it for them.

[ZetaPhoenix]

I see we now have case NV_I2C_CMD_SMBUS_BLOCK_WRITE:

Do we need one for Read? Is this expected to work for the EVGA cards? I did not see any changes that would change the feature advertisement support to the upper layers.

[ZetaPhoenix]

@aritger Results testing with ubuntu and 3080Ti:

user@jammy:~$ sudo i2cdetect -l
i2c-0	smbus     	SMBus I801 adapter at efa0      	SMBus adapter
i2c-1	i2c       	nvkm-0000:01:00.0-bus-0000      	I2C adapter
i2c-2	i2c       	nvkm-0000:01:00.0-bus-0001      	I2C adapter
i2c-3	i2c       	nvkm-0000:01:00.0-bus-0002      	I2C adapter
i2c-4	i2c       	nvkm-0000:01:00.0-bus-0003      	I2C adapter
i2c-5	i2c       	nvkm-0000:01:00.0-aux-0003      	I2C adapter
i2c-6	i2c       	nvkm-0000:01:00.0-bus-0004      	I2C adapter
i2c-7	i2c       	nvkm-0000:01:00.0-aux-0004      	I2C adapter
i2c-8	i2c       	nvkm-0000:01:00.0-bus-0005      	I2C adapter
i2c-9	i2c       	nvkm-0000:01:00.0-aux-0005      	I2C adapter
i2c-10	i2c       	nvkm-0000:01:00.0-bus-0006      	I2C adapter
i2c-11	i2c       	nvkm-0000:01:00.0-aux-0006      	I2C adapter
i2c-12	i2c       	nvkm-0000:01:00.0-bus-0007      	I2C adapter
i2c-13	i2c       	nvkm-0000:01:00.0-aux-0007      	I2C adapter
i2c-14	i2c       	nvkm-0000:01:00.0-bus-0008      	I2C adapter
i2c-15	i2c       	nvkm-0000:01:00.0-aux-0008      	I2C adapter
i2c-16	i2c       	nvkm-0000:01:00.0-bus-0009      	I2C adapter
i2c-17	i2c       	nvkm-0000:01:00.0-aux-0009      	I2C adapter
i2c-18	i2c       	sor-0006-0f84                   	I2C adapter
i2c-19	i2c       	sor-0006-0f44                   	I2C adapter
i2c-20	i2c       	sor-0006-0f82                   	I2C adapter
user@jammy:~$ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
user@jammy:~$ sudo i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- 2d -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
user@jammy:~$ sudo i2cdump 2 0x2d i
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2, address 0x2d, mode i2c block
Continue? [Y/n] y
Error: Block read failed, return code -6
user@jammy:~$ 

OpenRGB did not seem to run at all on the new i2c interfaces (from --loglevel 6):

....
1010  |Info:    ------------------------------------------------------
1010  |Info:    |             Detecting I2C interfaces               |
1010  |Info:    ------------------------------------------------------
1010  |Info:    Registering I2C interface: /dev/i2c-3 Device 10DE:2208 Subsystem: 3842:3953
1010  |Info:    Registering I2C interface: /dev/i2c-20 Device 0000:0000 Subsystem: 0000:0000
1011  |Info:    Registering I2C interface: /dev/i2c-10 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-1 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-19 Device 0000:0000 Subsystem: 0000:0000
1011  |Info:    Registering I2C interface: /dev/i2c-17 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-8 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-15 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-6 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-13 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-4 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-11 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-2 Device 10DE:2208 Subsystem: 3842:3953
1011  |Info:    Registering I2C interface: /dev/i2c-0 Device 8086:A323 Subsystem: 1849:A323
1012  |Info:    Registering I2C interface: /dev/i2c-18 Device 0000:0000 Subsystem: 0000:0000
1012  |Info:    Registering I2C interface: /dev/i2c-9 Device 10DE:2208 Subsystem: 3842:3953
1012  |Info:    Registering I2C interface: /dev/i2c-16 Device 10DE:2208 Subsystem: 3842:3953
1012  |Info:    Registering I2C interface: /dev/i2c-7 Device 10DE:2208 Subsystem: 3842:3953
1012  |Info:    Registering I2C interface: /dev/i2c-14 Device 10DE:2208 Subsystem: 3842:3953
1012  |Info:    Registering I2C interface: /dev/i2c-5 Device 10DE:2208 Subsystem: 3842:3953
1012  |Info:    Registering I2C interface: /dev/i2c-12 Device 10DE:2208 Subsystem: 3842:3953
....
--------
....
1354  |Debug:   [EVGA GeForce RTX 3080Ti XC3 Gaming] is enabled
1354  |Trace:   [ResourceManager] Calling detection progress callbacks.
1354  |Debug:   [EVGA GeForce RTX 3080Ti XC3 Gaming] no devices found
1354  |Trace:   [EVGA GeForce RTX 3080Ti XC3 Gaming] detection end
1354  |Debug:   [EVGA GeForce RTX 3080Ti XC3 Ultra Gaming] is enabled
....

[rskaliotis]

@aritger I can confirm your patch fixes smbus word reads for me. Where previously the MSB would always come back as 0x00, I'm now getting full valid 16-bit words.

Could you apply this to the open source driver and the proprietary one? I'm hitting this issue on both. Thank you!

[ZetaPhoenix]

Can I clarify? We can finaly get RGB colors instead of only green for my founders edition 2080 Ti? https://youtu.be/bcKQ3YFnYM4
That always made me so angry! yum

So does it work now, or it still requires flashing a new VBIOS?

OpenRGB has recently added support for the NV_API Illumination Controller which supports the 2070 FE so control may be possible but only under Windows. If NVIDIA is willing to expose a similar API for Linux or document what the API does (IE i2c commands) then OpenRGB can add support. https://gitlab.com/CalcProgrammer1/OpenRGB/-/commit/81b385a67e5f308036c62c4c40d106983cfc381d

[ZetaPhoenix]

@aritger

I still thinks this falls under the general i2c issues that were brought up but if you want it tracked as another issue that is fine.

The patch "added" support but it did not work so I do not think this patch is ready.

[aritger]

If I understand correctly, the issue that @CalcProgrammer1 described in the first post was specific to 16-bit smbus transactions with the ENE controller. That much seems to be addressed by the patch.

Can you tell, @ZetaPhoenix, what controller your board has? I suspect it is a different controller, if your test results don't match @rskalioti's?

[ZetaPhoenix]

The information was contained in my update here: #41 (comment) along with the error after applying the patch and attempting to do a block read.

[EVGA GeForce RTX 3080Ti XC3 Gaming]
1011  |Info:    Registering I2C interface: /dev/i2c-2 Device 10DE:2208 Subsystem: 3842:3953

[darrellenns]

@aritger The original post by @CalcProgrammer1 says the following:

We have also observed issues with SMBus block operations, though doing the same block operations using I2C_RDWR ioctl (thus avoiding the SMBus layer) seem to work on the NVIDIA proprietary driver.

Has this part been addressed by the patch at all? Based on the patch contents and the tests by @ZetaPhoenix, it seems that the patch only fixes the mixed word/byte operations, and does not include anything for the block operations.

[aritger]

Fair enough. We'll look into the block operation issue. I've filed NVIDIA internal bug 3757700 to investigate that.

[amrit1711]

@ZetaPhoenix

1. Can you please request provide the output of - #i2cdetect -F x where x is the bus address which responds with 2d.
2. If there is a difference seen with Open RM and monolithic RM driver versions.
3. We are seeing below result with RTX 3080 FTW3 Ultra, can you please confirm if this the same issue you are reporting and can be considered as repro.
   3757700# i2cdump 3 0x2d i
   Error: Adapter does not have I2C block read capability

I disabled the check for block read capability in i2c-tools source to force a read anyway. It fails with -
i2c-tools-4.3# ./tools/i2cdump 3 0x2d i
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3, address 0x2d, mode i2c block
Continue? [Y/n] Y
Error: Block read failed, return code -22

[ZetaPhoenix]

@ZetaPhoenix

1. Can you please request provide the output of  - `#i2cdetect -F x` where x is the bus address which responds with 2d.

2. If there is a difference seen with Open RM and monolithic RM driver versions.

3. We are seeing below result with RTX 3080 FTW3 Ultra, can you please confirm if this the same issue you are reporting and can be considered as repro.
   3757700# i2cdump 3 0x2d i
   Error: Adapter does not have I2C block read capability

I disabled the check for block read capability in i2c-tools source to force a read anyway. It fails with - i2c-tools-4.3# ./tools/i2cdump 3 0x2d i WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3, address 0x2d, mode i2c block Continue? [Y/n] Y Error: Block read failed, return code -22

1. If you are asking about without the new modules installed they look like this: #41 (comment)
2. I was testing against the default Ubuntu drivers and the new Open GPU KM provided here with the patch. The I2C now shows up as nvkm-0000:01:00.0-bus-0001 instead of i2c-0 i2c NVIDIA i2c adapter 1 at f:00.0
3. Yes, that matches. You can also run the OpenRGB pipeline version and enable verbose logging and you can see without the Open GPU KM, we attempt to talk to the device but return an error so we skip adding the device (Firmware dump fails as the card does not support the block read). If you run under Windows the card should be detected through the nvapi.dll as that supports the block reads/writes.

[darrellenns]

Just as another data point - I also see i2c block read/write not supported on my EVGA 3070 FTW3 Ultra Gaming. This is with the 5.15.65.01 driver (via Arch Linux nvidia-dkms package).

# i2cdetect -l
i2c-0   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
i2c-1   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter
i2c-2   i2c             NVIDIA i2c adapter 5 at 1:00.0          I2C adapter
i2c-3   i2c             NVIDIA i2c adapter 6 at 1:00.0          I2C adapter
i2c-4   i2c             NVIDIA i2c adapter 7 at 1:00.0          I2C adapter
i2c-5   i2c             NVIDIA i2c adapter 8 at 1:00.0          I2C adapter
i2c-6   smbus           SMBus I801 adapter at efa0              SMBus adapter
i2c-7   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-8   i2c             Synopsys DesignWare I2C adapter         I2C adapter

# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- 2d -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -F 0
Functionalities implemented by /dev/i2c-0:
I2C                              yes
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               no
SMBus Block Write                yes
SMBus Block Read                 yes
SMBus Block Process Call         no
SMBus PEC                        no
I2C Block Write                  no
I2C Block Read                   no

[ZetaPhoenix]

Any update on the block commands?

[aritger]

I /think/ we have block commands working now, though it didn't make it into the 515 (or, now 520) release series. It should be in the release series after 520, though I can't give a firm schedule.

[ZetaPhoenix]

Is there a patch to test?

[aritger]

Note that I can easily generate at the moment; sorry.

[NoX1De]

Hello, while I've skimmed the fairly lengthy correspondence regarding this issue, I've not spent a significant amount of time to fully understand the implications of the looming patch here. I see in the original comment:

"The cards we've been focused on lately are the ASUS 3xxx series cards, which all use a similar I2C RGB chip that is also found on some ASUS motherboards and various manufacturers' RGB DRAM modules. The chip comes from ENE..."

I'm on Fedora 35 and have a ASUS 3080 12GB ROG Strix GPU I'm currently running 515.76 drivers with where I'm attempting to get OpenRGB working to change the color of the cards LED(s). I've scoured the internet and found this thread to be most relevant/potentially useful in resolving the issue I'm having if I'm not mistaken. Am I understanding this thread here correctly in that this looming patch should solve the issue where openrgb does not seem to detect this card nor let you modify it's lighting colors?

 sudo openrgb -v -l
------------------------------------------------------
|               Start device detection               |
------------------------------------------------------
Initializing HID interfaces: Success
------------------------------------------------------
|             Detecting I2C interfaces               |
------------------------------------------------------
Registering I2C interface: /dev/i2c-3 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-1 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-4 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-2 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-0 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-5 Device 10DE:220A Subsystem: 1043:886B
------------------------------------------------------
|               Detecting I2C devices                |
------------------------------------------------------
------------------------------------------------------
|               Detecting HID devices                |
------------------------------------------------------
[X570 AORUS ELITE] Registering RGB controller
[Gigabyte RGB Fusion 2 USB] successfully added
------------------------------------------------------
|              Detecting other devices               |
------------------------------------------------------
------------------------------------------------------
|                Detection completed                 |
0------------------------------------------------------
: X570 AORUS ELITE
  Type:           Motherboard
  Description:    IT8297BX-GBX570
  Version:        0x00060001
  Location:       HID: /dev/hidraw1
  Serial:         redacted
  Modes: [Direct] Static Breathing Blinking 'Color Cycle' Flashing
  Zones: 'D_LED1 Bottom' 'D_LED2 Top' Motherboard
  LEDs: 'Back I/O' 'CPU Header' PCIe 'LED C1/C2'

Looking for ASUS detections...

sudo openrgb -vv -l | grep ASUS
[ASUS Aura SMBus Motherboard] is enabled
[ASUS Aura SMBus Motherboard] no devices found
[ASUS Aura SMBus Motherboard] detection end
[ASUS Aura GPU (ENE)] is enabled
[ASUS Aura GPU (ENE)] no devices found
[ASUS Aura GPU (ENE)] detection end
[ASUS Aura GPU] is enabled
[ASUS Aura GPU] no devices found
[ASUS Aura GPU] detection end

Separately in running i2cdetect I get the following but no apparent way to use openrgb to modify the color of my ASUS 3080 lighting from the default.

sudo i2cdetect -l
i2c-0	i2c       	NVIDIA i2c adapter 1 at 29:00.0 	I2C adapter
i2c-1	i2c       	NVIDIA i2c adapter 3 at 29:00.0 	I2C adapter
i2c-2	i2c       	NVIDIA i2c adapter 5 at 29:00.0 	I2C adapter
i2c-3	i2c       	NVIDIA i2c adapter 6 at 29:00.0 	I2C adapter
i2c-4	i2c       	NVIDIA i2c adapter 7 at 29:00.0 	I2C adapter
i2c-5	i2c       	NVIDIA i2c adapter 8 at 29:00.0 	I2C adapter

Will this fix/code change that's apparently (hopefully) coming in the version after 520 rectify this problem/allow openrgb devs to complete full support for these ASUS 3080 cards?

Thank you!

[owenmylotte]

I /think/ we have block commands working now, though it didn't make it into the 515 (or, now 520) release series. It should be in the release series after 520, though I can't give a firm schedule.

This is great news! I've been following this thread for months. Thank you for looking into this.

[atta2022]

Any news?
Tried to apply openrgb on my rig with 6 cards, 4 of them works, 2 not recognised.

sudo openrgb -l
Attempting to connect to local OpenRGB server.
Connection attempt failed
Local OpenRGB server unavailable.
Running standalone.
[i2c_smbus_linux] Failed to read i2c device PCI device ID
[i2c_smbus_linux] Failed to read i2c device PCI device ID
0: Gigabyte RTX3060 EAGLE OC 12G V2
Type: GPU
Description: RGB Fusion GPU
Location: I2C: /dev/i2c-23, address 0x63
Modes: [Direct] Breathing Flashing 'Dual Flashing' 'Color Cycle' 'Spectrum Cycle'
Zones: 'GPU Zone'
LEDs: 'GPU LED'

1: Gigabyte RTX3060 EAGLE OC 12G V2
Type: GPU
Description: RGB Fusion GPU
Location: I2C: /dev/i2c-18, address 0x63
Modes: [Direct] Breathing Flashing 'Dual Flashing' 'Color Cycle' 'Spectrum Cycle'
Zones: 'GPU Zone'
LEDs: 'GPU LED'

2: ASUS TUF RTX 3080Ti O12G GAMING
Type: GPU
Description: ENE SMBus Device
Version: AUMA0-E6K5-0107
Location: I2C: /dev/i2c-28, address 0x67
Modes: Direct [Off] Static Breathing Flashing 'Spectrum Cycle' Rainbow 'Chase Fade' Chase 'Random Flicker'
Zones: Unknown
LEDs: 'Unknown LED 1' 'Unknown LED 2' 'Unknown LED 3' 'Unknown LED 4'

3: ASUS ROG STRIX 3090 O24G GAMING
Type: GPU
Description: ENE SMBus Device
Version: AUMA0-E6K5-0107
Location: I2C: /dev/i2c-12, address 0x67
Modes: Direct [Off] Static Breathing Flashing 'Spectrum Cycle' Rainbow 'Chase Fade' Chase 'Random Flicker'
Zones: Unknown
LEDs: 'Unknown LED 1' 'Unknown LED 2' 'Unknown LED 3' 'Unknown LED 4' 'Unknown LED 5' 'Unknown LED 6' 'Unknown LED 7' 'Unknown LED 8' 'Unknown LED 9' 'Unknown LED 10' 'Unknown LED 11' 'Unknown LED 12' 'Unknown LED 13' 'Unknown LED 14' 'Unknown LED 15' 'Unknown LED 16' 'Unknown LED 17' 'Unknown LED 18' 'Unknown LED 19' 'Unknown LED 20' 'Unknown LED 21' 'Unknown LED 22'

sudo i2cdetect -l
i2c-0 smbus SMBus I801 adapter at f040 SMBus adapter
i2c-1 i2c i915 gmbus dpc I2C adapter
i2c-2 i2c i915 gmbus dpb I2C adapter
i2c-3 i2c i915 gmbus dpd I2C adapter
i2c-4 i2c AUX B/DDI B/PHY B I2C adapter
i2c-5 i2c AUX D/DDI D/PHY D I2C adapter
i2c-6 i2c NVIDIA i2c adapter 1 at 1:00.0 I2C adapter
i2c-7 i2c NVIDIA i2c adapter 4 at 1:00.0 I2C adapter
i2c-8 i2c NVIDIA i2c adapter 5 at 1:00.0 I2C adapter
i2c-9 i2c NVIDIA i2c adapter 6 at 1:00.0 I2C adapter
i2c-10 i2c NVIDIA i2c adapter 7 at 1:00.0 I2C adapter
i2c-11 i2c NVIDIA i2c adapter 8 at 1:00.0 I2C adapter
i2c-12 i2c NVIDIA i2c adapter 1 at 3:00.0 I2C adapter
i2c-13 i2c NVIDIA i2c adapter 3 at 3:00.0 I2C adapter
i2c-14 i2c NVIDIA i2c adapter 5 at 3:00.0 I2C adapter
i2c-15 i2c NVIDIA i2c adapter 6 at 3:00.0 I2C adapter
i2c-16 i2c NVIDIA i2c adapter 7 at 3:00.0 I2C adapter
i2c-17 i2c NVIDIA i2c adapter 8 at 3:00.0 I2C adapter
i2c-18 i2c NVIDIA i2c adapter 1 at 4:00.0 I2C adapter
i2c-19 i2c NVIDIA i2c adapter 5 at 4:00.0 I2C adapter
i2c-20 i2c NVIDIA i2c adapter 6 at 4:00.0 I2C adapter
i2c-21 i2c NVIDIA i2c adapter 7 at 4:00.0 I2C adapter
i2c-22 i2c NVIDIA i2c adapter 8 at 4:00.0 I2C adapter
i2c-23 i2c NVIDIA i2c adapter 1 at 5:00.0 I2C adapter
i2c-24 i2c NVIDIA i2c adapter 5 at 5:00.0 I2C adapter
i2c-25 i2c NVIDIA i2c adapter 6 at 5:00.0 I2C adapter
i2c-26 i2c NVIDIA i2c adapter 7 at 5:00.0 I2C adapter
i2c-27 i2c NVIDIA i2c adapter 8 at 5:00.0 I2C adapter
i2c-28 i2c NVIDIA i2c adapter 1 at 6:00.0 I2C adapter
i2c-29 i2c NVIDIA i2c adapter 3 at 6:00.0 I2C adapter
i2c-30 i2c NVIDIA i2c adapter 5 at 6:00.0 I2C adapter
i2c-31 i2c NVIDIA i2c adapter 6 at 6:00.0 I2C adapter
i2c-32 i2c NVIDIA i2c adapter 7 at 6:00.0 I2C adapter
i2c-33 i2c NVIDIA i2c adapter 8 at 6:00.0 I2C adapter
i2c-34 i2c NVIDIA i2c adapter 1 at 7:00.0 I2C adapter
i2c-35 i2c NVIDIA i2c adapter 5 at 7:00.0 I2C adapter
i2c-36 i2c NVIDIA i2c adapter 6 at 7:00.0 I2C adapter
i2c-37 i2c NVIDIA i2c adapter 7 at 7:00.0 I2C adapter
i2c-38 i2c NVIDIA i2c adapter 8 at 7:00.0 I2C adapter

Fri Oct 28 16:00:56 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 520.56.06 Driver Version: 520.56.06 CUDA Version: 11.8 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... Off | 00000000:01:00.0 Off | N/A |
| 50% 44C P5 82W / 350W | 11800MiB / 24576MiB | 99% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 1 NVIDIA GeForce ... Off | 00000000:03:00.0 Off | N/A |
| 50% 39C P5 106W / 350W | 11786MiB / 24576MiB | 99% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 2 NVIDIA GeForce ... Off | 00000000:04:00.0 Off | N/A |
| 50% 40C P5 38W / 200W | 4722MiB / 12288MiB | 100% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 3 NVIDIA GeForce ... Off | 00000000:05:00.0 Off | N/A |
| 50% 37C P5 32W / 200W | 1136MiB / 12288MiB | 100% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 4 NVIDIA GeForce ... Off | 00000000:06:00.0 Off | N/A |
| 50% 40C P5 85W / 300W | 11524MiB / 12288MiB | 99% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
| 5 NVIDIA GeForce ... Off | 00000000:07:00.0 Off | N/A |
| 50% 35C P5 80W / 300W | 11524MiB / 12288MiB | 99% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+

cat /proc/driver/nvidia/gpus/0000:01:00.0/information
Model: NVIDIA GeForce RTX 3090
IRQ: 135
GPU UUID: GPU-5b301eb8-e2db-77ef-647a-4cbc1a540cdb
Video BIOS: 94.02.59.00.5f
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:01:00.0
Device Minor: 0
GPU Excluded: No

cat /proc/driver/nvidia/gpus/0000:03:00.0/information
Model: NVIDIA GeForce RTX 3090
IRQ: 136
GPU UUID: GPU-1b345b76-87ed-1017-e656-e93560d55088
Video BIOS: 94.02.42.00.a9
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:03:00.0
Device Minor: 1
GPU Excluded: No

cat /proc/driver/nvidia/gpus/0000:04:00.0/information
Model: NVIDIA GeForce RTX 3060
IRQ: 137
GPU UUID: GPU-d9439839-dc25-e26d-e64d-22c29f46b1a7
Video BIOS: 94.06.2f.00.f5
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:04:00.0
Device Minor: 2
GPU Excluded: No

cat /proc/driver/nvidia/gpus/0000:05:00.0/information
Model: NVIDIA GeForce RTX 3060
IRQ: 138
GPU UUID: GPU-9d950fbe-fa66-b53d-323c-ff7079cd223c
Video BIOS: 94.06.2f.00.f5
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:05:00.0
Device Minor: 3
GPU Excluded: No

cat /proc/driver/nvidia/gpus/0000:06:00.0/information
Model: NVIDIA GeForce RTX 3080 Ti
IRQ: 139
GPU UUID: GPU-e9a3381e-0cef-29d1-d96c-a9abf81593b1
Video BIOS: 94.02.71.80.79
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:06:00.0
Device Minor: 4
GPU Excluded: No

cat /proc/driver/nvidia/gpus/0000:07:00.0/information
Model: NVIDIA GeForce RTX 3080 Ti
IRQ: 140
GPU UUID: GPU-43262d09-645f-44ea-e4b7-9514bebc8e75
Video BIOS: 94.02.71.80.cc
Bus Type: PCIe
DMA Size: 47 bits
DMA Mask: 0x7fffffffffff
Bus Location: 0000:07:00.0
Device Minor: 5
GPU Excluded: No

[LarryDCJ]

I'm available at [email protected] if you need a tester. I have an EVGA 3090 FTW3 Ultra.

[aritger]

I think all of the items mentioned in this Issue are addressed by the 525.35 release. I'd appreciate if testers could confirm.

[SapphirusBeryl]

I think all of the items mentioned in this Issue are addressed by the 525.35 release. I'd appreciate if testers could confirm.

I've got an EVGA 3080 FTW3, and can confirm the i2c interface is now working with 525.35. All functionality in OpenRGB pertaining to the RGB bar is in fact working.

$ i2cdetect -l
i2c-3	i2c       	NVIDIA i2c adapter 1 at 8:00.0  	I2C adapter
i2c-4	i2c       	NVIDIA i2c adapter 5 at 8:00.0  	I2C adapter
i2c-5	i2c       	NVIDIA i2c adapter 6 at 8:00.0  	I2C adapter
i2c-6	i2c       	NVIDIA i2c adapter 7 at 8:00.0  	I2C adapter
i2c-7	i2c       	NVIDIA i2c adapter 8 at 8:00.0  	I2C adapter
$ openrgb -l
0: EVGA GeForce RTX 3080 FTW3 Ultra LHR
  Type:           GPU
  Description:    EVGA Ampere RGB GPU Device
  Version:        1.01.15
  Location:       I2C: /dev/i2c-3, address 0x2D
  Modes: Off Direct Breathing 'Spectrum Cycle' 'Color Cycle' ['Rainbow Wave'] Wave Star 'Color Stack'
  Zones: 'Front Logo' 'End plate Logo' 'Back Logo' 'Addressable Header'
  LEDs: 'Front Logo' 'End plate Logo' 'Back Logo' 'Addressable Header'

[CalcProgrammer1]

Which card isn't working for you? It looks like your two ASUS cards are properly detected, as it reads the version string. RGB Fusion GPU should work even without the changes made here as it just uses byte accesses. Do note that OpenRGB has not been well tested against systems with multiple GPUs, maybe you're running into an issue due to that. Would you be able to test them one at a time?

[NoX1De]

I can confirm sadly that it is still not working for me after upgrading to the new 525.53 drivers (ASUS 3080 12GB ROG Strix GPU on Fedora 35)...what can I do to help? I am I missing something here or doing something wrong? I don't believe I am but please let me know...happy to assist with further testing etc. etc.

Mon Nov 14 12:17:43 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.53	  Driver Version: 525.53       CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+

:~$ sudo i2cdetect -l
i2c-0	i2c       	NVIDIA i2c adapter 1 at 29:00.0 	I2C adapter
i2c-1	i2c       	NVIDIA i2c adapter 3 at 29:00.0 	I2C adapter
i2c-2	i2c       	NVIDIA i2c adapter 5 at 29:00.0 	I2C adapter
i2c-3	i2c       	NVIDIA i2c adapter 6 at 29:00.0 	I2C adapter
i2c-4	i2c       	NVIDIA i2c adapter 7 at 29:00.0 	I2C adapter
i2c-5	i2c       	NVIDIA i2c adapter 8 at 29:00.0 	I2C adapter

:~$ sudo openrgb -vv -l | grep ASUS
[ASUS Aura SMBus Motherboard] is enabled
[ASUS Aura SMBus Motherboard] no devices found
[ASUS Aura SMBus Motherboard] detection end
[ASUS Aura GPU (ENE)] is enabled
[ASUS Aura GPU (ENE)] no devices found
[ASUS Aura GPU (ENE)] detection end
[ASUS Aura GPU] is enabled
[ASUS Aura GPU] no devices found
[ASUS Aura GPU] detection end

:~$ sudo openrgb -l -v
Attempting to connect to local OpenRGB server.
Connection attempt failed
Local OpenRGB server unavailable.
Running standalone.
------------------------------------------------------
|               Start device detection               |
------------------------------------------------------
Initializing HID interfaces: Success
------------------------------------------------------
|             Detecting I2C interfaces               |
------------------------------------------------------
Registering I2C interface: /dev/i2c-3 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-1 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-4 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-2 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-0 Device 10DE:220A Subsystem: 1043:886B
Registering I2C interface: /dev/i2c-5 Device 10DE:220A Subsystem: 1043:886B
------------------------------------------------------
|               Detecting I2C devices                |
------------------------------------------------------
------------------------------------------------------
|               Detecting HID devices                |
------------------------------------------------------
[X570 AORUS ELITE] Registering RGB controller
[Gigabyte RGB Fusion 2 USB] successfully added
------------------------------------------------------
|              Detecting other devices               |
------------------------------------------------------
------------------------------------------------------
|                Detection completed                 |
------------------------------------------------------
0: X570 AORUS ELITE
  Type:           Motherboard
  Description:    IT8297BX-GBX570
  Version:        0x00060001
  Location:       HID: /dev/hidraw1
  Serial:         redacted
  Modes: [Direct] Static Breathing Blinking 'Color Cycle' Flashing
  Zones: 'D_LED1 Bottom' 'D_LED2 Top' Motherboard
  LEDs: 'Back I/O' 'CPU Header' PCIe 'LED C1/C2'

[CalcProgrammer1]

If the GPU isn't being detected at all it may not yet be added to OpenRGB. Even without the patch it looked like ASUS ENE GPUs were being detected.

…

On Mon, Nov 14, 2022 at 11:20 AM NoX1De ***@***.***> wrote: I can confirm sadly that it is still not working for for me after upgrading to the new 525.53 drivers (ASUS 3080 12GB ROG Strix GPU on Fedora 35)...what can I do to help? Mon Nov 14 12:17:43 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 525.53 Driver Version: 525.53 CUDA Version: 12.0 | |-------------------------------+----------------------+----------------------+ :~$ sudo i2cdetect -l i2c-0 i2c NVIDIA i2c adapter 1 at 29:00.0 I2C adapter i2c-1 i2c NVIDIA i2c adapter 3 at 29:00.0 I2C adapter i2c-2 i2c NVIDIA i2c adapter 5 at 29:00.0 I2C adapter i2c-3 i2c NVIDIA i2c adapter 6 at 29:00.0 I2C adapter i2c-4 i2c NVIDIA i2c adapter 7 at 29:00.0 I2C adapter i2c-5 i2c NVIDIA i2c adapter 8 at 29:00.0 I2C adapter :~$ sudo openrgb -vv -l | grep ASUS [ASUS Aura SMBus Motherboard] is enabled [ASUS Aura SMBus Motherboard] no devices found [ASUS Aura SMBus Motherboard] detection end [ASUS Aura GPU (ENE)] is enabled [ASUS Aura GPU (ENE)] no devices found [ASUS Aura GPU (ENE)] detection end [ASUS Aura GPU] is enabled [ASUS Aura GPU] no devices found [ASUS Aura GPU] detection end :~$ sudo openrgb -l Attempting to connect to local OpenRGB server. Connection attempt failed Local OpenRGB server unavailable. Running standalone. 0: X570 AORUS ELITE Type: Motherboard Description: IT8297BX-GBX570 Version: 0x00060001 Location: HID: /dev/hidraw1 Serial: redacted Modes: [Direct] Static Breathing Blinking 'Color Cycle' Flashing Zones: 'D_LED1 Bottom' 'D_LED2 Top' Motherboard LEDs: 'Back I/O' 'CPU Header' PCIe 'LED C1/C2' — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIAY7DEKA4GUWGNOJNL3ZLWIJYHJANCNFSM5VWWIISA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[NoX1De]

I see, is there anything I can do to help get the process started to have the GPU added to OpenRGB or is there already an open issue to get the ASUS 3080 12GB ROG Strix and additional ASUS GPU's supported now that the Nvidia drivers seem to have the required code changes? I would assume there's an open issue now that I re-read the original issue here, so maybe I just need to wait for the changes in OpenRGB, that said let me know if I can help at all.

[CalcProgrammer1]

We just need the PCI Vendor ID, Device ID, Subvendor ID, and Subdevice ID along with the official marketing name of the card (link to ASUS website would be good). There's a 99% chance it has the same i2c chip at the same address as all of the other 3xxx ASUS cards but to be safe we have an allow list of known GPU IDs so we don't accidentally try controlling any I2C device with the wrong protocol.

[CalcProgrammer1]

Also, make sure you're using the latest pipeline/git version of OpenRGB. A lot of GPUs have been added to the list since 0.7.

[atta2022]

ok, will report my issue to /dev/null, thank you.

[aritger]

There is no need for snark, @atta2022

All I suggested was that separate problems should be tracked as separate Issues, which doesn't seem an unreasonable engineering practice. If you believe the problem you are seeing is the same as the problem originally reported in this Issue, then let's work it here. Otherwise, please file a separate Issue.

From the comments above, @CalcProgrammer1 already suggested to help isolate the problem you are seeing by testing the GPUs individually. Further, there was an indication that the path you are hitting through OpenRGB wouldn't have been impacted by the particular driver bug we were originally tracking in this Issue. Maybe your configuration is tripping on an issue in OpenRGB, or maybe you've found a different driver bug. In either case, separating different problems into different github Issues will make it easier to solve the problems.

[NoX1De]

Thanks @CalcProgrammer1, given the comment above- in an effort to not clutter this issue if it's not due to the originally reported issue here I've pinged you at the link below to move the conversation there, it seems my card may already have support added in OpenRGB given that issue, so I'm not sure what is going on at this point? Am I missing something? This also may beg the question that there may still be some problems related to the original issue reported here, hence this comment on this thread again. For now, I will take the conversation elsewhere unless we discover my problem is due to the original reported in this issue since related dialog is seemingly discouraged here.

https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/2508

[NoX1De]

Hi there @aritger, I've done some testing with the new 525.53 drivers and modifying the LED colors for my ASUS 3080 12GB ROG Strix GPU and it seems that there may still be some issues with the Nvidia driver. I swapped back to the Nouveau drivers and everything works great, any color I specify is set as expected. The issue is that when attempting to specify a certain color to change the LED(s) to when using the latest version of OpenRGB with the 525.53 drivers it will not set the LED(s) to the specified color code and just always sets the color to blue no matter what color code is specified. The Nvidia drivers do work with some "preset" modes (e.g. 'Spectrum Cycle', Rainbow) but any mode where you attempt to manually specify a color/colors does not work and it will always just be set to blue when using the Nvidia 525.53 drivers.

See more detailed comments here: https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/2508

[CalcProgrammer1]

I believe this is due to the handling of SMBus block operations. The mode is set using standard byte operations but the colors are set using 3 byte blocks. An SMBus block write operation of 3 bytes of data actually contains 5 bytes of data and I expect NVIDIA is getting it wrong in your case. It should send the on-chip register address, the data size (3), and then the 3 data bytes (color data). In addition on the ENE controller it first performs a word write containing a 16 bit ENE register, but this part of the NVIDIA driver has been fixed already if your version string looks good and the mode setting works.

…

On Fri, Nov 18, 2022 at 6:28 PM NoX1De ***@***.***> wrote: Hi there @aritger <https://github.com/aritger>, I've done some testing with the new 525.53 drivers and modifying the LED colors for my ASUS 3080 12GB ROG Strix GPU and it seems that there may still be some issues with the Nvidia driver. I swapped back to the Nouveau drivers and everything works great, any color I specify is set as expected. The issue is that when attempting to specify a certain color to change the LED(s) to when using the latest version of OpenRGB with the 525.53 drivers it will not set the LED(s) to the specified color code and just always sets the color to blue no matter what color code is specified. The Nvidia drivers do work with *some* "preset" modes (e.g. 'Spectrum Cycle', Rainbow) but any mode where you attempt to manually specify a color/colors does not work and it will always just be set to blue when using the Nvidia 525.53 drivers. See more detailed comments here: https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/2508 — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIAY7HQUB4P3QWVDHDMSLLWI7DFTANCNFSM5VWWIISA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[darrellenns]

Tested successfully with 525.60 and EVGA 3070 FTW3 Ultra. Setting various RGB modes and colors via OpenRGB all worked as expected.

[NoX1De]

I updated to 525.60.11 and the latest version of OpenRGB (0.81)...and I just wanted to report/confirm that setting specific colors is still not working with my ASUS 3080 12GB ROG Strix GPU. All attempts to set a specific color still just only sets the LED(s) to blue aside from the pre-configured modes (e.g. Spectrum Cycle, Rainbow...)

$ sudo openrgb -l
0: ASUS ROG STRIX RTX 3080 O12G
  Type:           GPU
  Description:    ENE SMBus Device
...snip...

$ openrgb -V
OpenRGB 0.81, for controlling RGB lighting.
  Version:		 0.81
  Build Date		 Wed, 07 Dec 2022 00:33:26 -0500
  Git Commit ID		 cf610fa559fcde6f2d49ee8b9c1a53f7b3694642
  Git Commit Date	 2022-12-06 21:43:50 +0100
  Git Branch		 master

Wed Dec  7 00:42:58 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.60.11    Driver Version: 525.60.11    CUDA Version: 12.0     |
|-------------------------------+----------------------+----------------------+

[atta2022]

I gave up, also with version 0.81 openrgb and new drivers nvidia its still NOT possible to set all my cards. 2 simply not identified, what is weird because temp sensor is also being read by (mining) software.

[gardotd426]

I wanted to make sure I came back to confirm that my EVGA XC3 Ultra 3090 is now detected when using the 525 branch of the NV driver and current master of OpenRGB (built from source yesterday).

The XC3 Ultra has two zones - both EVGA lohos, one along the top of the card and another on the backplate. Both show up in the main tab of the OpenRGB GUI, and I can set them to specific colors with no issue, and the two zones also show up as options for Hardware-Sync lighting in the HWSync plugin. I would say that for my card at least, the current state of things amounts to 99% compatibility. The only thing that I believe a reasonable user would expect to work but that still doesn't is using the GPU as the SOURCE for the HWSync plugin.

To clarify, I can go right now and add both zones to my AIO and have the GPU lighting change depending on my CPU temperature, or I could sync it to anything else detected by lm-sensors. I imagine most of us here already know why it doesn't work - Nvidia doesnt use the standard sysfs method of reporting thermals, power draw, etc. Instead they use the nvcontrol X11 extension, aka libxnvcntrl. This is how GreenWithEnvy is able to show temps, fan speeds, set fan curves, etc. Its also why we don't have fan control/thermal monitoring in Wayland (@ the NV engineers here: surely this is coming soon along with VRR in Wayland, right? I mean VRR support plus a method for controlling temps, clocks, power limits, etc are basically the only things NV lacks on Wayland vs AMD, and NVControl can't make the jump, and X is dead).

But even without an lm-sensors way to monitor temps for OpenRGB, I think we could probably pretty easily get it working in the interim. @CalcProgrammer1 should I post on the GitLab about how best to go about sending thermal data to OpenRGB? I mean GWE has a button you can click that will pop out a new window with rolling graphs showing current and past fan speed, temps, clocks, everything. The code Rob uses to get the data is already there, its just in python. But he would probably be willing to lend a hand, and maybe until NV has a universal method for reporting such things, we could add a patch fhat checks to see if the user is on X11 and has libxnvcntrl installed, and if so then OpenRGB (or the plugin, idk) would show the GPU data as options in stuff like HWSync.

Or maybe we could send the data from GWE to OpenRGB through its server protocol?

[gardotd426]

I gave up, also with version 0.81 openrgb and new drivers nvidia its still NOT possible to set all my cards. 2 simply not identified, what is weird because temp sensor is also being read by (mining) software.

@atta2022 ....mining software? What are you mining, literal coal? It'd be more of a real thing than GPU cryptomining. So if you're not mining, then why on earth would you use mining software to get temps?

Because we already have a great GPU clocks/power limits/fan curve/temperature app for NV on X11 on Linux. GreenWithEnvy.

And there's not a single thing weird about 2 of your cards reporting their temps to your mining software, because thats literally a completely different plane of existence than using SMBUS/i2c to control RGB lighting. Thermal get reported through a different subsystem.

I would follow the devs' recommendations and isolate your issue and then report it in a new thread either here or at the OpenRGB gitlab, depending on whose issue it is.

[CalcProgrammer1]

I wanted to make sure I came back to confirm that my EVGA XC3 Ultra 3090 is now detected when using the 525 branch of the NV driver and current master of OpenRGB (built from source yesterday).

The XC3 Ultra has two zones - both EVGA lohos, one along the top of the card and another on the backplate. Both show up in the main tab of the OpenRGB GUI, and I can set them to specific colors with no issue, and the two zones also show up as options for Hardware-Sync lighting in the HWSync plugin. I would say that for my card at least, the current state of things amounts to 99% compatibility. The only thing that I believe a reasonable user would expect to work but that still doesn't is using the GPU as the SOURCE for the HWSync plugin.

To clarify, I can go right now and add both zones to my AIO and have the GPU lighting change depending on my CPU temperature, or I could sync it to anything else detected by lm-sensors. I imagine most of us here already know why it doesn't work - Nvidia doesnt use the standard sysfs method of reporting thermals, power draw, etc. Instead they use the nvcontrol X11 extension, aka libxnvcntrl. This is how GreenWithEnvy is able to show temps, fan speeds, set fan curves, etc. Its also why we don't have fan control/thermal monitoring in Wayland (@ the NV engineers here: surely this is coming soon along with VRR in Wayland, right? I mean VRR support plus a method for controlling temps, clocks, power limits, etc are basically the only things NV lacks on Wayland vs AMD, and NVControl can't make the jump, and X is dead).

But even without an lm-sensors way to monitor temps for OpenRGB, I think we could probably pretty easily get it working in the interim. @CalcProgrammer1 should I post on the GitLab about how best to go about sending thermal data to OpenRGB? I mean GWE has a button you can click that will pop out a new window with rolling graphs showing current and past fan speed, temps, clocks, everything. The code Rob uses to get the data is already there, its just in python. But he would probably be willing to lend a hand, and maybe until NV has a universal method for reporting such things, we could add a patch fhat checks to see if the user is on X11 and has libxnvcntrl installed, and if so then OpenRGB (or the plugin, idk) would show the GPU data as options in stuff like HWSync.

Or maybe we could send the data from GWE to OpenRGB through its server protocol?

This is not an issue with NVIDIA's driver at this point. I think the appropriate place to post this would be on the Hardware Sync Plugin GitLab (https://gitlab.com/OpenRGBDevelopers/OpenRGBHardwareSyncPlugin IIRC) if you're having an issue with a missing data source in the plugin, or you could post a feature request to GWE to add OpenRGB SDK integration (not sure that's in scope of their project). OpenRGB itself does not provide hardware sync or effects, so opening an issue on the OpenRGB GitLab is not the way to go.

[colinjmatt]

I updated to 525.60.11 and the latest version of OpenRGB (0.81)...and I just wanted to report/confirm that setting specific colors is still not working with my ASUS 3080 12GB ROG Strix GPU. All attempts to set a specific color still just only sets the LED(s) to blue aside from the pre-configured modes (e.g. Spectrum Cycle, Rainbow...)

Confirmed this is also still the case on an ASUS Strix LC 3080 TI with nvidia 525.60.11-3 on Arch Linux

[dev-m-mulvey]

Confirming that the same issues mentioned by @colinjmatt and @NoX1De occur using openrgb v0.81 and nvidia 525.60.11 on a system using an asus TUF RTX 3080Ti O12G card and manjaro linux (xfce) OS.

[owenmylotte]

Hello. I'm wondering if there is a specific thread for the issue mentioned above? (@CalcProgrammer1 @KidA3995 @colinjmatt @NoX1De)

I'll expand on the symptoms a bit in case it gives a clue to what is going wrong:

• OpenRGB sucessfully recognizes my card (ASUS ROG STRIX 3060 O12G V2 GAMING) and is able to set different modes as far as default color cycles and time dependent flashing things is concerned.
• However, the colors are being written incorrectly and this is happening in a very specific way.
  • The red channel writes blue to the LEDs.
  • The blue channel and green channel both write an extremely faint but just barely visible red to the LEDs.

So, the only color that can come out of the LEDs is blue, effectively.

Thanks for all of the help so far.

[NoX1De]

Hello. I'm wondering if there is a specific thread for the issue mentioned above? (@CalcProgrammer1 @KidA3995 @colinjmatt @NoX1De)

I'll expand on the symptoms a bit in case it gives a clue to what is going wrong:

• OpenRGB sucessfully recognizes my card (ASUS ROG STRIX 3060 O12G V2 GAMING) and is able to set different modes as far as default color cycles and time dependent flashing things is concerned.

• However, the colors are being written incorrectly and this is happening in a very specific way.

  • The red channel writes blue to the LEDs.
  • The blue channel and green channel both write an extremely faint but just barely visible red to the LEDs.

So, the only color that can come out of the LEDs is blue, effectively.

Thanks for all of the help so far.

AFAIK this is still a Nvidia driver issue per the details found in this comment #41 (comment) I am not sure where this currently stands but @aritger was the last Nvidia person to comment, is there perhaps any update on the issue described in the comment I've linked here from @CalcProgrammer1 in terms of this being rectified in a newer driver version or otherwise? There seems to be a number of people wondering if this will be fixed at this point.

[WACOMalt]

I just want to confirm that I see the same behavior with manual color control on my "Asus Rog Strix 3090 O24G Gaming".
Spectrum Cycle and Rainbow work fine. But any manual color control results in Blue.
I am testing in v0.9 of OpenRGB with NVidia drivers 535 (535.129.03-0ubuntu0.22.04.1 full version name).

I'm happy to test further if there's anything I can contribute. Is there any separae issue yet for this on NVidia's end?

[Kwandos]

My apologies, this fell off my radar. Thanks to @CalcProgrammer1's diagnosis in #41 (comment), hopefully this is fairly easy to resolve. I've filed NVIDIA internal bug 4396674 for the always-blue symptom.

I have the same problem on my ASUS TUF GAMING V2 3070 ti, wondering if there will be a fix?

[Andresdiaz16]

I have the same issue with a ASUS ROG STRIX 3080ti, Openrgb -v 0.9.2, nvidia-drivers = 550.54.14, on Arch Linux if I can help testing let me know.

[GHJebus]

I'm seeing what I believe to be this same issue with my ASUS 4070 Ti Super. Windows works fine with setting addressable colors via Armoury Crate or OpenRGB however under linux OpenRGB colors are 'garbled'. And it's random on reboot. In one case only Red could be set and it appeared Blue, and in another case Red is Teal, and Green and Blue are both Green. Though after a fresh boot from a power off state it presents consistently as Red is Blue and Green/Blue are ignored.

Because OpenRGB color addressing works in Windows, I can only assume it's something with the linux nvidia driver. I'm currently using driver 550.54-14, and a fork of OpenRGB 0.91 with added support for the ASUS TUF RTX 4070 Ti Super O16G Gaming card.

I'm happy to help with debugging/patching to assist getting to the root of the issue. Though, in the mean time, are there any updates with the filed bug 4396674?

Thanks!