Arch Linux User Repository

I'm strapped for time these days. My main rig is down in storage buried by boxes. I won't have time or a way to test updates to this PKGBUILD. If a major change comes along, I'll be relying on you lot to test the package. In a few months, I should have my affairs in order. Until then, post any proposed changes to the PKGBUILD or other files with detailed explanations of the effects. I'll do my best but don't expect me to have as much time as I once did. Don't forget to report problems with the udev rules upstream, where it is now maintained.

Can the out-of-date flag be cleared, if it is not too much of a bother? AUR helpers complain about this during installation and it's quite annoying. The flagger probably misunderstood the mechanics of -git packages.

you actually have to load it, it's not loaded automatically. So you still have to run sudo modprobe i2c_piix4

I actually checked that before commenting. For me, i2c_piix4 and i2c_dev are loaded automatically.

But i also found the problem.

Without i2c-piix4-aura-dkms, the permissions of the relevant /dev/i2c-* devices are 600 and root:root. If you change that to 660 and root:wheel, it does work like expected.

i2c-piix4-aura-dkms actually has a udev-rule for this reason. It’s only one line:

KERNEL=="i2c-*", ATTR{name}=="SMBus*" SUBSYSTEM=="i2c-dev" MODE="0660", GROUP="wheel"

@zoidby also what exact motherboard do you have? It's important.

@zoidby I can actually confirm this.

The thing is, at first I thought you were making a simple mistake. See, there's now an i2c_piix4 kernel module included in the kernel, yes. BUT, you actually have to load it, it's not loaded automatically. So you still have to run sudo modprobe i2c_piix4. I was about to come tell you that, but I decided to check for myself. I have a second install where i2c-piix4-aura-dkms isn't installed. I booted into it, checked, and sure enough, my RAM sticks were detected but NOT my motherboard.

So I installed i2c-piix4-aura-dkms (it's in chaotic-aur) and rebooted. Sure enough, it was absolutely what fixed it. Detected the mobo straight away. Definitely still an issue.

I now have 5.8.3-arch1-1, but openrgb still doesn’t detect any devices without i2c-piix4-aura-dkms installed.

I am lucky to still have the source since the package was removed from the AUR. Otherwise i wouldn’t be able to control my RGB anymore.

Why does the check function execute mkdir -p $HOME/.config/OpenRGB? Is it because you do cd ~/.config/OpenRGB && openrgb on the desktop file?

Because there's no guarantee that the package is installed in the same computer or by the same user who built it, and it might not even be executed at all, depending on your makepkg.conf.

I'd remove the check function and replace the command in the desktop file with this: [[ ! -d ~/.config/OpenRGB ]] && mkdir -p ~/.config/OpenRGB; cd ~/.config/OpenRGB && openrgb

(And to comply with the XDG spec, ${XDG_CONFIG_HOME:-$HOME/.config} is preferred instead of ~/.config, but I'm not sure how well it works in a desktop file)

gardotd426, here is the bug report from Adam Honse, the developer of openrgb.

Notice the above bug report doesn't cover intel motherboards which will still require a patch for the nuvoton chip used.

I'll change the exec line to Exec=bash -c 'cd ~/.config/OpenRGB && openrgb' considering the issue with compatibility; as for why I change the directory, openrgb doesn't adhere to freedesktop's XDG Base Directory Specification meaning that by default it will clutter your home directory with config profiles. I did this as a stopgap measure until it is implemented upstream (similar to the udev rules that I tried to maintain). See here for the bug report.

@Myrddin, where did you see that i2c-piix4-aura-dkms was upstreamed?

Also, I have a humble suggestion about the included .desktop file. Change Exec=bash -c 'cd $HOME/.config/OpenRGB && openrgb' to Exec=bash -c 'cd ~/.config/OpenRGB && openrgb'.

Some desktop environments refuse to launch your version, such as Deepin (I guess because they have trouble getting the $HOME variable for some reason) and therefore WILL NOT launch OpenRGB (you have to launch it from the terminal). But using the tilde (~) is effectively the exact same thing (cd ~ and cd $HOME do the same thing) and it actually works on these desktop environments. Alternatively, just remove the cd part and just exec openrgb. The same config is loaded regardless, I just tested by launching from the terminal in a completely different directory, and my saved profiles were still present. So definitely either change the $HOME to a ~ or just remove that part and have it be Exec=openrgb

This is the output of uname -a

Linux arch 5.7.7-arch1-1 #1 SMP PREEMPT Wed, 01 Jul 2020 14:53:16 +0000 x86_64 GNU/Linux

If i don’t install i2c-piix4-aura-dkms, no hardware shows up at all. Not the board, not the ram.

Like i said, the issue with 99-openrgb.rules is fixed. The remaining problem is that i2c-piix4-aura-dkms has to be installed. And i am not even sure if that is a problem or related to this package.