msi-rgb
msi-rgb copied to clipboard
nagisa
Hi, can you provide a windows app.
I need a windows app because I don't like to use MSI gaming app, but i want to control the rgb light.
Thank you.
Providing an app for Windows would involve writing a kernel driver (as far as I can tell), getting the driver signed (something I have no idea how to do), and figuring out how to make Windows load the driver.
I cannot dedicate time for all the effort needed to release a Windows application myself, but if you, or anybody else, wants to help, I’ll gladly accept it.
Thank you for you reply, i found a project which can control the msi card without gaming app: https://github.com/Vipeax/MSI-LED-Tool.
Is there any way to make a new tool like this project?
The tool you’ve linked to still uses the libraries from the gaming app to implement the functionality, so it is not truly “without gaming app”.
So somehow can you use that to manipulate for motherboard on Windows? I tried with ubuntu on windows 10 but not worked of course :( And standart system of MSI for leds is not enough. I purchased 5050 leds and nzxt hue+ set. Hue+ is great but on MSI side not fancy things like that :(
This cannot be used on windows yet. I still haven't seen a standalone ISA bus driver.
On Jul 10, 2017 11:15 AM, "stbatuhan" [email protected] wrote:
So somehow can you use that to manipulate for motherboard on Windows? I tried with ubuntu on windows 10 but not worked of course :( And standart system of MSI for leds is not enough. I purchased 5050 leds and nzxt hue+ set. Hue+ is great but on MSI side not fancy things like that :(
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-314036824, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0hYGqwD96jn8v2eorYrP88ubsCSGks5sMd2ogaJpZM4NMm9F .
Well is there a way to contribute? I'm a programmer also but not interested on hardware programming and drivers on the kernel for now. Also i hate when i get home after work :) Bec all my day passes on the programming. So i spent only almost an hour @last-friday
You could try to write an utility that uses MSI's own drivers, but I would personally avoid them because of them enabling trivial vulnerabilities.
On Jul 10, 2017 11:34 AM, "stbatuhan" [email protected] wrote:
Well is there a way to contribute? I'm a programmer also but not interested on hardware programming and drivers on the kernel for now. Also i hate when i get home after work :) Bec all my day passes on the programming. So i spent only almost an hour @last-Friday https://github.com/last-friday
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-314041228, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0qt9pu4RVo9baB-ZSJPfTT5oIS5aks5sMeIigaJpZM4NMm9F .
Looks like you might be able to build msi-rgb on Windows 10. I am not going down this path, but Windows Subsystem for Linux provides a user-mode Linux kernel.
Instead, I shall continue trying to get RUSTUP to build msi-rgb using the MSVC tool chain.
For this I installed MSVC Build Tools and then RUSTC in Windows 10.
- I have
msi-rgbcompiling on Windows 10, but it complains about the/dev/portsaccess. - Looking for a cross-platform mechanism for accessing hardware registers.
You cannot as WSL does not give access to ISA ports.
On Sep 16, 2017 05:28, "Dominic Cerisano" [email protected] wrote:
Looks like you can run msi-rgb on Windows.
https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
I have not tried it, but this is a full blown user-mode version of Ubuntu from Canonical allowing bash.
Personally I think it is cheating, so I will continue trying to get RUSTUP to compile msi-rgb using the MSVC tool chain.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-329939245, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0jNG2E_o-AhUjpp5pogijzaoDtYkks5sizJdgaJpZM4NMm9F .
Looks like WSL Insider Preview might get ISA port access 'soon' .. it just got serial port access.
On the native tool chain side, have you looked at the x86(amd64) crate I mentioned? The documentation is a little sparse ..
This looks to be the missing piece of the puzzle. There are no crates available for it, but it allows user mode port access in Windows.
I just want to report that I installed the Linux Subsystem for Windows, Ubuntu flavor, and was able to successfully build the project. However, it chokes up with the error:
error: could not open /dev/port; try sudo?
caused by: No such file or directory (os error 2)
I am interested in helping to port this to Windows, but I have hardly worked with hardware development or Windows software development. I've been a JS developer for a few years and am trying to get my foot in the door to building these kinds of apps. If I can be of any help, I will gladly contribute!
The missing piece as pointed by the Dominic seems right. Porting the app should be just changing the program to load the linked driver and use functions provided by it on windows rather than the inb and outb functions called currently.
On Nov 20, 2017 06:03, "Arlo" [email protected] wrote:
I just want to point out that I installed the Linux Subsystem for Windows, Ubuntu flavor, and successfully built the project. However, it chokes up with the error:
error: could not open /dev/port; try sudo? caused by: No such file or directory (os error 2)
I am interested in helping to port this to Windows, but I have hardly worked with hardware development or Windows software development. I've been a JS developer for a few years and am trying to get my foot in the door to building these kinds of apps. If I can be of any help, I will gladly contribute!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-345586210, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0o98c_Zr4m0GyGQkyL7cSSWdRNLnks5s4PotgaJpZM4NMm9F .
Ports are protected in Windows and require signed drivers. The windows port driver I mentioned is signed.
The interface is standard in/outb for ports. But every SIO chip will have different bytecode protocols.
I have since moved onto usb adressable RGBs, which do not require leaping through such fiery hoops, Also they are addressable.
RWeverything is a little more up-to-date and supports both command line and gui. http://rweverything.com I have not installed it, but I suspect it contains the driver mentioned above, since signing authority is hard to come by.
I have 'ported' msi-rgb to Windows. See here.
It's not exactly a port.
For one, it's not written in Rust. I didn't add support for Windows to this project. It was a possibility, and I do find Rust attractive, but 1) Rust is a bit too verbose 2) There are no idiomatic Win32 wrappers and it lacks other little niceties that make C++ far more convenient to get things done quickly 3) I barely have any experience with Rust (that's not to say I didn't try to port it in Rust, I did and I gave up when I realized the amount of verbose code I'd have to write and the amount of time I'd have to spend to write code to make calls to Win32).
For another, while I ported over most of the functions from here, my goal was to do it differently. I.e. reverse engineering Mystic Light to figure out how to do it right, rather than try to guess from trial and error. @nagisa did get it pretty much right - but I couldn't have known.
Also, reverse engineering Mystic Light allowed me to understand a couple of things: Mystic Light-supported MBs use either NCT6797(D), NCT6795(D), NCT5567, or NCT5565. Some have specialized LED controllers, which means they work in a completely different way. Others also work differently though they use these same chips (they're categorized differently in the program). However, IO to all 4 chips works exactly the same. They're always found at 0x4E. Functionality is not chip-dependent, but motherboard-dependent. So there are going to be motherboards not compatible with msi-rgb even though they use an NCT6795(D) chip. Also it seems to me that LED control on these motherboards affects all built-in MB LED hardware (including headers)? It looked to me like it, but I don't have a motherboard to test it to make sure I'm not missing anything.
That is excellent work @ixjf. Did you explore the possibility of using this signed library that can access ports without admin or kernel privileges?
Also does your solution work even from cold boot (power off/on)? Our experience is that MSI GAMINGAPP has to be run first to initialise the SIO rgb header.
You can reset the SIO chip to factory by holding down your PC start button for 10 seconds while it is unplugged.
That is exactly the one I'm using. I just scrapped all the user mode code and wrote my own to avoid a DLL dependency and because I already had code to talk to a driver that was cleaner and simpler (I only needed specific code to load the x64 driver as well). The driver is also embedded in the program and is extracted to the process' current path before loading, and then deleted afterwards on unloading, so it's really all just one 300kb EXE.
I don't think it's possible to load a kernel driver without admin privileges, though.
It is not a kernel driver, it is a signed library. Signing authority allows access to protected memory like IO ports. All you really need to do is replace your port register call with the InpOut32 call. You should be able to statically link it into your executable? The upside is no admin privilege required to run it.
No, it uses a kernel driver. There is a kernel mode and user mode to it: the DLL, which applications load and call functions from, and the kernel mode (the .sys), where the magic happens. It's exactly because of that kernel driver that it needs to be signed. Only signed drivers can be loaded by Windows. Only drivers can access the hardware at that level. You see only a DLL because the .sys file is embedded in the DLL.
Also, no, it doesn't. Coincidentally, I was trying to figure that out just now. I had fully turned off my PC and then turned it back on and I realized the LEDs weren't working. So far, nothing.
Edit: To clarify, it's the kernel driver that is signed, the DLL doesn't need to be.
The point being (is-a and has-a aside) that it allows user level port access.
To re-initialise your rgb header, just launch MSI GAMING APP and set your leds to white (or any colour). Only have to do this once per cold boot (after unplugged).
You might want to use RWEverything to sniff the ports while MSI GAMING APP runs for the first time. This should contain the rgb header init port register sequences, which you could add to your code.
Yes, I know, but I want to figure out why it doesn't work at all now. I followed all the main calls in Mystic Light and I don't seem to be missing anything from there, so there must be something else initializing the chip.
It is obviously something that MSI GAMING APP is doing, strongly suspect it is just a sequence of bytes sent to some bank of port registers on first run. Sniff the ports!
Yes, but I mean there are multiple DLLs. The DLL I've been looking at had all the logic for dealing with the chip, but maybe there's something else. Or I'm just overlooking something important.
Also, no, statically linking won't help. That's not the problem. It's the call to CreateService that fails if the process doesn't have admin rights. It doesn't matter how the code is loaded.
The DLLs don't matter - the port registry bytes are what initialise the SIO. It does not matter which DLL sends them, just the order they are sent. The init codes should be the first ones sent to the RGB bank on cold start.
You would have to first uninstall MSI apps, cold boot, run RWEverything and then reinstall and run the MSI apps. Instead of RWEverything you might get away with just tracing the DLLs after uninstall, cold boot, reinstall. I would guess the MSI DLLs only send the init codes once ever per cold boot (possibly why you have not seen them yet).
You should be able to create a service with user privilege (it seems - not that familiar with WIN10 service security model).
But why don't you just install it as a persistent System Tray app? Do you need the service model for something?
The DLLs DO matter, because that's where I get the information from. I'm reverse engineering them, not doing trial and error with RWeverything.
Also, no, you can't. Especially not a kernel driver. You need sudo on Linux too, don't you?
No DLLs don't matter - only the init codes to the SIO. You should be able to get them from tracing the MSI DLLs from cold boot (or RWEverything). I would use both at the same time.
On Linux yes, only root or groups like dailout can access serial ports. I just set the sticky bit on the msi-rgb binary (sudo chmod u+s msi-rgb). Ownership and group must be set to root.
Are you saying only admin can install a signed driver? That would make sense. Obviously I have not gone done this road on WIN10. Port access requires superuser to install on both WIN and LINUX, but should only require user-level access to run an msi-rgb-enabled app.
In fact I gave up on msi-rgb and found that building my own rgb chips out of $1.00 ATTiny chips allowed HID-USB access rather than SIO access (which does not require superuser access or even mobo rgb). Now I have nearly unlimited (matrix and strip size only limited by power supply) 60fps addressable rgb lighting everywhere (mobo agnostic - as long as there is a usb port).
I have argued with @nagisa that the only function of msi-rgb should be to disable mobo rgb. That way it wont interfere with custom case lighting solutions like mine.
I think you don't understand what I'm saying. I'm NOT doing trial and error with RWeverything. That can tell me what is happening, but not how and why. I'm reverse engineering Mystic Light - disassembling the code and seeing what it does.
Also, no. Signing is not what allows user level access to hardware. Signing provides a way for both Windows and the user to know that some executable comes from the author it says it does. That's about it. It's like a real life signature. It doesn't even have anything to do with drivers. You can sign any executable. In order to access the hardware, you need to run in kernel space. Hence, you need a kernel driver. The reason Windows only allows signed kernel drivers is because those drivers can do pretty much anything, especially without being detected, so it's best only those from reliable sources be installed. Moreover, it's not the InpOut32 DLL that is signed - it's the kernel driver that the DLL loads.
And yes, only an administrator can install a driver. The reason you don't see Mystic Light asking for permissions every time you run it is because when you installed Mystic Light, or the Gaming App, the setup asked you for them. When it installed the program, it installed the services (including the driver service) as well and allowed anyone to run it afterwards. If you look at LEDKeeper.exe in Mystic Light's directory, you'll see a small blue and yellow icon on the side that shows that the executable requires admin rights.