# Solaar: a Linux manager for Logitech receivers, mice and keyboards

> Solaar is a GPL-2.0 Python application that pairs Logitech devices, changes their settings and runs rules on the special messages Linux otherwise ignores. It is not a driver, and it is not for Windows or macOS.

**pwr-Solaar/Solaar** — Linux device manager for Logitech devices

- Repository: https://github.com/pwr-Solaar/Solaar
- Website: https://pwr-solaar.github.io/Solaar
- Stars: 9,419 · Forks: 578
- Language: Python
- License: GPL-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pwr-solaar-solaar

## How Solaar talks to receivers, devices and rules

A Unifying, Bolt, Lightspeed or Nano receiver presents itself to Linux as a normal input device, so typing and pointing work without any extra software. What the kernel input layer does not expose is the rest of the conversation: pairing a new device to the receiver, unpairing one, reading battery status, changing scroll behaviour, remapping buttons, or reacting to special messages the device sends. The README is explicit about the boundary: Solaar "is not a device driver and responds only to special messages from devices that are otherwise ignored by the Linux input system." That sentence is the whole design premise. Solaar sits beside the input stack rather than replacing it, which is why it can be installed and removed without affecting whether your mouse moves the cursor.

The audience follows from that. You need Linux, a Logitech device that speaks one of the supported receiver protocols or connects over USB or Bluetooth, and a reason to change something the default stack will not let you change. If you only want the mouse to work, you do not need Solaar. If you have two receivers and want to know which device is paired to which, or you want a thumb button to trigger a shell command, the input layer gives you nothing and Solaar gives you the channel.

## Installing Solaar from distro packages, pip or pipx

The repository layout tells you most of the architecture. Application code lives under lib/, command line entry points and helper scripts under bin/, documentation under docs/ with mkdocs.yml driving the published site, translations under po/, and udev rules under rules.d/ and rules.d-uinput/. The two rule directories matter: rules.d/42-logitech-unify-permissions.rules grants the permissions Solaar needs to open the receiver, and the uinput variant is the one the Makefile installs for the Ubuntu path via install_udev_uinput. Without a rule in place, Solaar starts but cannot reach the hardware, which is the most common first-run failure.

Solaar is written in Python and the packaging reflects that. setup.py reads the version from lib/solaar/version, then tries to record a commit with git describe, falling back to dpkg-parsechangelog output. Data files declared there include the hicolor icons, the compiled .mo translations, share/applications/solaar.desktop, and that udev rule. The declared description calls it a "Linux device manager for Logitech receivers, keyboards, mice, and tablets." Dependencies in the Makefile point at the stack you would expect for a GTK application on Linux: gtk3, python3-gobject, python3-dbus, python3-pyudev, python3-psutil, python3-xlib and python3-yaml for the dnf path, and libdbus-1-dev, libglib2.0-dev, libgtk-3-dev and libgirepository1.0-dev for the apt path.

The feature set the README lists is four items: pairing and unpairing devices with receivers, configuring device settings, custom button configuration, and running rules in response to special messages. The rules subsystem is the part that separates Solaar from a settings panel. A rule watches for a message from a device and fires an action, and the repository ships rules.d-uinput/ alongside it, which is a hint that some rule actions synthesize input events rather than just toggling a device setting. The documentation site has a dedicated rules page and a capabilities page; the README itself does not enumerate which devices support which settings, so device-by-device expectations have to come from those pages rather than from the top-level file.

## Where Solaar stops being the right tool

The README's first recommendation is to check your distribution. It states that up-to-date prebuilt packages are available for some distributions, naming Fedora as an example, and warns that other repositories "may be several versions behind the current version." That warning is worth taking literally: the Debian, Ubuntu universe, Gentoo and Mageia packages are listed separately from the current ones, and the current ones named are the Arch extra repository, the Solaar stable PPA for Ubuntu and Kubuntu, and the NixOS flake at Svenum/Solaar-Flake. If you are on Arch, the package name is solaar. If you are on Ubuntu or Kubuntu, the README points at the stable PPA rather than universe.

