RGB Control through a VM

B

borisko

Member
Jun 25, 2019
21
0
21
37
Hi guys. I know it's a stupid topic, and has nothing to do in a server forum, but here I am with my shiny lit beast, spatting rainbows...

I installed Windows through a virtual machine (Proxmox / KVM) and was wondering if there is anything particular I should pass through or install to be able to control most RGB features through the provided software inside the VM itself, or eventually if I should try to control it through the command line directly.

Below are some specs relevant to the rgb things in my box, as well as the software I am planning to use.
- Gigabyte Z390 Aorus Master (with i9-9900K if that's any relevant)
- H100i liquid cooler (fans themselves are connected to Corsair's Lightning node pro) hooked on a usb 2.0 header on Motherboard.
- Led strips (and RGB SSD daisy-chained to it) hooked to one of the RGB LED headers on the mobo.
- 64GB of G-Skill Trident Z memory.

I was planning on using RGB Fusion (Gigabyte's own software) to control the mobo lights and the strip, as well as eventually the RAM (although I heard that software aint playing nice and I'm better off with Gskill own software) but so far, I'm out of luck, probably because nothing is recognized properly. The RGB Fusion software even froze my vm once and I couldn't change anything on it (sadly no BIOS/UEFI control for RGB Fusion on that board).
Unsure how I can eventually identify (if that's even possible) the RGB LED header on the mobo to passthrough directly to the windows machine to recognize and tinker with?

Same question for RAM, although I realize now that I'm writing this that if I don't assign all of the RAM to the vm, I'll probably be out of luck too?

I'm clearly out of my depth.

Thanks in advance for any help!
 
normally the rgb headers/leds/etc are controlled via i2c directly on the board

while there are the various i2c devices in /dev/i2c-X etc. there is normally little to no documentation about which
are the correct ones and how the software identifies them

there is an sdk though for it (https://www.gigabyte.com/mb/rgb/sdk ) maybe this includes some documentation/way to control it on the host directly...
 
Thanks a lot for your answer Dominik. I tried taking a look at the SDK, but it didn't seem to show much documentation apart from usage to build around it, also it seems it is solely Visual Studio based and requires several windows-based dependencies to work (and I am frankly not smart enough to identify anything useful I am afraid)... Seems like I am stuck.

I tried the stupid way, passing through the entire SMBus to that VM, and even that did nothing more than messing up with my access to the node and ethernet connection.

Could I have been on the right path though? I mean the SMBus is the only pci device that I identified with lspci that showed me is using a i2c kernel module, the only that I could pass through in my GUI anyway. How would you go about identifying "safely" (or passing something through)? I don't mind trial and error as long as I don't damage the node itself, my VM is just a test one anyway.

Sorry if all those are noob questions too.
 
borisko said:
Could I have been on the right path though? I mean the SMBus is the only pci device that I identified with lspci that showed me is using a i2c kernel module, the only that I could pass through in my GUI anyway. How would you go about identifying "safely" (or passing something through)? I don't mind trial and error as long as I don't damage the node itself, my VM is just a test one anyway.
Click to expand...
honestly i am not sure this will work at all..
say you can pass through the smbus device (which i am not sure of, and most likely it will not be in a separate iommu group), then i guess the guest will still not correctly identify the ports etc....
 
dcsapak said:
honestly i am not sure this will work at all..
say you can pass through the smbus device (which i am not sure of, and most likely it will not be in a separate iommu group), then i guess the guest will still not correctly identify the ports etc....
Click to expand...

Yeah I kinda had a brain fart there, forgetting that the whole principle of qemu is to emulate the motherboard itself and virtualize it... :-D Which would obviously be my main bottleneck.

I went through a crazy workaround and managed to get somewhere by installing Windows on a USB stick, boot from it (after unplugging all my SDDs, probably overkill but I am paranoid with Windows messing up with Grub and such, from previous read-outs of linux community) and kinda managed to force the motherboard into saving my light configuration for the LED strip and the onboard lights after multiple reboots. No idea how it did work but it seems to save if I choose static lights, save multiple times and don't loose power, despite not having control over rgb in BIOS, so that's a big win for now!

Still no luck retaining configuration for the RAM though, maybe it's hit and miss like the LEDs and could work if I give access to most of my RAM to the VM, but I doubt it. Will tinker further and report. Thanks a lot for your answer though Dominik !
 
borisko said:
Yeah I kinda had a brain fart there, forgetting that the whole principle of qemu is to emulate the motherboard itself and virtualize it... :-D Which would obviously be my main bottleneck.

I went through a crazy workaround and managed to get somewhere by installing Windows on a USB stick, boot from it (after unplugging all my SDDs, probably overkill but I am paranoid with Windows messing up with Grub and such, from previous read-outs of linux community) and kinda managed to force the motherboard into saving my light configuration for the LED strip and the onboard lights after multiple reboots. No idea how it did work but it seems to save if I choose static lights, save multiple times and don't loose power, despite not having control over rgb in BIOS, so that's a big win for now!

Still no luck retaining configuration for the RAM though, maybe it's hit and miss like the LEDs and could work if I give access to most of my RAM to the VM, but I doubt it. Will tinker further and report. Thanks a lot for your answer though Dominik !
Click to expand...


Did you ever have any luck with this? I'm stuck in a similar situation.
 
How does one go about using OpenRGB inside an LXC container? I have some Corsair RAM and RGB that I would like to control so a VM passthrough wont cut it. Thanks.
 
i tried the same like you. Using the openrgb as a led controller on the host.
i compiled openrgb 0.9. Its a Proxmox on top of debian 12 at my gaming workstation with
a 8 core AMD 5700g and a Aorus B550 pro-p Motherboard.
First i have passed my RTX2060 to the vm and my 500gig Lenovo NVMe for the guest and all
other devices like Soundblaster X4, Keyboard, Mouse through USB Passthrough.

If i'm starting the VM first, The OpenRGB runs normal but crashes sometimes.
The VM doesn't start if the openrgb is started first.

i've tried to passthrough all USB Devices through PCI Device directly. But it did not change the strange behaviour.

What can i do with this? I saw, that some Peoples in the forum are suggesting the way to go with openrgb not the way
to passthrough the USB devices of the Corsair Commander Pro directly.

I musst say. I have multiple lightning devices.
- Commander Pro
- Commander Node
- H100i
- Corsair Vengeance RGB

i don't know how to proceed at this point.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back