Replies: 5 comments 8 replies
-
Reasons why a daemon is necessary at all:
|
Beta Was this translation helpful? Give feedback.
-
So, how a D-Bus interface could look like?
Possible interfaces:
Actually, the D-Bus tree is very similar to what liquidctl CLI currently outputs. |
Beta Was this translation helpful? Give feedback.
-
Another major advantage of a daemon is that it would allow us to have synchronized access to the devices, avoiding issues like #274 ("Running two liquidctl processes causes Corsair H100i PRO XT to stop responding to read requests."). This is to say: some sort of daemon has been on my mind for a possible liquidctl version 2, but I had incorrectly discarded D-Bus because I didn't know that it was available on Windows. One issue still remains (besides the huge refactor): in order for the daemon to synchronize access between multiple users (root + one non-root is a fairly common scenario), it would probably need to run with elevated privileges. On a Linux distro that's not a major problem (we can supply a service configuration), but the peer-to-peer mode on Windows worries me. And how do these D-Bus implementations work on Mac? |
Beta Was this translation helpful? Give feedback.
-
Re. D-Bus, I'm acknowledge your points even though I think I didn't make myself super clear in a couple of places. But I'll let the idea mature a bit more and only bring up any remaining issues/concerns if they are really necessary.
Hidapi not being thread-safe on Windows (or other platforms) is news to me. Sure, I don't expect that any given That said, I agree that dropping hidapi could be beneficial on some platforms. (Probably all except Mac OS, where anytime I've had to follow or debug hidapi issues it turned out to be kernel-level quirks, undocumented behavior...) |
Beta Was this translation helpful? Give feedback.
-
@jonasmalacofilho Related: I've accidentally found a pure-Python hidapi replacement - https://github.com/google/pyu2f/tree/master/pyu2f/hid The only issue is that they throw away report numbers (should be easy to fix). |
Beta Was this translation helpful? Give feedback.
-
IMO a software that controls fans/pumps/RGBs should be a D-Bus daemon, just like upower, udisks, libratbag, etc. This way you can provide a rich object oriented API (with standardized things like property change notifications and caching), that can be accessed from multiple languages/toolkits: GLib/Gio (Gtk), Qt, simpler/smaller libraries like jeepney (Python) or dbus-rs (Rust).
Yes, you can actually use D-Bus on Windows, and it doesn't require a dedicated bus daemon to run, it can work in peer-to-peer mode (i. e. your daemon is the server).
Beta Was this translation helpful? Give feedback.
All reactions