The Logitech Unifying Receiver is a wireless receiver using 2.4 GHz band radio communication that can connect up to six compatible wireless mice and keyboards to your computer.The input device that comes with the receiver is already paired with it and should work out of the box through plug and play.Logitech officially supports pairing of additional devices just through their Windows and macOS software.
Should Logitech Options and Logitech Options Daemon be listed in 'Login Items'? Comment Weaselboy Moderator. Jan 23, 2005 31,454 11,150 California.
Pairing and unpairing on Linux is supported by a number of tools, listed thereafter:
ltunify is a command-line C program that can perform pairing, unpairing and listing of devices. Solaar is a graphical Python program that integrates in your system tray and allows you to configure additional features of your input device such as swapping the functionality of Fn keys. libratbag is a configurable mice daemon that allows you to configure your devices, it has a GTK based graphical frontend app, piper.
Installation
Several solutions are available:
Logitech Options is a powerful and easy-to-use application that enhances your Logitech mice, keyboards, and touchpads. Customize your device with Options and do more than you thought possible. Logitech Control Center permission prompts on macOS Catalina; Logitech Control Center permission prompts on macOS Mojave; NOTE: We are aware that after upgrading from macOS 10.14 Mojave or earlier to macOS 10.15 Catalina with LCC (Logitech Control Center) versions 3.9.8 or below, some Logitech Unifying-based devices may stop working. Logitech Options needs them for mouse stuff and button mapping/macros in other apps, Dropbox needs them to put its little popup over MS Office documents to let you know other people are currently working with them, some apps like this need certain disk access permissions and the like as well.
- libratbag/piper
- pairing_toolAUR
The following packages use the plugdevuser group, create it if it does not exist, and add users to this group to avoid the need of running these as root:
- solaar or solaar-gitAUR
- ltunifyAUR or ltunify-gitAUR
Do not forget to relogin to apply user's group membership. After installation, run
and then replug reciever. After that you will not need root permissions.
Usage
pairingtool can only be used for pairing and does not provide feedback, it also needs to know the device name for pairing. ltunify, Solaar and libratbag can detect the receiver automatically.
ltunify
Examples on unpairing a device, pairing a new device and showing a list of all devices:
Solaar
Solaar has a GUI and CLI. Example CLI pairing session:
To disable autostart of Solaar, remove /etc/xdg/autostart/solaar.desktop.
libratbag
Currently, piper is not able to pair/manage devices for unifying receivers but libratbag does include a lur-command command line tool that is able to do this.
pairingtool
To find the device that the receiver has, therefore take a look at the outputs of
This will show the names of your receiver, for example hidraw0.
Now switch off the device that you want to pair (if it was on) and execute your compiled program with the appropriate device as argument:
Now switch on the device you want to pair. After a few seconds your new device should work properly.
Known Problems
Wrong device (pairing tool only)
On some systems there is more than one device that has the same name. In that case you will receive the following error message when the wrong device is choosen:
Keyboard layout via xorg.conf
With kernel 3.2 the Unifying Receiver got its own kernel module hid_logitech_dj which does not work flawlessly together with keyboard layout setting set via xorg.conf.A temporary workaround is to use xorg-setxkbmap and set the layout manually. For example for a German layout with no deadkeys one has to execute:
To automate this process one could add this line to xinitrc or the according autostart file of your windows manager respectively desktop environment.
Logitech touchpad keyboard K400r with unifying receiver M325
The Logitech keyboard K400r with integrated touchpad comes with Logitech unifying receiver M325 so the above mentioned about the keyboard layout will apply here too.
Also the integrated touchpad is recognized as 'pointer' instead of 'touchpad' so you cannot use the Touchpad Synaptics drivers.Two finger horizontal scrolling and tapclick will work but in order to have a middle mouse button emulated you will have to add
to your evdev.conf. Now third button is emulated by pressing both buttons simultaneously.
Solaar 'Permission denied'
Is it possible to have the error:
In this case, you can physically remove the Unifying Receiver and re-insert it, and re-run the command (as described in the second point of installation part on the official site [1]).
Wireless Keyboard does not work while booting (cannot enter luks passphrase)
While booting it's impossible to input anything with a Logitech wireless Keyboard (e. g. Logitech MK700).The cause of the problem is the own hid module for Logitech devices since Kernel 3.2.
A workaround is adding hid-logitech-hidpp to MODULES in /etc/mkinitcpio.conf:
Logitech Options Daemon Location
and recreate the initrd for the kernel:
MouseJack Vulnerability
Several security vulnerabilities of the system have been reported and you may be in particular affected by the MouseJack Vulnerability if your firmware has not been updated recently.
It is possible to display the current firmware's version by running:
RQR12 firmware with version earlier than 012.008.00030 and RQR24 firmware versions earlier than 024.006.00030 are affected by this vulnerability and should be updated.
The firmware can be updated using fwupd like so:
If everything looks good, apply the update:
Keyboard or mouse does not wake pc from sleep
Follow the Solaar USB installation instructions.
Lag of the wireless device
Because the receiver uses the 2.4 GHz frequency band also used by Bluetooth and Wi-Fi 802.11, it is possible in some circumstances of heavy Wi-Fi usage close to the receiver to experience lag or disturbances in communication with the devices. This is unlikely because the receiver confines its communication to channels unused by the majority of 802.11 solutions and it is able to quickly change channel within the band if it detects any interference from another device. However, some users have experienced interferences.
Switching on/off the device will force the search for a 'quiet' channel and may solve the issue.
This problem can also manifest if there is electrical noise from USB3 sockets on the motherboard, and it is located close to or in one. Moving the receiver to a USB hub or the end of an extension cable may fix this.
Logitech Options Update
Lagging scrolling
If you have several receivers in system, for example you use multi-device keyboard and mouse and passthrough one of the receivers while using pci passthrough setup and after you turned off your guest machine, that receiver got appeared in the host OS, the input may become laggy. While mouse moving is good, the scrolling with wheel is unacceptably slow (scrolling step is very small). In that situation, unplugging and replugging the receiver may help (however, it may fall to this laggy mode just after several seconds again). Also if you use multi-device peripherals (for example, MX Master mouse), you may just reswitch to the current port with the device-number button.
See also
Logiops - Logitech Options alternative for configuring supported mice and keyboards
State of Affairs
If you use third-party mice with your Mac, you've surely noticed just how useless the side buttons are. By default, they act as a sort of crippled middle click, consigned to opening new links out from under you when you least expect it. Compare to Windows, where those same buttons allow you to fluidly navigate back and forward in practically any window with a history. Once you've gotten used to this feature, it's hard to get by without it.
Here's a demo of how the side buttons work in macOS by default. The colored circles stand for button clicks, with orange representing the bottom/back side button (M4) and blue representing the top/forward side button (M5). Each of the four windows already has a history.
As you can see, this binding is completely useless. Except for opening new links in browsers, there's no response in any of the apps. (And unlike with an actual middle click, you can't even click to close the tabs afterwards.) Frankly, it's not clear to me why these buttons do anything at all!
The most common fix for this silly behavior is to rebind the side buttons to ⌘+[ and ⌘+] — standard, OS-wide shortcuts for navigating history. This behavior can't be configured natively in System Preferences, but it's used in everything from Logitech's mouse software to third-party tools like USB Overdrive. Unfortunately, while this works fine in most applications, it still doesn't feel very natural. Whenever you click one of the side buttons, you either get a distracting menu bar blink or an obnoxious alert sound. In contrast to every other mouse function, each side click is sent to the entire foreground application instead of the specific view under your cursor. Behavior can be unpredictable in some contexts depending on how the foreground application has its keyboard shortcuts configured. In other words, you can't rely on this approach.
Here's a demo of the keyboard shortcut binding in action.
Decidedly less useless, but still frequently confusing. For instance: if you have lots of windows open in an application, how do you know from a glance which one your navigation click is going to? In the video, you can see the navigation commands going to Finder even when the cursor is hovering over a different window. Or, if you're unfamiliar with an app, how can you be sure that the side buttons won't trigger some state-changing shortcut, as they do with indentation in Xcode? Keyboard shortcuts are unpredictable, and this makes the side buttons feel unsafe in practice. You learn to avoid them unless necessary.
SensibleSideButtons
In contrast to the above two approaches, SensibleSideButtons makes your side buttons behave like bona fide navigation keys. Navigation now works in practically any application with a history, even if there aren't any keyboard shortcuts bound to forward and back. Navigation commands are sent directly to the view under your cursor, alleviating mistakes and even (hypothetically) allowing multiple navigable sections within a single window to be controlled independently. There's no blinking menu bar, no annoying noises, no fear of errant keyboard shortcuts messing with your workflow. Best of all, the code is native, clean, and very simple. All we're doing is dusting off some slightly forgotten parts of macOS.
Here's a demo of the side button behavior when using SensibleSideButtons.
Pretty much perfect! All four windows, including Xcode and Documentation, perform exactly as one would hope. And there's no more confusion if the cursor is over a non-navigable or out-of-focus window when the side button is clicked: the command simply resolves to nothing instead of triggering an application-wide shortcut.
SensibleSideButtons lives in your menu bar. That's it: while it's up there, you'll get the sensible back/forward behavior, and when it's gone there's no trace of the behavior left. (You can also open the app menu and selectively enable or disable it as you please.) There's no CPU overhead or any weird polling — just some system-wide events getting sent out whenever M4 or M5 is clicked.
Technical Notes
I've suffered with poorly-behaving side buttons on all my third-party macOS mice for years, to the point where I just assumed that the problem was unfixable. But then I got my hands on a Logitech MX Master, and I was surprised to discover that the side buttons on this particular mouse (and no others!) behaved in that ideal, universal, Windows-like way. No blinking menu bars... navigation localized to the view under your cursor... consistent behavior in practically every app. It was the first time I'd seen it on a Mac!
Curious about the unusual behavior, I whipped out Xcode and wrote a quick application to capture mouse click events and do some analysis. First question: what was the standard, expected macOS behavior for the side buttons in generic mice? Testing several models, I discovered that the side buttons emitted standard M4 and M5 commands just as they did in Windows. It just so happened that macOS didn't want much to do with these commands, and they also couldn't be rebound in any native way.
Inferring, then, that the Master was doing something special with its side buttons, I tried capturing them as well. To my surprise, they appeared to emit nothing! I guessed that perhaps the Logitech driver was doing something interesting to make them work this way. But what was the secret? The Master's side buttons behaved in a completely consistent way across all my software, so it probably wasn't some special-purpose Logitech code. (Although I couldn't rule this out.) The buttons were definitely not emitting keyboard shortcuts since they were missing the trademark menu bar blink and only affected views under the cursor. There had to be a global set of back/forward events in macOS that was being emitted here, but hours of bitter Googling couldn't yield evidence of such events existing. I also looked into AppleScript tricks, but those lead to a similar dead end.
A bit stumped, I decided to capture all the events emanating from the MX Master. And there was a hit! The side buttons weren't being seen by the OS as clicks at all, but fake three-finger swipe gestures.
For several years, the standard navigation gesture in macOS has been the two-finger drag: snazzy, but mostly limited to Safari and a few other apps. However, a legacy three-finger swipe can be additionally enabled in Trackpad preferences, and while it's not nearly as flashy as its younger brother, it works far more universally across the OS. Under the hood, this gesture is basically free to implement: all you have to do is include a swipeWithEvent: selector in your view controller or responder and you're good to go. Then, if the user performs a three-finger swipe with the cursor over your view, it triggers the selector and presumably navigates in the corresponding direction.
In other words, this gesture is as close to a global back/forward event as exists in macOS. Unfortunately, the type of event that it emits — NSEventTypeSwipe — cannot be generated programmatically.
I really wanted to port this behavior to my own third-party mice, but macOS was stubbornly standing in my way! How was Logitech creating these events? Did they have access to some private frameworks? Was there some reverse-engineering involved? I thought I'd have to either capture the binary event data and clone it for my own use, or alternatively send a contraband message to whatever Logitech process was handling this behavior. (I figured it was the Logitech Options Daemon, since CPU usage spiked significantly when mashing the side buttons.) But I lucked out, as someone else had already done the hard work in this area.
In order to create the gesture code for an application called Sesamouse, developer Nathan Vander Wilt reverse-engineered the data structure of gesture-based NSEvents and released his work as open source. Playing around with his functions, I quickly discovered the winning combination that would get me the same gesture events that the Master was sending out. The swipe event didn't even require a mouse position, so there was no need to reason about coordinates. It was as simple as a NSEventPhaseBegan event followed immediately by a NSEventPhaseEnded event.
The other half of the puzzle was stifling the M4 and M5 commands and replacing them with this falsified gesture. Fortunately, macOS provides a very easy way to do this through the use of event taps. With a simple call to CGEventTapCreate and a filter of kCGEventOtherMouseUp and kCGEventOtherMouseDown, a callback is scheduled for each numbered mouse button click. The callback is allowed to return an event other than the default, so I simply returned NULL for M4 and M5 and then sent out my fake events instead. As far as I can tell, event taps have almost no overhead.
You can get the source code (GPLv2) for SensibleSideButtons on Github or as a zip.
Credits
SensibleSideButtons is made by me — Alexei Baboulevitch. You can find me on Twitter @archagon, and e-mail me at ssb@archagon.net. My blog can currently be found at http://beta-blog.archagon.net.
A huge thanks to Nathan Vander Wilt for the tremendous work involved in reverse-engineering event handling in macOS. I would have surely given up if his Touch project hadn't existed!
SensibleSideButtons is free because I believe it's an optimal solution to a longstanding issue with macOS. I'd rather treat it as a bugfix than a product and make it available for anyone to download and enjoy! However, if you find that the app improves your productivity as much as I think it will, please consider leaving a small donation or buying something through my Amazon affiliate link. I'd greatly appreciate it, and it will help fund this and many other useful software endeavors.
Thank you for visiting!