Configurer proprement une souris Logitech récente sous Linux reste moins simple que ça ne devrait l’être. Logi Options+ couvre Windows et macOS, mais pas Linux. Côté Linux, Solaar reste la référence historique, surtout pour les récepteurs Unifying et le diagnostic. Pour du remappage plus proche de l’expérience Options+, il manquait encore une option native et maintenable.
OpenLogi essaie de combler ce vide. Le projet est écrit en Rust, parle HID++ et fournit une interface graphique, une CLI, des paquets Linux, des règles udev et un agent systemd utilisateur. Au 28 juillet 2026, le dépôt compte plusieurs milliers d’étoiles et la dernière release observée est la v0.6.22, publiée le 21 juillet 2026.
En bref#
OpenLogi est un logiciel libre, sous double licence MIT / Apache 2.0, destiné à configurer des souris Logitech HID++ sans installer Logi Options+.
Ce qu’il sait faire aujourd’hui :
- remapper des boutons ;
- régler les DPI et gérer des préréglages ;
- configurer SmartShift sur les modèles compatibles ;
- appliquer des profils par application ;
- stocker la configuration dans un fichier TOML ;
- fonctionner localement, sans compte et sans télémétrie selon le README du projet.
Le point important pour ce blog : Linux est traité comme une plateforme cible, pas comme un cas secondaire. Le paquet installe les règles udev, fournit une unité systemd utilisateur et évite de lancer l’application avec sudo.
Le problème Logitech sous Linux#
Logitech fournit Logi Options+ pour configurer ses périphériques récents, mais l’application ne couvre pas Linux. Sur un poste Linux, on se retrouve donc avec trois choix réalistes :
- garder les réglages matériels par défaut ;
- utiliser Solaar quand le périphérique est bien supporté ;
- passer par un projet plus récent comme OpenLogi pour le remappage et les profils.
Solaar reste solide et mature. Il gère beaucoup de périphériques Logitech, en particulier les générations Unifying, et il rend service pour l’appairage, la batterie et certains réglages. Mais il ne cherche pas exactement le même compromis qu’OpenLogi :
- l’interface est plus orientée configuration classique que remappage visuel ;
- les profils par application sont plus limités ;
- l’expérience dépend beaucoup du périphérique et de la fonctionnalité HID++ concernée ;
- la configuration n’est pas pensée d’abord comme un fichier TOML versionnable.
OpenLogi arrive avec une autre approche : Rust, GPUI, configuration texte et agent dédié pour posséder la connexion HID++.
Architecture#
OpenLogi est structuré en plusieurs crates Rust :
openlogi-gui: interface desktop avec le framework GPUI (le même que celui utilisé par Zed Editor)openlogi-cli: outil en ligne de commandeopenlogi-agent: daemon qui possède la connexion HID++ et sert d’intermédiaire.
Le projet s’appuie sur la crate hidpp de @lus. D’après la feuille de route amont, OpenLogi prend en charge les récepteurs Logi Bolt, les récepteurs Unifying, les connexions Bluetooth directes et les périphériques câblés, avec des limites selon les modèles.
Le choix de GPUI est intéressant. C’est le framework Rust utilisé par Zed, avec rendu GPU et sans runtime JavaScript embarqué. Sur le papier, c’est cohérent pour une application de configuration qui doit rester résidente sans ressembler à une suite desktop complète.
L’autre point d’architecture important est la séparation GUI / agent. L’agent garde la main sur l’accès au périphérique, tandis que l’interface et la CLI pilotent la configuration. C’est plus propre que de mélanger affichage, permissions et accès bas niveau dans un seul processus.
Installation sur Linux#
OpenLogi fournit des paquets .deb, .rpm et .pkg.tar.zst pour x86_64 / amd64 et arm64 / aarch64.
# Debian / Ubuntu
sudo dpkg -i openlogi_*.deb
# Fedora / RHEL
sudo rpm -i openlogi-*.rpm
# Activer l'agent systemd pour votre utilisateur
systemctl --user enable --now openlogi-agent.serviceLe paquet installe les règles udev nécessaires pour l’accès à /dev/hidraw* et /dev/uinput sans lancer l’application en root.
Avant de tester, il faut fermer Logi Options+ sur les autres OS si vous êtes en dual boot, et surtout ne pas laisser Solaar utiliser le même récepteur en parallèle. Un seul logiciel peut posséder l’accès HID++ à un récepteur donné à un instant donné.
Première utilisation#
La CLI permet de vérifier rapidement si le périphérique est visible :
openlogi listSi un récepteur Logi Bolt ou Unifying est branché, la commande doit lister les appareils appairés et leurs informations disponibles, par exemple la batterie et le profil actif. Le détail dépend du périphérique.
La GUI se lance simplement :
openlogiL’interface affiche un carrousel des appareils détectés, un schéma de la souris avec des zones cliquables correspondant aux boutons physiques, et des panneaux pour le DPI, SmartShift et les profils par application.
Ce qu’OpenLogi apporte#
Remappage de tous les boutons#
OpenLogi expose un catalogue de 41 actions intégrées : copier, coller, retour navigateur, contrôle multimédia, changement de bureau, cycle de DPI, etc. Les raccourcis clavier personnalisés sont enregistrés dans la configuration.
Le point intéressant est le bouton de geste. Le projet permet de choisir quel bouton physique porte ce rôle, puis de définir des actions par direction. C’est plus flexible que l’approche habituelle où le rôle est attaché à un bouton dédié.
Contrôle DPI complet#
OpenLogi gère les préréglages DPI et les actions de type cycle. Le réglage est appliqué au périphérique via HID++, ce qui évite de dépendre d’une couche de remappage purement applicative.
SmartShift#
Sur les souris compatibles, notamment les gammes MX, OpenLogi expose les réglages SmartShift : mode de molette, sensibilité et mode cranté permanent. Ce n’est pas propre à OpenLogi, mais le fait de pouvoir le configurer sous Linux est le vrai sujet.
Profils par application#
OpenLogi peut appliquer des surcharges de configuration quand le focus change d’application. Sur Linux, cette partie repose aujourd’hui sur WM_CLASS, donc X11. Sous Wayland, il ne faut pas partir du principe que les profils par application fonctionneront.
Configuration en TOML#
L’avantage le plus net d’OpenLogi est la configuration en fichier texte. Le fichier est stocké dans ~/.config/openlogi/config.toml par défaut sur Linux.
schema_version = 2
selected_device = "2b042"
[app_settings]
launch_at_login = false
check_for_updates = false
[devices.2b042]
dpi_presets = [800, 1600, 3200]
[devices.2b042.bindings]
Back = "BrowserBack"
Forward = "BrowserForward"
[devices.2b042.per_app_bindings."firefox"]
Back = "Copy"Le format exact peut encore évoluer. Le projet prévient lui-même qu’OpenLogi n’est pas stable et que les fonctionnalités comme la configuration peuvent changer. En pratique, ce n’est pas gênant pour un poste de travail personnel, mais c’est à garder en tête avant de le déployer partout via dotfiles.
Vérifier son exposition Linux#
Avant d’accuser OpenLogi si rien ne remonte, quelques vérifications simples évitent de perdre du temps.
Identifier le récepteur ou le périphérique :
lsusb | grep -i logitechVérifier que les noeuds HID existent :
ls -l /dev/hidraw*Vérifier l’agent utilisateur :
systemctl --user status openlogi-agent.serviceLire les journaux de l’agent :
journalctl --user -u openlogi-agent.service -n 100 --no-pagerTester la détection OpenLogi :
openlogi listSi Solaar est lancé en même temps, fermez-le avant de refaire le test. Les symptômes typiques d’un conflit sont simples : périphérique visible dans lsusb, mais impossible à ouvrir ou absent côté OpenLogi.
OpenLogi vs Solaar#
Solaar ne disparaît pas parce qu’OpenLogi existe. Pour beaucoup de périphériques, notamment les plus anciens, Solaar reste probablement le choix le plus prudent. La comparaison utile est plutôt celle-ci :
| Critère | Solaar | OpenLogi |
|---|---|---|
| Langage | Python | Rust |
| GUI | GTK | GPUI (natif, GPU) |
| Profils par app | Limité | Oui, sous X11 côté Linux |
| Config | Interface + fichiers | TOML |
| Paquets Linux | Oui (.deb/.rpm) | Oui (.deb/.rpm/.pkg.tar.zst) |
| Support Windows | Non | Oui, port plus récent |
| Maturité | Élevée | Projet récent |
| Bouton de geste | Selon support périphérique | Configurable, capture encore partielle |
Le bon choix dépend du besoin.
- Pour appairer, diagnostiquer ou gérer un vieux périphérique Logitech, Solaar reste souvent plus rassurant.
- Pour remapper une souris récente, gérer des profils et versionner la configuration, OpenLogi devient intéressant.
- Pour un poste Wayland strict où les profils par application sont indispensables, OpenLogi n’est pas encore le bon outil.
Les deux projets peuvent coexister sur une même machine, mais pas utiliser le même récepteur simultanément.
Vie privée#
Le README d’OpenLogi annonce une approche locale : pas de compte, pas de cloud, pas de télémétrie. Les deux appels réseau mentionnés par le projet sont limités à la récupération optionnelle des images de périphériques et à la vérification de mise à jour, désactivée par défaut.
C’est un vrai avantage pour un outil qui a accès à des événements d’entrée. Même sans partir dans la paranoïa, une application de configuration de souris n’a pas besoin d’un modèle cloud pour appliquer un profil DPI ou remapper un bouton.
Limitations actuelles#
OpenLogi est en développement actif et pas encore stable. Quelques points à prendre en compte :
- Le récepteur ne peut être utilisé que par un seul logiciel à la fois. Il faut quitter Options+ ou Solaar avant de lancer OpenLogi.
- Les profils par application sur Linux ne fonctionnent que sous X11 pour le moment.
- La capture matérielle de certains boutons reste partielle, notamment autour du bouton de geste, du mode-shift et de certaines molettes.
- Windows est supporté, avec des builds signés, mais le port reste plus récent que Linux et macOS.
- La compatibilité avec les anciens périphériques Unifying est moins large que Solaar.
- Le format de configuration peut encore changer.
Conclusion#
OpenLogi répond à un besoin réel : configurer une souris Logitech récente sous Linux sans dépendre de Logi Options+ ni d’un compte cloud. Le projet est encore jeune, mais les choix techniques sont cohérents : accès HID++ dédié, agent utilisateur, interface native et configuration TOML.
Ce n’est pas un remplacement universel de Solaar. C’est plutôt un bon candidat si vous cherchez du remappage avancé, des profils et une configuration versionnable.
Pour un poste Linux avec une MX Master, une MX Anywhere ou un modèle récent bien supporté, ça vaut clairement un test. Pour un environnement plus ancien, ou si Solaar couvre déjà le besoin sans friction, il n’y a pas d’urgence à changer.
La prudence reste simple : tester sur une machine, garder Solaar disponible, vérifier le comportement sous votre session graphique, puis décider. Pour un outil aussi proche de la couche d’entrée, c’est plus sérieux qu’une migration faite uniquement parce que le dépôt GitHub monte vite.
Sources#
- OpenLogi, dépôt GitHub : https://github.com/AprilNEA/OpenLogi
- OpenLogi, site officiel : https://openlogi.org/en
- OpenLogi, documentation de connexion : https://openlogi.org/en/docs/getting-started/connect-device
- OpenLogi, releases : https://github.com/AprilNEA/OpenLogi/releases
- OpenLogi, configuration : https://github.com/AprilNEA/OpenLogi/blob/master/docs/CONFIGURATION.md
- Solaar : https://github.com/pwr-Solaar/Solaar
- Crate
hidpp: https://crates.io/crates/hidpp - GPUI : https://github.com/zed-industries/gpui
