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.

I do not see any issues with the daemon running as root/admin. Unless you're allowing arbitrary code execution through the D-Bus API, you're fine. In Python, it's hard to do accidentally. Even in C, if you're using a mature high-level D-Bus library (like Gio), this is very unlikely (and would mean that there's a vulnerability in the library).

And how do these D-Bus implementations work on Mac?

macOS supports Unix domain sockets for a long time, so there are even fewer differences with Linux. I would use peer-to-peer mode on both Windows and macOS.

Also, note that on Windows and macOS, you will be shipping your own builds of the libraries - so nobody prevents you from patching them in whatever way you like.

Gio allows creating GDBusConnection from arbitrary GIOStream: https://developer.gnome.org/gio/stable/GDBusConnection.html#g-dbus-connection-new
So it can work even over named pipe, I think ("default" D-Bus transport on Windows is TCP over loopback interface).

Pure-Python Jeepney can work over any channel that supports read/write too.

I do not see any issues with the daemon running as root/admin.

My main concern is that packaging and distributing something that requires a daemon to be running independently of the current session (in the end, root is not technically necessary) is going to be painful on anything but Linux.

And while I spend 95% of my time on Linux, I still care that liquidctl be cross-platform, and easy to setup on all of those platforms.

I would use peer-to-peer mode on both Windows and macOS.

I thought so.

What would be the easier way to establish something like the system D-Bus (i.e. a bus that is not dependent of any particular session) using peer-to-peer D-Bus on Windows/Mac?

Also, note that on Windows and macOS, you will be shipping your own builds of the libraries - so nobody prevents you from patching them in whatever way you like.

But we still want to support Linux, so we can't depend on the arbitrary hacks for those two other platforms, meaning some duplication of efforts on our side. And maintaining patches to a D-Bus library seems like the type of thing that's one order of magnitude more work than maintaining liquidctl itself.

Unless you're allowing arbitrary code execution through the D-Bus API, you're fine. In Python, it's hard to do accidentally.

Since this would require a full rewrite (not only for the daemon itself, but also because this server-based architecture screams for a new driver model that would make it easier to write clients, especially generic ones like GUIs), I would probably do it in Rust, rather than Python.

I still think that Python was the right choice for liquidctl v1.0, but now the lack of a strong/powerful static type system is a significant maintenance cost.

My main concern is that packaging and distributing something that requires a daemon to be running independently of the current session (in the end, root is not technically necessary) is going to be painful on anything but Linux.

It shouldn't be an issue. On Windows, there is a standardized way to install services (including system-wide services). I don't know about macOS, but I'm sure someone else already solved the problem (and probably even put an open-source solution on GitHub).

What would be the easier way to establish something like the system D-Bus (i.e. a bus that is not dependent of any particular session) using peer-to-peer D-Bus on Windows/Mac?

Peer-to-peer mode means clients connect directly to the daemon — a Unix domain socket on macOS and a TCP socket on Windows (on loopback interface). Or, if D-Bus implementation is good enough, over a named pipe. For Unix socket and named pipe, a well-known location/name should be enough.

But we still want to support Linux, so we can't depend on the arbitrary hacks for those two other platforms

For Linux, no hacks are necessary, because the daemon is connected to the system bus. All libraries support it. Hacks might only be necessary on Windows/macOS if a library doesn't support peer-to-peer mode (at least Gio and the reference implementation do), or to add named pipe support (not strictly necessary).

Since this would require a full rewrite (not only for the daemon itself, but also because this server-based architecture screams for a new driver model that would make it easier to write clients, especially generic ones like GUIs), I would probably do it in Rust, rather than Python.

So far, everything in Rust is "in development"/incomplete. You'll probably be working on external libraries more than on liquidctl itself (diwic/dbus-rs#320).

If you want some kind of static typing, maybe mypy could help?

Otherwise, I'd actually recommend C+GLib.

1. Mature D-Bus implementation (probably the most widely used = most tested one). With a code generator.
2. libusb and udev wrappers with integration into GLib event loop.
3. Similar daemons (upower, libratbag) are written using this stack.
4. Can copy/paste C code between the daemon and Linux kernel drivers (and OpenCorsairLink).

Actually, you could mix C and Python using GObject Introspection... But Python GObject bindings have their own bugs.

Also, there are Rust bindings for GObject libs... But I am not sure if daemon-side GDBus is currently usable (from Rust).

Another interesting thing is getting rid of hidapi, because hidapi is not thread-safe (at least on Windows), and has no async API.
With glib: https://github.com/amezin/nzxt-grid-v3-glib (Windows and Linux, macOS is a bit different but doable too)
With asyncio, on Linux async read from hidraw will work out of the box, and on Windows you could interact with devices using IocpProactor. macOS is, again, special, but asyncio event loop integration will probably be easier than GLib.

Sure, I don't expect that any given hid_device can be shared between multiples threads

Independent read and write are what I would want for grid/smart device drivers. Either an async API is needed, or thread-safety on this level (I would prefer an async API, of course).

It seems that on Windows, hidapi improved a bit: libusb/hidapi@f7c7f97. After this change, it should be possible to read in one thread and write in another (if I didn't miss anything), except missing synchronization in register_error.

I still don't like spawning threads (and then debugging synchronization issues) just because of API limitations.

But coming up with a proper event loop abstraction for hidapi won't be easy.

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...

Could you provide a few links? Maybe that will stop me from trying to reinvent hidapi :)

libusb/hidapi#202

Could you provide a few links? Maybe that will stop me from trying to reinvent hidapi :)

It's been a while. The only thing that comes to mind is trezor/cython-hidapi#116, but that's not really representative of what I meant, even though it may still qualify as "interesting": being able to trigger a Mac OS kernel panic from Python 🤷

I distinctly remember some pain, but maybe my memory is betraying me and it wasn't that bad... don't let it get in your way.

Thanks for the other info. Indeed, that's problematic.