Package Details: openrgb-git 0.9.1162.g23dbaba-1

Git Clone URL: https://aur.archlinux.org/openrgb-git.git (read-only, click to copy)
Package Base: openrgb-git
Description: Configuration utility for RGB lights supporting motherboards, RAM, & peripherals
Upstream URL: https://gitlab.com/CalcProgrammer1/OpenRGB
Keywords: led
Licenses: GPL-2.0-only
Conflicts: openrgb
Provides: openrgb
Submitter: Myrddin
Maintainer: CalcProgrammer1
Last Packager: CalcProgrammer1
Votes: 35
Popularity: 0.69
First Submitted: 2020-02-14 03:47 (UTC)
Last Updated: 2025-01-21 00:20 (UTC)

Dependencies (6)

Required by (15)

Sources (3)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 Next › Last »

axelgenus commented on 2020-06-21 08:08 (UTC) (edited on 2020-06-21 08:10 (UTC) by axelgenus)

Udev rules should be patched for OpenRGB to read/write to I2C devices (i.e. Aura DRAM's). Group 'i2c' does not exists in ArchLinux, there is no 'uaccess' for those devices and there should NOT be: I2C devices should only be accessible to a high-level users group for security reasons.

IMHO you could remove 'plugdev' assignments altogether (since we have 'uaccess' there), replace 'i2c' group with 'wheel' and chmod 660 the devices. This is how I fixed it on my workstation:

$ cat /etc/udev/rules.d/custom-i2c.rules

KERNEL=="i2c-[0-99]*", GROUP="wheel", MODE="0660"

Myrddin commented on 2020-06-20 21:53 (UTC) (edited on 2020-06-25 17:12 (UTC) by Myrddin)

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).

CyrIng commented on 2020-06-20 02:26 (UTC) (edited on 2020-06-20 17:25 (UTC) by CyrIng)

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

streblo commented on 2020-05-28 15:46 (UTC)

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

ugur commented on 2020-05-26 11:33 (UTC) (edited on 2020-05-26 11:34 (UTC) by ugur)

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"

slip commented on 2020-05-25 21:44 (UTC)

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.

Myrddin commented on 2020-05-25 15:21 (UTC) (edited on 2020-06-25 17:13 (UTC) by Myrddin)

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.

slip commented on 2020-05-25 00:12 (UTC) (edited on 2020-05-25 01:14 (UTC) by slip)

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

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 Next › Last »