Arch Linux User Repository

Thanks for the dependency tip, Cyring; I've added them to the PKGBUILD. I disagree with your second part regarding the rules file.

The rules file doesn't need editing to work; you don't need to be added to the storage group. Any errors in your log are harmless regarding the plugdev group because TAG+="uaccess" handles permissions on recent versions of systemd/udev. The plugdev group is for Debian et al. & is ignored on archlinux with systemd.

Additionally, i2c-dev should be loaded on boot by installing this package & i2c-piix4 is loaded by default on my system (& presumably others' systems).

Using a fresh Arch setup, you may additionally need:

pkgconf
i2c-tools
ldconfig

As mentioned in other comments, a service to care about:

modprobe i2c-dev
# find and replace group plugdev with storage in 99-openrgb.rules
# then add user account to storage
cp -v openrgb-git/src/openrgb/99-openrgb.rules /etc/udev/rules.d/
udevadm control --reload-rules
udevadm trigger

Might be nice to add in a .service for loading a default profile on boot.

Hi Myrddin,

I have a Corsair K70 RGB LUX keyboard which have different product ID than K70 RGB keyboard. Could you please add below udev rule to 99-openrgb.rules file.

# Corsair k70 RGB LUX
SUBSYSTEM=="usb", ATTR{idVendor}=="1b1c", ATTR{idProduct}=="1b33", MODE="0666", TAG+="uaccess"

Okay, thanks. I checked the link with the fix and it appears that it wasn't merged, which makes sense because currently, it's still conflicting as the package stands. Additionally, commenting out the udev rules doesn't work either. The conversation I had with the developer stated that the way to do it was to remove it from the build process. Since you can't test it and see, I'll leave it at that and sort it myself. Thanks.

I cannot test this, but supposedly your issue with conflicts on fan control software has now been resolved, 10479. Edit: I was incorrect, the NZXT controller has been refactored to use hidapi which will support hidraw eventually.

Additionally, fan control is planned for OpenRGB; but you're likely going to be waiting a few months for that to pan out. See here.

I should start an Archwiki page for RGB software. There does seem to be enough options out there for a proper page on configuration, troubleshooting, etc.

I have a proposal for this package that I figured I'd run by you. To preface this, I'm not an expert in this area and this might be a very stupid question.

The NZXT controller conflicts with at least 1 other controller software (Gkraken) for pump and fan speed to control cooling. While the hardware continues to work, the ability to change cooling profiles is prevented. I assume this is because they both try to control it through the same USB interface. Gkraken doesn't have LED control and OpenRGB doesn't have fan/pump control and they are both the best at what they are intended to do in my opinion. Personally, I would much rather lose lighting control over cooling control.

A simple sed -i '/NZXT/s/.*//' OpenRGB.cpp in the build process removes any calls to NZXT controllers and builds without NZXT support leaving other software to do that. Is it feasible and/or reasonable to create a warning about the possible loss of hardware control and a Y/n option if the user wants to build with or without NZXT control? Or do you think a separate package should be created, which ultimately would be identical to yours but with the one line added into the PKGBUILD?

Thanks

For NZXT Kraken in 99-openrgb.rules:

# NZXT Kraken
SUBSYSTEM=="usb", ATTR{idVendor}=="1e71", ATTR{idProduct}=="170e", MODE="0666", TAG+="uaccess"

Thanks,