For a source install, the Makefile encodes the intended sequence. On Ubuntu the aggregate target is install_ubuntu, which runs the apt dependencies, the uinput udev rule and pip in that order. On macOS the aggregate target is install_macos, which runs install_brew then install_pip; the README does not present macOS as a supported target, and the Makefile target exists without documentation of what works there, so treat it as unverified.

The dependency step for a Debian-family machine is:

```bash
sudo apt update
sudo apt install libdbus-1-dev libglib2.0-dev libgtk-3-dev libgirepository1.0-dev
```

After that, the Makefile installs the udev rule and reloads the daemon. The rule source is rules.d-uinput/42-logitech-unify-permissions.rules and the destination is /etc/udev/rules.d/, set as UDEV_RULES_DEST in the Makefile:

```bash
sudo cp rules.d-uinput/42-logitech-unify-permissions.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
```

The Python install itself is a plain pip call, with PIP_ARGS defaulting to the current directory. The Makefile also offers a pipx path that installs with system site packages, which is the variant that makes sense for a GTK application that needs the distribution's PyGObject rather than a wheel:

```bash
python -m pip install --upgrade pip
pip install .
```

```bash
pipx install --system-site-packages .
```

Once installed, the first real use is to launch Solaar with the receiver plugged in and see whether it enumerates. The README's screenshots show a main window with multiple devices and a second view scoped to a single receiver, plus a back-divert panel and a rule editor. If the window opens but lists nothing, the udev rule is the first thing to check, because that is the permission boundary the Makefile exists to set up. Pairing, unpairing and settings changes are all driven from that window; the README does not document a headless workflow, so the GUI is the entry point.

## Solaar compared with Piper and logiops

The clearest limitation is the one the project states itself: Solaar is Linux only. The related searches include people looking for Solaar on Windows and on macOS, and the README offers no support for either. The install_macos target in the Makefile installs brew dependencies and then pip, but nothing in the README claims the application functions on macOS, and the dependency list is built around GTK and udev, neither of which is the macOS model. If you are not on Linux, this is not your tool.

A second boundary is the device list. Solaar covers Logitech hardware that connects through a Unifying, Bolt, Lightspeed or Nano receiver, or over USB or Bluetooth, and it acts only on the special messages those devices send. A device that never emits those messages gives Solaar nothing to work with, and the README does not publish a compatibility matrix at the top level. The capabilities page on the documentation site is where that question is answered, and the README's own pointer to a Known Issues page suggests the set of working combinations is not uniform.

The third is packaging drift. The README's own wording, that some repositories "may be several versions behind the current version," means a bug you hit may already be fixed upstream and still present in your distro package. That is not a Solaar-specific sin, but it changes what a bug report is worth. If you file an issue against a stale package, the maintainers are working with a different codebase than the one you are running. Check the version you actually have before assuming the problem is current.

## Maintenance, licensing and what a Solaar upgrade costs

The searches pair Solaar with Piper and with logiops, and the difference is in what layer each one operates on. Piper is associated with configuring gaming mice through libratbag, which is a different device abstraction than Solaar's receiver-message channel. Solaar talks to the receiver and to the device's own special messages; a configuration tool built on libratbag talks to the device through that library's model of profiles and resolution settings. If your goal is DPI stages and LED zones on a gaming mouse, the libratbag route is the one aimed at that job. If your goal is pairing a second keyboard to a Unifying receiver, reading battery levels and firing a rule when a button is pressed, Solaar is the one that exposes those.

logiops is the other comparison, and the difference there is architectural rather than feature-level. Solaar is a Python GTK application that a user launches; logiops is a daemon-style approach to Logitech HID++ devices, which means configuration is persistent and not tied to an open window. That matters if you want button behaviour to survive a reboot without a session application running. Solaar's rules are part of its application model, and the README does not describe a background service mode. The trade-off is legibility: Solaar's rule editor is a visible, editable thing, while a daemon configuration is a file you maintain. Neither is strictly better; they suit different expectations about where configuration should live.

