Logitech M720 mouse thumb button does nothing at all

I am running Fedora Linux 39 (Workstation Edition) and I just got a Logitech M720 Triathlon Mouse. One of the buttons on it is called a “thumb button”. It’s below the forward and back buttons. On Windows it’s used for gestures by default. On Linux I think it’s supposed to send a Ctrl+Alt+Tab keypress by default.

But it’s not doing anything at all for me. If I run the xev event tester, all the other buttons and mouse movement show up (except for the toggle & connect button, which is used to connect to other receivers). But the thumb button produces no output in xev at all, as though I’m not pressing the button. I tried connecting to mouse to a Windows box to see if I got a damaged mouse, but the button works fine there.

I tried mapping the button using solaar, Piper, and Mouse Actions, to no avail. I tried closing solaar and stopping the ratbagd service. I made sure mouse-actions wasn’t running. I tried uninstalling logiops. I haven’t installed xautomation or imwheel. I tried unsetting the “Switch system controls” (Ctrl+Alt+Tab) default keyboard shortcut. So if something is blocking this button, I don’t know what it is.

I’m connecting to the Fedora laptop via Logitech’s Unifying USB receiver. The mouse shows up fine in ratbagd output and in /proc/bus/input/devices.

Does anyone have any ideas how I can get something to see this button being pressed?

Ok, I got something, and it’s weird. When I initially set up this mouse, I paired it using solaar to a Logitech Unifying USB receiver which I’ve had plugged into my Fedora box for a long time. I plugged the new Unifying receiver into my Windows box. Just now, I tried taking that new Unifying receiver and plugging it into my Fedora box (removing my old Unifying receiver), and now xev shows the button being pressed. It appears as Control_L + Alt_L + Tab.

Both Unifying receivers are model C-U0007, though the exact etching on the two are pretty different. I plugged my old Unifying receiver into my Windows box, and the Logi Options+ software I’ve got there said that the thumb button was now mapped to Keyboard Shortcut: None. This is not the option I’d chosen last time I had the mouse connected to Windows through the new Unifying receiver. I used the software to change it to Keyboard Shortcut: Windows, and put the old Unifying receiver back into my Lenovo box. And now my old Unifying receiver is working correctly in xev, with the thumb button showing up as Control_L + Alt_L + Tab.

So, are profile settings stored on the Unifying receiver USB dongle? Or maybe the mouse stores profile settings and saved them for each Unifying receiver? Or maybe the mouse stores profile settings and associates them to each of its 3 channels (that toggle & connect button)?

Whatever it is, I think I’ve got it fixed enough now that I can figure out how to map that button to do what I want.

1 Like

So this seems to be a hardware problem. Maybe that other receiver also just didnt support that one button.

That nothing appears in xenv (or whatever the Wayland equivalent is) means Fedora cant do anything likely.

Now that the button appears, you can remap it to the desired action in GNOME and KDE. You could close this and mark your second comment as answer.

Yeah, could be a hardware problem. Weird that after fiddling with it using Logitech’s software on a Windows computer, the dongle started working fine on the Fedora box.

I used Fedora’s keyboard shortcuts settings to create a keyboard shortcut for myself (I’ve left the “Switch system controls” default keyboard shortcut disabled). Just pressing the thumb button when I was asked to press the key binding worked just fine, and it showed up as Ctrl+Alt+Tab. I set it to run a command to show or hide GNOME’s Activities Overview. I found that dbus-send is much faster than xdotool.

bash -c 'if ( dbus-send --print-reply --session --dest=org.gnome.Shell --type=method_call /org/gnome/Shell org.freedesktop.DBus.Properties.Get string:org.gnome.Shell string:OverviewActive | grep --quiet "boolean false" ); then dbus-send --session --dest=org.gnome.Shell --type=method_call /org/gnome/Shell org.freedesktop.DBus.Properties.Set string:org.gnome.Shell string:OverviewActive variant:boolean:true; else dbus-send --session --dest=org.gnome.Shell --type=method_call /org/gnome/Shell org.freedesktop.DBus.Properties.Set string:org.gnome.Shell string:OverviewActive variant:boolean:false; fi'

This command can probably be made a lot shorter, but I don’t think I can call dbus-send just once; there doesn’t seem to be a toggle option.

I’ll mark my reply as the solution.

1 Like

This can happen when you have a device with old firmware and the new software not supports it anymore.

When you check here (follow the link) you will see that Linux is updating the device if you have the Linux Vendor Firmware Service running.

I guess this happened while you made an successful update with https://fwupd.org/

By the way, reading the details of the firmware information of your dongle you can do in Solar, clicking on the Unifying Receiver and on the top and then click on the light-bulb diagonal over the “About Solar” button.

I believe solaar on Linux and the Logi software on Windows is referring to the hardware address of the dongle while saving the info’s in a config file. So it is possible that you can distinguish in between the two USB dongles.

1 Like

The two receivers have the same firmware, bootloader, and “other” versions now. I don’t know if they were different versions before. They have the same USB ID, but different serial numbers. So solaar can distinguish them by serial number.

1 Like