msi-rgb
msi-rgb copied to clipboard
nagisa
Asrock Fatal1ty X370 Gaming X
NCT6779D appears to be common across ASRock boards, comparing data sheet data with the chip supported here and it looks identical
so it is just adding it to the same group?
i can test if you do the above.
I added the chip ID but the output wasn't the same as for the msi. Looking through rw-everything through the super-io registers (like og author did for msi) it doesn't appear that asrock is using the same superio method to control the rgb header. I'm thinking its going over i2c or another comm. method.
It is likely the two protocols are similar. You should be able to replace the msi-rgb port bank control bytes with the ones you are seeing in rw-everything.
I don't see any byte changes in rw-everything when changing colors using the ASRock utility
Perhaps you are filtering the wrong port banks? I believe rw-everything has a 'promiscuous mode' that will show all port bank bytes in/out.
Just curious, could you also try sniffing the usb traffic while ASRock utility is running? I glanced at the spec sheet for the NCT6779D SIO chip, and did not see any RGB control specifically mentioned. The RGB control layer might exist only the BIOS microcode. Still pretty sure it's using 3 SIO pwm lines for RGB 50/50 header, so rw-everything should see it. Also make sure you run rw-everything as administrator, since ports are protected memory.
There are multiple things that could have happened here:
- The RGB is controleld by SIO and interaction with SIO is done over the ISA bus. However, the ASRock utility may be implemented better compared to MSI’s embarrassing display of incompetence and cleans up after its operations, which would end up not displaying changes in the rw-everything as easily as they were visible with the MSI tool.
- The RGB is controlled by a different chip, and the communication protocol used is different (e.g. SMBus, PCI(e), etc.). In that case you may need to do something else entirely. You can look over the board for suspect chips. On Asus’ boards it is obvious because their chips have "aura" printed on them. Perhaps something of the sort will be true for ASRock as well.
- It is possible that the RGB control is done via firmware APIs (e.g. by talking with the UEFI via its runtime services). In that case poking with oscilloscope and/or disassembling said firmware will be necessary.
I would recommend to at least look at the symbols from the ASRock’s utility and see if they are telling in any way.
@dcerisano I tried all banks available in rwe. The specsheet for the chip covered in this repo doesn't list RGB control either; in the superio section it lists bank 12 as reserved.
That said, before I head out to work, here are the symbols from the exe taken with snowman: https://gist.github.com/sovanyio/9776a63897a3c46608f150ca57b64234
Ah so. You will need the symbol tables for the exe and dlls, which ASRock might not have shipped. Obviously MSI does include the symbol tables, perhaps in the reasonable expectation that one has the time to reverse engineer their protocols this way. @nagisa is the only one that has done it, only for one specfic SIO chip from one specific mobo.
I've discovered that Asus' Intel boards use the super IO chip's built in SMBus controller to send commands to the Aura chip. AMD boards use the chipset (x370, 470, etc) SMBus controllers and Intel boards use the Intel PCH SMBus controller for RGB RAM control but we were stumped as to where Intel boards connected the on-board controllers.
May be similar for ASRock and others. I ended up writing an i2c driver for the NCT6793D's SMBus master. I plan on porting it to Linux soon.
we were stumped as to where Intel boards connected the on-board controllers.
Just curious, but who are "we"? Are you doing this commercially? Great work, btw ... I know it takes a lot of patience and persistance.
Me and some other people helping out in the GitLab issue comments, nothing commercial.