Package Details: openrgb-git 0.9.1233.g1809c75-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: 34
Popularity: 0.008139
First Submitted: 2020-02-14 03:47 (UTC)
Last Updated: 2025-02-16 20:54 (UTC)

Dependencies (6)

Required by (15)

Sources (3)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9

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

rjahanbakhshi commented on 2020-05-06 09:27 (UTC) (edited on 2020-05-06 09:28 (UTC) by rjahanbakhshi)

For NZXT Kraken in 99-openrgb.rules:

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

Thanks,

fsyy commented on 2020-05-01 20:47 (UTC)

Hi,

i added another line to the udev rules.

Asus Aura Addressable RGB Header

SUBSYSTEM=="usb", ATTR{idVendor}=="0b05", ATTR{idProduct}=="18a3", MODE="0666", TAG+="uaccess"

to access the rgb headers on my Z390-F Asus mainboard, would be nice if you could add that too :)

cobaltspace commented on 2020-04-13 06:19 (UTC)

What purpose does doing the qmake in it's own folder instead of how upstream says to?

« First ‹ Previous 1 .. 4 5 6 7 8 9