Logitune configures Logitech mice on Linux over HID++ without a background daemon

A Linux Options+ clone that talks to the mouse directly

Logitune is described as a Linux configurator for Logitech peripherals, with per-application profiles, gesture mapping, thumb wheel modes, and a dark-themed Qt Quick interface matching Logitech Options+. It is written in C++ against Qt 6, and it is not a wrapper around the vendor's own software, which does not exist for Linux.

The mechanism is the interesting part. Communication with devices happens through HID++ 2.0 directly via the Bolt receiver, and the project states plainly that no daemon is needed. That is a meaningful architectural choice. Most Linux device tooling of this kind either requires a background service holding privileged access, or ships a udev rule to hand a device to a running process. Logitune instead opens the receiver and configures the device itself, and the installation guide lists permissions as a first-class topic alongside installation.

What you get in exchange is the feature set that Options+ users expect on Windows and macOS. Automatic button, scroll and DPI switching on window focus. Button remapping to keystrokes, media controls, application launch, gestures, or a SmartShift toggle. Thumb wheel modes for volume, zoom and horizontal scroll with an invert control. Hold plus swipe gestures for desktop switching, task view, and custom keystrokes. DPI, SmartShift and scroll settings with live preview. And a system tray that shows battery status and can minimize the app.

There is also a descriptor editor that runs in-app, launched with the --edit flag, where you can position hotspots, upload images, and tune labels without hand-editing JSON files by hand.

Three MX Master models verified, the MX Anywhere family still beta

Device support is where a tool like this is either honest or not, and this one publishes a per-feature table.

The MX Master 2S, MX Master 3, and MX Master 3S are marked Verified, and every column is filled in for all three: battery, DPI, SmartShift, thumb wheel, button remapping, gestures, smooth scroll, and Easy-Switch. The MX Master 4 is also Verified with the same coverage except smooth scroll, which is explained below.

The four MX Anywhere models, meaning the MX Anywhere 3, the MX Anywhere 3 for Business, the MX Anywhere 3S, and the MX Anywhere 3S for Business, are all marked Beta. Their thumbs wheels and gestures are listed as unsupported, and the project says these descriptors ship as beta pending hardware confirmation, with issue #46 tracking the verification. The MX Vertical and the MX Vertical for Business are also beta, and their table shows no DPI and no SmartShift support.

One specific defect is documented rather than hidden. Smooth scrolling on the MX Master 4 is disabled in the shipped descriptor because the hardware does not respond correctly to the HID++ configuration used on the 2S and 3S. The regular scroll wheel and SmartShift work normally, so only sub-tick smoothing is missing. The project tells you how to re-enable it yourself by setting "smoothScroll": true in devices/mx-master-4/descriptor.json, and says that if it works on your unit the default will be promoted.

Other Logitech HID++ 2.0 devices can be added by contributing a device descriptor, so the ceiling on support is not the hardware but the number of descriptors somebody has written.

Per-app profiles need native focus tracking, which is the desktop environment limit

The feature matrix across desktop environments is where the real constraint sits.

Button remapping, media controls, DPI, SmartShift, scroll, thumb wheel modes, gesture actions, and the system tray are all marked supported on KDE Plasma 6, GNOME 42 or later on Wayland, and Hyprland. But per-app profiles and automatic profile switching are supported on those three and marked as not available on other desktop environments.

That is a technical consequence, not a policy choice. A per-app profile has to be applied when a window takes focus, which requires the application to track the focused window natively on each desktop. The project supports KDE and GNOME that way, and lists block shortcuts during capture as unsupported on GNOME and Hyprland as well.

So the honest summary is: the mouse configuration works broadly, and the profile automation works on the desktops that expose focus information. If you run Sway, Xfce, Cinnamon, or anything else outside that list, you still get remapping and DPI control, but the automatic switching that is arguably the headline feature is off the table.

The reconnect handling is worth a mention too. Automatic re-enumeration and profile reapplication after a disconnect and reconnect is listed as a feature, which matters more than it sounds for a wireless mouse that sleeps and wakes.

Installing from an OBS repository, and what the source build actually does

There are four install routes, and the packaged ones are the ones most people should use.

Ubuntu 24.04 gets the package from an Open Build Service repository:

echo 'deb http://download.opensuse.org/repositories/home:/mmaher88:/logitune/xUbuntu_24.04/ /' | sudo tee /etc/apt/sources.list.d/logitune.list
wget -qO- https://download.opensuse.org/repositories/home:mmaher88:logitune/xUbuntu_24.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/logitune.gpg > /dev/null
sudo apt update && sudo apt install logitune

Fedora 42 uses the same repository system through dnf:

sudo dnf config-manager addrepo --from-repofile=https://download.opensuse.org/repositories/home:mmaher88:logitune/Fedora_42/home:mmaher88:logitune.repo
sudo dnf install logitune

