cross-posted from: https://lemmy.world/post/42787520
Most of us have some blinking, light-emitting, colorful devices attached to our potatoes - or whatever the minimum specs for Linux are these days, haven’t checked in a while.
And most of us use OpenRGB to control them. But I fear this single project has some major, fundamental issues. As with many projects, it grew very fast and very big.
It has over 200 supported devices today, and the list keeps growing.
But it wasn’t designed to grow this fast or support such a variety of devices.
This has led to several issues:
Not all features can be implemented for all devices:
For example, devices with different available effects per zone aren’t supported by design. You may have noticed that sidebar LEDs on some keyboards aren’t controllable via OpenRGB.
No support for macros, DPI settings, and more:
It was always about RGB. This isn’t an issue per se - it’s the scope of the software. But:
Cannot coexist with macro/mouse controlling software:
OpenRGB needs to open the HIDRAW device to control it, and this is an exclusive operation. So no other software can hook those devices at the same time.
Growing backlog:
Device-support requests keep piling up, new devices wait a long time to be accepted - the usual open-source maintenance challenges.
My Idea
Let’s create a unified device abstraction library. The core part should just offer a C++ library with all the device abstraction logic in it. This library can then be consumed by a variety of software:
- OpenRGB could use the RGB part of it, focusing on orchestration and advanced features
- Python bindings for scripting your setup
- Hyprland integrations
- Custom CLI tools
- Whatever the community builds
Therefore, if you’re a developer who knows your way around modern C++ features (or wants to learn), here’s my project pitch:
What this could be:
- Modernized device code (C++23, memory safety, proper abstractions)
- Support for ALL peripheral features (RGB, macros, DPI, profiles, etc.)
- Clean API for other developers to build on
- Reduced fragmentation - community maintains ONE device library instead of competing implementations
Making this real would need:
- C++ developers , as one developer is no developer (and i have other hobbies!)
- People who’ve worked with USB/HID protocols on Windows and other Non-Linux platforms!
- Anyone frustrated with current Linux peripheral tools and willing to help fix it
- Design feedback and testing
To kickstart this:
We can fork OpenRGB’s existing device implementations (GPL-licensed) as a foundation. I have at least two devices here that offer on-device macro functionality, key remapping, and more, so I can create the basic abstractions for those features.
Thoughts?
This will not be a fork of OpenRGB. While I plan to take a huge chunk of it (the reversed generiert device protocols) the library itself, is all written from scratch.
And, as mentioned, OpenRGB has issues. Besides the listed, technical, issues it has also design and maintenance issues:
While OpenRGB heavily depends on Qt, and is written in C++, ur is full of plain C constructs. This is intentional, have a look at the README.md. raw pointer juggling, lifetime issues (therefore, segfaults) and most importantly:
Making it a dependency would not aolfe any of the feature issues. A device, provided by OpenRGB, still has no support for macros, OpenRGB does all the device communication, so no way to add it.
How about opening an issue on OpenRGB asking what you need and why, maybe it can be abstracted away, headless, and that architecture change could be useful for them and other projects too then?
You can do that part yourself and let other use that new tool as their dependency but it means you’ll have to keep it up to date against OpenRGB itself as it supports more devices just because of its popularity.
Other stuffis not part of OpenRGB and never will be. Maybe you should have a loook at the project yourself, mainly read the contribution document.
What is your issue? Avoiding fragmentation? Yeah me to.
Currently,I do want to control my mouse, I need a different software that collides work OpenRGB.
This is not fixable by trying to force stuff into OpenRGB the maintainer clearly does not want (he said so).
After we have a working lib, with at least feature parity, I will try to convince the current maintainer of OpenRGB to outsource the device handling, and focus on the features he wants to build.
EDIT and I don’t want to compete with OpenRGB, I want to focus the currently fragmented world of Linux peripheral development in a singular place, so every tool can use it. Ad a library, not a GUI application that just is another project that will die because it gets unmaintanable.
So, please, have a good look at the contribution documentation and the bug tracker. Look for yourself, or try to introduce macro support or other stuff into this project. I have done so in the past.
And to be clear: If the author and maintainer says he don’t want to have this feature, I completely understand.