## Frequently asked questions about Solaar

The last push to the default branch was on 2026-08-18, and the most recent release listed is 1.1.20 from 2026-06-28, preceded by 1.1.20rc3 and 1.1.19. The repository is not archived. That pattern, a release candidate followed by a stable release a few days later, is what the release history shows; it suggests changes are staged through release candidates rather than shipped straight to stable.

Solaar is licensed GPL-2.0, and setup.py declares the package name as solaar. The practical implication of the GPL for most users is nil: you install it and run it. For anyone embedding it, the licence is the ordinary copyleft one, and the LICENSE.txt at the repository root is the authoritative text. Nothing here is legal advice; read the licence if you are redistributing.

Upgrade cost is mostly a packaging question. If you installed from a distribution repository that tracks current versions, upgrades arrive with the rest of your system. If you are on a distribution whose package lags, moving to the PPA, the Arch extra package or the Nix flake is how you get current code, and the README lists those as the up-to-date sources. For a pip or pipx install, the upgrade is a reinstall of the package directory, and the udev rule is a file you copied once; a new release that changes the rule would need that copy repeated. The Makefile's uninstall_udev target exists for removing it. The README does not document a migration path between major versions, so nothing here should be read as a promise that settings carry forward.

## Conclusion

Adopt Solaar if you run Linux with a Logitech receiver and want pairing, per-device settings or rules that react to button and gesture messages. Skip it if you need Windows or macOS support, or if a plain HID remapper already covers your use case. Before installing, check whether your distribution ships a current version, and confirm the udev rule lands in /etc/udev/rules.d/ with make install_udev_uinput.

## FAQ

### What is Solaar?

Solaar is a Linux device manager for Logitech keyboards, mice and other devices that connect through Unifying, Bolt, Lightspeed or Nano receivers, or over USB or Bluetooth. It is not a device driver and only acts on special messages the Linux input system ignores.

### How do I install Solaar on Linux?

The README recommends checking your distribution first, since up-to-date packages exist for some distributions, with Fedora named as an example. Otherwise it points to the Arch extra repository, the Solaar stable PPA for Ubuntu and Kubuntu, or the Svenum/Solaar-Flake NixOS flake, and the Makefile provides install_ubuntu and install_pip targets for a source install.

### How do I install Solaar on Ubuntu?

The README lists a Ubuntu/Kubuntu package in the Solaar stable PPA as the current source, separate from the Ubuntu universe repository, which may lag behind. For a source install on Ubuntu the Makefile target install_ubuntu runs the apt dependencies, the uinput udev rule and pip in sequence.

### How do I install Solaar on Arch?

The README names the Arch solaar package in the extra repository as one of the up-to-date prebuilt packages.

### How do I use Solaar?

You launch the application with a supported receiver or device connected, then pair or unpair devices, change device settings, configure buttons, or run rules in response to special messages from the device. The README does not document a headless workflow, so the graphical window is the entry point.

### How do I install Solaar on Fedora?

The README states that up-to-date prebuilt packages are available for some Linux distributions in their standard repositories and names Fedora as an example, so the distribution package is the first place to look. For a source build, the Makefile's install_dnf target installs gtk3, python3-devel, python3-gobject, python3-dbus, python3-pyudev, python3-psutil, python3-xlib and python3-yaml.

## Sources

- [License: GPL-2.0](https://github.com/pwr-Solaar/Solaar/blob/master/LICENSE)
- [Project website](https://pwr-solaar.github.io/Solaar)
- [pwr-Solaar/Solaar on GitHub](https://github.com/pwr-Solaar/Solaar)
- [README](https://github.com/pwr-Solaar/Solaar/blob/master/README.md)
- [Releases](https://github.com/pwr-Solaar/Solaar/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pwr-solaar-solaar