I can only seem to get the color Red Working about msi-rgb HOT 15 OPEN

Same result with the MSI B350M Mortar (Ryzen+Linux rig)

Red is the default color that the RGB header outputs out of the box, before the gaming app is run. So it can be considered the unactivated/uninitialized state of the header.

It seems that maybe that msi-rgb needs to be run after the gaming app?
You could try using the gaming app to initialize the header to white (all RGB channels on full)
Then try running the msi-rgb build.

I went over all the bits being set in the code, and they seem to be correct for the red channel.

For example, this gives a nice red glow effect:

sudo ./target/release/msi-rgb dcffdebc 00000000 00000000 -d 6

Note the unexpected little-endian byte notation required to set the curve (the big-endian curve cdffedcb is not smooth)

Suspect that msi-rgb is missing some registers in the current bank, or maybe in another bank that gets hit by the gaming app (Nagisa certainly has run the gaming app, which would flash those missing registers).

Would need to test on a new uninitialized sio chip to confirm. These secret registers might activate the header. RGB is extremely marketing focused, so understandable that MSI would not release the details.

I really don't want to put Windows on my nifty new Ryznix rig to test this. Maybe wine can run the gaming app - will try that.

from msi-rgb.

from msi-rgb.

It makes sense that the Arctic board would be default white RGB .. maybe that is why all RGB channels are working for you.

Also at the driver level, many chipsets are little-endian.

Anyway, great work - you should get danger pay for reverse engineering embedded chipset designs.
I really like how the effects are zero CPU load and persistent across reboots.

BTW - tried running the MSI gaming app under wine - it can't even.

from msi-rgb.

I found the problem area in the msi-rgb code for this issue.
If you comment out the following block, everything works on a standard B350M Mortar.

    let ff_val = (step_duration >> 8) as u8 & 1 |
                 0b10 |  // if 0 disable lights on rgb header only, not on board
                 if invs.contains(&"b") { 0b10000 } else { 0 } |
                 if invs.contains(&"g") { 0b01000 } else { 0 } |
                 if invs.contains(&"r") { 0b00100 } else { 0 };
    write_byte_to_cell(f, base_port, 0xff, ff_val)?;

• You will lose the ability to invert colors, I can live with that.
• Also, the high order byte of step_duration is lost.
• If you already ran msi-rgb with that block, you must reset the SIO chip by running the Gaming App.

Perhaps @nagisa could look into this further.

Notes:

• The SIO id returned by my board (standard B350M Mortar) is 0xD352.
• CPU-Z lists it as NCT6795 (not NCT6795D) is this different than on the Arctic variant of the Mortar?
• As proof this is working:

BEHOLD DANTE'S SHIMMERING FIRES OF THE SEVENTH CIRCLE !!
sudo ./target/release/msi-rgb dcffdebc 23112233 00000000 -d 3
sudo ./target/release/msi-rgb dcffdebc 23112233 00000000 -d 3 -p

from msi-rgb.

from msi-rgb.

@parakrama1995 can you confirm that doing the change described by @dcerisano "fixes" it for your board?

from msi-rgb.

He might also want to try:
sudo /sbin/modprobe nct6775 force_id=0xd120
This supports the missing nct6795D driver as of kernel 4.12.10
(also gets the sensors and pwm fancontrol working)
See RGB ALL THE THINGS

from msi-rgb.

from msi-rgb.

Well, it is related in that both the sensors and the rgb header are controlled by the same SIO chip, plus neither is directly supported yet in the latest release of the Linux kernel (4.12.10).
BTW - I am trying to drive traffic to the MSI-RGB repo to get more mobos supported ..
https://github.com/dcerisano/RGB-LED-Motherboard-Header-Driver-App

from msi-rgb.

@dcerisano If you comment out that block in the code, does that also remove the need to initialize the header with the MSI gaming app in Windows?

I'm curious because you said that if you already ran msi-rgb without that block commented out you'd have to reset the SIO by running the gaming app. Or am I just grasping at straws here?

from msi-rgb.

You only need to reset the SIO chip if you already ran the tool without commenting out the lines before.

Another method to "reset" the SIO chip is to unplug the power (flip the switch on the PSU) and hold the power on button for a few seconds.

from msi-rgb.

The tool should otherwise "initialise" the SIO just fine.

from msi-rgb.

Oh, okay. I was just curious because a user by the name of DGxInfinitY made a comment in an issue thread for RGB-LED-Motherboard-Header-Driver-App (which uses msi-rgb) about needing to have the MSI gaming app initialize the headers.

If you'd like to read his post, here's a link to the thread: dcerisano/RGB-LED-Motherboard-Header-Driver-App#3

So, if I understand correctly, I wouldn't have to use the gaming app on Windows first to be able to use msi-RGB to control the lights on the motherboard?

from msi-rgb.

Well, msi-rgb definitely does intiialise the RGB functionality correctly on my mortar arctic, I cannot vouch for anything else.

from msi-rgb.

You can use tools like RWEverything to confirm that the correct init codes for a specific SIO variant are provided to msi-rgb.

Keep in mind some manufacturers are withholding the spec sheets for proprietary rgb controllers, so this is the only way to confirm the codes.

from msi-rgb.