Arch Linux users install from the AUR with yay -S logitune.

Building from source is a CMake and Ninja flow:

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
cmake --build build
sudo cmake --install build
logitune

Note the last line. After installing, the project tells you to run logitune, and the Makefile in the repository makes the same point in a slightly more detailed way: the install target ends with an udevadm control --reload-rules and a udevadm trigger before it prints the reminder to run logitune. That is the moment the udev rules become live, and it is the step most likely to be missed if you install by hand.

Four test tiers and a Makefile that shows how the project is built

The repository has a Makefile whose targets mirror the structure of the code, which is a good way to understand what is there.

There is a build target that configures a Debug build with CMake and exports compile commands, then builds with parallelism. There are three test targets, and they are separated by layer: a C++ unit and integration test binary, a QML component test binary, and a tray manager test binary. All three run with QT_QPA_PLATFORM=offscreen, which is how a Qt application is tested without a display. A test-all target chains them together. There are also run, install, uninstall, release, clean, help, setup-hooks, and packaging targets for deb, rpm, and arch packages.

The guide set includes a Testing guide with a philosophy section, four test tiers, and guidance on writing tests, plus a separate HID++ Protocol guide covering the report format, features, the Bolt receiver, and asynchronous matching. That last topic is the one to read before contributing a new device, because asynchronous matching is exactly the part that decides whether a descriptor is matched to the right physical unit when several identical mice are connected.

The guide set also has pages for Getting Started, Building, Architecture with 14 Mermaid diagrams, Adding a Device, Adding a Desktop Environment, and Contributing. The Architecture guide with diagrams is the fastest way to understand how the HID++ layer, the device descriptors, the profile manager, and the UI fit together.

Descriptors are the extension point, and the data directory is where they live

The design that makes device support extendable is the descriptor, and the repository layout makes it obvious.

At the top level there is a devices directory, a data directory with the application icon file, a src directory, a pkg directory, a packaging directory, a scripts directory, hooks, tests, and a docs directory. The descriptors are JSON, and the guide for adding a device points at a device descriptor as the contribution unit. That is a clean model: supporting a new mouse means writing a descriptor that describes its capabilities and buttons, not writing new C++.

The descriptor is also where the smooth scroll override lives. Setting "smoothScroll": true in devices/mx-master-4/descriptor.json re-enables the feature the hardware was not cooperating with. The same file therefore serves two purposes: it is the declarative description of a device, and it is the user-facing override surface for hardware quirks.

The in-app editor mode is the nicer version of the same idea for users who do not want to touch JSON at all. Launched with the --edit flag, it lets you position hotspots, upload images, and tune labels graphically. That is what makes the tool usable for a device it has never seen, since you can describe the layout by hand and still have a working profile.

For the desktop environment side, there is a hooks directory whose script the project calls a pre-push script, and a note that cmake configure sets core.hooksPath to hooks automatically, which is why the setup-hooks target is described as redundant in a container.

Maintenance pace, GPL-3.0 obligations, and what the project does not claim

The project is being worked on. The last push was on 2026-07-31, and three tagged releases landed within two months of each other: v0.3.7 on 2026-07-28, v0.3.6 on 2026-06-19, and v0.3.5 on 2026-06-08. The patch releases are quick and regular, which is what you want from a project whose code talks to firmware.

The licence is GPL-3.0, and for a device configurator that matters in a specific way. GPL-3.0 requires that derivative works be distributed under the same licence, and the repository ships packaging directories for deb, rpm, and arch packages, which is the distribution form the licence obligations attach to. That is the normal arrangement for a Linux desktop utility and is not a problem for users; it only matters if you plan to incorporate the code into a closed source product.

What the project does not claim is worth stating too. There is no compatibility promise for devices outside the table, no gesture support on the MX Anywhere family, no smooth scroll on the MX Master 4 out of the box, and no per-app profile switching outside KDE, GNOME, and Hyprland. The three caveats in the project text are precise rather than vague, which is a good sign about how the rest of the support claims should be read.

The stated limits also suggest where this tool is heading rather than where it is. Support for more HID++ 2.0 devices is a contribution problem with a known solution shape, and adding desktop environments is documented as an implementation task with its own guide.

Editorial conclusion

Logitune fits a Linux user on KDE or GNOME with an MX Master 2S, 3, 3S or 4 who wants the Options+ style controls that Logitech ships only for its own operating systems. It does not fit someone with an MX Anywhere mouse, whose descriptors are still marked beta pending hardware confirmation, or a user on a desktop environment outside the supported list, where per-application profile switching is unavailable. Before installing, check the device table for your exact model and read the udev requirement, because the tool talks to the receiver directly and needs permission to open HID++ devices.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mmaher88/logitune on GitHub
4. README
5. Releases