This monumental release encompasses nearly 3 years of work since the 0.9 release, and a year's worth of core reworks since the 1.0rc2 release candidate last year. Tons of new device support, an overhauled profile system, the option to cleanly run as a background service, PawnIO, Qt6, and much more!

Downloads for OpenRGB 1.0 are live on https://openrgb.org/, plugin 1.0 builds will be coming online soon.

Tentative OpenRGB 1.0 release date is over Labor Day weekend, probably either Friday Sep. 4 or Saturday Sep. 5 so that I have some time after the release to make some 1.0 related content (social posts and YouTube videos) over the long weekend.

I think we are in a pretty good state now, just want some remaining device support to get merged and a window for developers to submit final cleanups to controllers.

Not guaranteeing anything though, it could slip.

Support for the #Valve #SteamMachine under #Linux has been merged into #OpenRGB. This relies on the leds-valve kernel module that is included in the SteamOS kernel. A DKMS package is available to install this kernel module on #Arch and #Debian distros:

https://gitlab.com/CalcProgrammer1/leds-valve-dkms

or AUR leds-valve-dkms-git

A follow up to my earlier post about the leds-valve DKMS module, now it is usable within the latest experimental build of OpenRGB itself as long as that leds-valve module is loaded.

Support for the #Valve #SteamMachine under #Linux has been merged into #OpenRGB. This relies on the leds-valve kernel module that is included in the SteamOS kernel. A DKMS package is available to install this kernel module on #Arch and #Debian distros:

https://gitlab.com/CalcProgrammer1/leds-valve-dkms

or AUR leds-valve-dkms-git

I made a DKMS package for Valve's leds-valve driver, the Linux kernel driver that drives the LED strip in the Steam Machine. I also made an AUR package leds-valve-dkms-git. The GitLab repo has a Debian build in the build artifacts though I haven't tested it, but it works on Arch.

I am working on a controller in OpenRGB to use this driver, it still needs some cleanup but I have it working. There is a lot of room for optimization as the interface leds-valve exposes only allows writing one LED at a time but refreshes the whole strip for every change. I'd like to add an additional path to send the whole strip at once go get better update rates but this will require a change to the leds-valve driver directly.

OpenRGB Release Candidate 1.0rc3 has been released! This new release candidate build should be considered the latest stable build and is recommended for end users. It doesn't contain the next branch changes yet, but there are some major stability improvements as well as a lot of new device updates and some UI cleanups in this build. Distro maintainers, please update 1.0rc2 packages to 1.0rc3, keep using qt5 for now.

Builds are available on Codeberg:

https://codeberg.org/OpenRGB/OpenRGB/releases/tag/release_candidate_1.0rc3

Links are also updated on https://openrgb.org/

The Flatpak release will be updated soon.

https://floss.social/@OpenRGB/116830393836395905

The PCBs I designed for my smart ARGB splitter came. I had them manufactured by OSHPark and they turned out great. I assembled one, flashed it, and was able to drive 6 independently controlled outputs from a single ARGB input from my Airgoo controller.

ARGB splitters and hubs suck. They actively take the "addressable" out of ARGB by sending the same signal to all downstream LED components. While dedicated USB ARGB controllers like the Nollie and Airgoo have come out with 16+ ports to alleviate the need for splitters, some times a splitter is more convenient. I just updated my PC and my new Thermaltake CPU cooler has 4 separate ARGB components (an LED strip on each tower as well as 2 ARGB fans) all tied together with splitters so it all gets addressed as one uneven blob. A discussion on the OpenRGB Discord made me want to revisit the idea of a smart splitter, something I previously failed to make using an ATTiny as well as discrete logic. However, this time I tried using a RP2040 and its high speed programmable PIO architecture and succeeded! This project is the result. One ARGB signal goes in to GPIO0, and it gets divided up into channels based on the number of LEDs configured for each channel on GPIOs 2, 3, 4, and 5. It could be expanded for more GPIOs pretty easily as well. It acts on the signal in real time with no buffering, so theoretically you could chain them together without penalty or latency.

https://www.thingiverse.com/thing:7310885

https://gitlab.com/CalcProgrammer1/OpenRGBDeskFan

I've created a new version of my OpenRGB Desk Fan project! This is a 3D printed stand and Arduino Pro Micro based controller to turn any ARGB 120mm or 140mm PC fan into a colorful desk fan that syncs with your OpenRGB setup. The software is based on CorsairLightingProtocol. I originally designed it in 2024 but now have updated the 3D models to provide 140mm support and clean up the base.

I haven't abandoned OpenRGB. It might seem that way given the last "stable" release was in 2023, but rest assured 1.0 is on the horizon still. I originally intended to release 1.0 last year shortly after 1.0rc1, but external setbacks pushed it back, namely WinRing0 being taken down by Windows Defender and Qt5 reaching EOL. However, after putting out those fires I decided I was not happy releasing 1.0 in its current state. Several other developers had open concerns about the backend and about rough edges in the user experience, and more issues came to light after 1.0rc2 in September.

Moving to a client/service architecture on Windows was desired to get around PawnIO's need to run as admin, but significant parts of the user interface (settings and profiles mainly) were not made to work with the SDK server.

This led to the creation of the next branch, a separate branch where I have been doing some major user-facing as well as backend changes. Notable big changes are below.

• Update to Plugin API v5 and SDK Protocol v6
• New profile system that properly integrates plugin settings into OpenRGB profiles
• Settings and profile sync with background service
• USB HID device hotplugging
• Dynamic list updates
• Per-Zone Modes
• Lots of potential crashes mitigated by backend cleanups, protocol improvements, and better definition of plugin interfaces

For more detail, see this merge request:

https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/2935

You can also download pipeline builds there to test, and -next-git AUR packages are available for testing as well on Arch based distros.

I've been wanting to migrate away from lemmy.ml for a while and have been using my lemmy.today account as my main Lemmy presence for a while now. This instance has been stable enough that I feel comfortable migrating here. The old Reddit style mlmym interface is available at https://old.lemmy.today/c/OpenRGB.