msi-rgb
msi-rgb copied to clipboard
nagisa
Which Motherboards? Intel or AMD-only? Z-series?
Which MSI motherboards does this utility work on? Also, does it only work on MSI’s AMD motherboards, or does it also work on their Intel motherboards? Does it only work on MSI’s B-series of motherboards, or does it also work on MSI’s Z-series motherboards?
In the README he mentions that it supports motherboards using the Nuvoton NCT6795D Super I/O chip. In the blog post linked in the README hey says that he has MSI B350M Mortar Arctic.
I have a MSI B350 Tomahawk which uses NCT6795D-N and msi-rgb does not work. So it seems to be very specific for the Super I/O chip or even motherboard.
Oh, okay. Maybe he should just rename it MSI-B350M-MORTAR-ARCTIC or something like that. And maybe provide a list of motherboards that this actually works on.
I was just curious because I had thought about buying one of MSI’s Z-series motherboards, and I was wondering if it would be possible to control the RGB lighting on it in Linux.
@arnarg The -N is irrelevant. I had made a mistake a while ago that was present during all the publicity period. If you tried the utility during that period, try again and it might just work this time around.
@RedSoxFan04 This utility is only really tested on the NCT6795D chip. It might or might not work on motherboards with other chips, but it is on you to test that out. If the utility does not work and you got a NCT6795D chip on your motherboard, it is probably a bug.
For the reference, I’ve seen Z-series motherboards that use this chip, so your motherboard might have the chip as well.
@nagisa I tried it yesterday on Arch Linux. Admittedly I didn't debug it much, just tried your examples and they had no effect. I will however look into this as my led strip is now on full brightness with no way to change it.
I added some code to check whether the application is really working with a chip that claims to be NCT6795D as well as some flags to set a different port at which the chip may be accessible.
I tried it again with the new changes. If I set the base port to anything other than the default 4a it throws an error. When I try to change the color it prints nothing and returns 0. The leds are unaffected.
Is there anything I can do to debug what's happening?
anything other than the default 4a it throws an error.
4e, you mean? This at least means that by default we indeed are communicating with the right chip on your board.
So, here's an interesting thing… I’ve plugged in another SATA device and the leds stopped chinging for me as well. Until I booted into Windows and ran the MSI junk again. Needs more investigation I guess.
Seems like draining power from the system (switch the PSU off and click the power button) also resets the super I/O chip enough to make the tool not work.
@arnarg please try again (commit https://github.com/nagisa/msi-rgb/commit/b5a16876fe3cd29748e2941e79bb49077090d973).
@nagisa Yeah I meant 4e.
Now we're getting somewhere! When I run
sudo ./target/release/msi-rgb 00000000 FFFFFFFF 00000000
The LEDs completely turn off for a few seconds and then slowly fade on to green. At least now I can turn them off at night! :+1:
I tried a few of your animated samples and they just turn off the LEDs. I have waited for a while but they don't seem to fade on like the solid colors.
No wait! I didn't notice this because I was just watching the led strip but I tried your Happy Easter example and the motherboard backlight started blinking. Is there some onboard lighting on the MSI B350M Mortar Arctic?
sudo ./target/release/msi-rgb 00000000 FFFFFFFF 00000000The LEDs completely turn off for a few seconds and then slowly fade on to green. At least now I can turn them off at night! 👍
Nice. This should immediately switch to green, though, rather than fade. I’m sort of suspecting RGB header just might not have the juice necessary to drive your strip? (Alternatively, the sI/O is simply set to provide the least amount of current by default and I have no idea how to change that :)) How long does it take for the colour to "fade" in? What does something like this:
sudo ./target/release/msi-rgb 0F0F0F0F F0F0F0F0 00000000 -d250 # or even larger number
look like?
I’m sort of suspecting RGB header just might not have the juice necessary to drive your strip?
I find that highly unlikely. I read in the manual that the LED strip connector has power rating of 3A.
I have about a meter of it installed (probably). That length should not draw 3A and it was very bright with all the colors on before successfully turning them off. Just the green should be about 1/3 of the current draw of all of the colors.
sudo ./target/release/msi-rgb 0F0F0F0F F0F0F0F0 00000000 -d250 # or even larger
Seems to just turn it off.
I might just install windows and see how it behaves.
How long does it take for the colour to "fade" in?
It stays completely off for about 12 seconds and it takes about 8-10 seconds to fade on. Keep in mind this was just counting the seconds in my head.
But here's something interesting.
sudo ./target/release/msi-rgb 00000000 FFFFFFFF 00000000
After it has completely turned on as green I then run
sudo ./target/release/msi-rgb 00000000 FFFFFFFF FFFFFFFFF
and the green stays on for the ~12 sec delay and then the blue starts fading on.
@arnarg Could you please pull down the most recent commit and paste the output of
sudo ./target/release/msi-rgb --print-current 0 0 0 # or whatever colours you use
>> sudo ./target/release/msi-rgb --print-current 0 0 0 Bank 12 (d0...100): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0 00 00 00 00 00 00 00 ff ff 11 00 04 34 01 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 02 Bank 09 (20...40): d3 52 ff 00 00 00 40 13 00 ff 58 01 11 00 00 11 0f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Bank 0b (60...70): 0a 20 0a 40 00 00 ff ff ff ff ff ff ff ff ff ff
They values don't change until I run it the second time, but I guess you're printing it before actually changing the values?
I've also noticed that anything less than FFFFFFFF on any of the colors turns the color completely off forever. So it's completely on or completely off for each color. Seems like PWM isn't working correctly or something.
Changing the -b value takes effect immediately even though the color is still fading on.
They values don't change until I run it the second time, but I guess you're printing it before actually changing the values?
Yes that was intended.
So, there were two differences between register values in your case and mine. I’ve set my sI/O to have the same values as in your case and still could not reproduce. There may be a difference somewhere else entirely, but I’ve no idea where to look for them.
The last I can think of to try, before you install Windows to check: power off your computer, switch off your PSU or unplug it entirely, press the power button, switch the PSU back on/plug back in, turn on the computer and try again.
I've also noticed that anything less than FFFFFFFF on any of the colors turns the color completely off forever
Very weird. All I can say that this is getting ever so weirder and unlikelier to reproduce.
Seems like PWM isn't working correctly or something.
I think RGB header does not use PWM and simply adjusts the voltage of the pin(s).
The last I can think of to try, before you install Windows to check: power off your computer, switch off your PSU or unplug it entirely, press the power button, switch the PSU back on/plug back in, turn on the computer and try again.
That didn't change anything.
I think RGB header does not use PWM and simply adjusts the voltage of the pin(s).
How is that possible with a common anode? There is a single +12V and the R, G and B pins are grounded to turn on the LEDs. I guess it should be possible to current limit the pins somehow.
I have a Windows USB ready. Is there anything specific you'd like to see from my quest?
Not really. I’m interested if setting colours with MSI’s gaming app react to changes quickly and maybe whether this utility works fine afterwards.
Getting a dump of sI/O writes and reads would be nice, of course, but is non-trivial to achieve.
@nagisa No sorry, I was getting ready to boot up Windows ISO when life got in the way. I'll try to find time soon.
I also see the same things on my B350 Tomahawk Arctic
sudo ./target/release/msi-rgb 0 0 0
switches off everything insantly
sudo ./target/release/msi-rgb FFFFFFFF FFFFFFFF FFFFFFFF
takes 12s to start fading an another 12s to go full brightness white (with slight purple hint in my case)
sudo ./target/release/msi-rgb FFFFFFFF 0 0
switches to red instantly
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb FFFFFFFF FFFFFFFF 0
goes to yellow after 12s delay and 12s fade in
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 EFFFFFFF
goes immediately off and stays like that
for any of the values below
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 EFFFFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FEFFFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFEFFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFEFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFFEFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFFFEFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFFFFEF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFFFFFE
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 7FFFFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FF7FFFFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFF7FFF
(master ±) msi-rgb ツ sudo ./target/release/msi-rgb 0 0 FFFFFF7F
the light goes/stays off and nothing happens
So my conclusions are (valid for each individual color (R,G or B) separately):
- one can only either fully switch on of fully switch off the light (not brightness adjustment)
- the switching off happens directly, when using 00000000
- swtiching on happens with 12s delay and 12s fade in , when using FFFFFFFF
@adrianstaniec could you try after changing the 3 linked lines to
if d & 0xe7 != 0xe7 {
outb(f, base_port + 1, 0xe7 | (d & !0xe7))?;
}
please?
I changed the lines, recompiled, but I don't see any effect.
btw. I noticed something else, maybe worth to mention.
When I switch off with:
./msi-rgb 0 0 0
the LEDs switches off really quickly
but when using non zero and non FFFFFFFF
like for example
When I do for example:
./msi-rgb 0 0 00FFFFFF
it takes about a second for the LEDs to switch off
For what it's worth, back in the early days of my Tomahawk I contacted Msi to ask about the color limitation and they replied that my hardware could not support any other colour except from the 7 ones you can choose from the Gaming App. It sounded just like an excuse at first, but while reading this thread I've thought that it actually could be true: You have just 2 states (on/off) for each channel (R, G and B), so the total number of colours you can make is 2^3=8. Now if you remove the all-leds-off combination you get 7, which is exactly the number of options in the Gaming App.. The hardware PWM could really be screwed up.
Maybe it could be possible to make a software timer to simulate a PWM wave by turning on and off the channels very fast (a 50Hz duty cycle would be enough i think), provided that the chip can handle such frequent writes.
I have an MSI B350 board and have found that msi-rgb only works if you first dual boot into Windows, and run the msi gaming app to properly initialize the RGB header.
Just select white and dual boot back into Linux. After that, msi-rgb works as expected.
Obviously my specific SIO controller for the RGB header is not being properly initialized by the msi-rgb utility, but this only needs to be done once.
Also keep in mind RGB SIO controllers are farily recent, proprietary, and don't yet have full Linux driver support.
I have given up on trying to reverse engineer SIO drivers from Windows to Linux, and simply bought a $10 fully addressable WS2812B RGB controller that is the size of a bean and fully powered by USB.
It runs on all mobos, all OSes, and has APIs in pretty much every language. Did I mention it is fully addressable?
Yes, initialization was a problem once which I didn't account for initially, as it only shows up after power is drained from the system.
That being said, without initialisation the utility does not work at all, so there's that.
As for 7 colours. It could be a case but it certainly is not a technical limitation given the same chip is used in all the boards I've seen/heard about so far. The chip might be configured to only support 7 colours via e.g. unconnected feature pin or something, which would mean MSI is an ultimate asshole, more than it is already.
As for some update I've recently had an idea on how we could easily inspect the inner workings of the gaming app with different boards, but I'm fairly busy lately and might not be able to get to it for a little while.
On Nov 7, 2017 10:28 PM, "Dominic Cerisano" [email protected] wrote:
I have an MSI B350 board and have found that msi-rgb only works if you first dual boot into Windows, run the msi gaming app to properly initialize the LEDs.
After that, msi-rgb works as expected on linux.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/2#issuecomment-342611947, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0lbGIU5H-2WCZ47RNXQvd-BNHlRGks5s0L1_gaJpZM4NEqfI .
