I have Logitech G700 mouse. Using Logitech Gaming Software on Windows it’s possible to bind single keystroke or even multikey macro to single mouse button and that binding is stored internally in mouse itself, no SW needed to make it work.
For example I can: connect mouse to Windows machine, assign ‘delete’ keystroke to one of mouse buttons, unplug mouse and connect on different PC (does not matter if it’s Windows or Linux) and pressing that mouse button is recognized as ‘delete’ keyboard press.
That was working perfectly fine for me for years: I once programmed my mouse the way I liked and keep on using it under Fedora from version 26 up to recent update on v30.
After recent dnf update (check details below) it stopped working. All mouse buttons that are not assigned with regular mouse buttons no longer works, both for keyboard button bindings and for multimedia buttons like play, pause and so on.
I’ve reproduced same problem on different Fedora machine that was not updated in a while, at first it worked fine, after upgrade it stopped. Also tried to upgrade it up to Fedora 31, no change, still does not work.
I’ve check with xev and xinput test, all mouse buttons mapped as keyboard or multimedia buttons are not recognized in any way. Mouse connected to older Fedora or Windows works fine. Also tried other G700 unit (I have two), still the same.
Below are two dnf history items, one of them broke stuff. I was not able to revert them completely and update packages one by one to find the one to blame. Both updates were done on single login session, after reboot problem appeared.
I can install pure F30 on pendrive and check more deeply but I would really appreciate any suggestion what is most likely causing that. Or if anyone just knows which one is to blame or - even better - what except for downgrade I can do to have my functionality back, possible with some additional SW.
In the mean time, until it’s solved properly:
Arch Wiki: Links to key-binding software for mouses (Mouse buttons, User tools).
This one is graphical (supports Wayland, according to Arch Wiki):
“Piper is merely a frontend, the list of supported devices depends on libratbag. See the libratbag device files for a list of all known devices.”
dnf search piper
Last metadata expiration check: 21:17:29 ago on Wed 05 Feb 2020 11:38:07 AM +07.
==================================================================== Name Exactly Matched: piper =====================================================================
piper.noarch : GTK application to configure gaming mice
Thanks for response!
I’ve tried piper before posting here, forget to mention that. It does not help in any way unfortunately. I’m able to do same stuff with with that I can do with Logitech Gaming SW on Windows but mappings still does not work.
In the mean time, your can try to switch to Xorg-session (if your’re currently using Wayland).
Xorg does not help either, tried that as one of the first things 
Did your tried to connect this mouse to different ports? It’s last guess from me.
(yes, i’d read that this issue reproducible on different machines).
Yes, tried that as well
IMHO it looks like something has change somewhere and no longer permits any non-mouse buttons to be send by actual mouse. Would be nice if anyone with something other than Logitech Gaming could confirm if this is the case. Not sure if there are any mouses out there that have for example ‘play/pause’ or ‘volume up/down’ buttons build in by default, if so and my guess is correct then those would stop working as well. I tired to search for such reports but did not find any yet.
Also problem with bug reporting is that I have no idea which package caused that, that is why I asked if anyone have at least a clue which is/are most likely to blame from those two lists from first post.
For now only thing that I know that I could do is to sacrifice few hours, install f30 and play a game like update smallest set of rpms possible - reboot - check if it still works.
Your may want to start with updating the Kernel in this case of testing. Most probably it is there.
You’re right thanks!
In case anyone encounter this topic searching for solution to this problem:
5.3.16 is last one from F30 repo that works, next one 5.4.7 is not.
I noticed that dmesg and /dev/input/by-id differs. For 5.3.16:
$ dmesg | grep -i logitech
[ 10.822299] usb 3-8.3: Manufacturer: Logitech
[ 10.828727] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.0/0003:046D:C531.0004/input/input7
[ 10.828824] hid-generic 0003:046D:C531.0004: input,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input0
[ 10.831375] input: Logitech USB Receiver Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input8
[ 10.883217] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input9
[ 10.883256] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input10
[ 10.883532] hid-generic 0003:046D:C531.0005: input,hiddev97,hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input1
$ ls -la /dev/input/by-id/
total 0
drwxr-xr-x. 2 root root 160 Feb 13 08:51 .
drwxr-xr-x. 4 root root 380 Feb 13 08:51 ..
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-CM_Storm_Keyboard_--_QuickFire_XT-event-if01 -> ../event5
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-CM_Storm_Keyboard_--_QuickFire_XT-event-kbd -> ../event4
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-Logitech_USB_Receiver-event-if01 -> ../event9
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-Logitech_USB_Receiver-event-mouse -> ../event7
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-Logitech_USB_Receiver-if01-event-kbd -> ../event8
lrwxrwxrwx. 1 root root 9 Feb 13 08:49 usb-Logitech_USB_Receiver-mouse -> ../mouse0
And for latest 5.4.17:
dmesg | grep -i logitech
[ 10.581945] usb 3-8.3: Manufacturer: Logitech
[ 10.588484] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.0/0003:046D:C531.0004/input/input7
[ 10.588622] hid-generic 0003:046D:C531.0004: input,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input0
[ 10.591283] input: Logitech USB Receiver Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input8
[ 10.642665] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input9
[ 10.642700] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/input/input10
[ 10.642783] hid-generic 0003:046D:C531.0005: input,hiddev97,hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input1
[ 10.668215] logitech-djreceiver 0003:046D:C531.0004: hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input0
[ 10.794169] logitech-djreceiver 0003:046D:C531.0005: hiddev97,hidraw4: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-8.3/input1
[ 10.846384] logitech-djreceiver 0003:046D:C531.0005: device of type eQUAD step 4 Gaming (0x07) connected on slot 1
[ 10.846681] input: Logitech Wireless Mouse PID:1023 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/0003:046D:1023.0006/input/input13
[ 10.846794] hid-generic 0003:046D:1023.0006: input,hidraw5: USB HID v1.11 Mouse [Logitech Wireless Mouse PID:1023] on usb-0000:00:14.0-8.3/input1:1
[ 10.883505] input: Logitech G700 as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8.3/3-8.3:1.1/0003:046D:C531.0005/0003:046D:1023.0006/input/input17
[ 10.883692] logitech-hidpp-device 0003:046D:1023.0006: input,hidraw5: USB HID v1.11 Mouse [Logitech G700] on usb-0000:00:14.0-8.3/input1:1
[ 60.643444] logitech-hidpp-device 0003:046D:1023.0006: HID++ 1.0 device connected.
$ ls -la /dev/input/by-id/
total 0
lrwxrwxrwx. 1 root root 9 Feb 12 13:40 usb-CM_Storm_Keyboard_--_QuickFire_XT-event-if01 -> ../event5
lrwxrwxrwx. 1 root root 9 Feb 12 13:40 usb-CM_Storm_Keyboard_--_QuickFire_XT-event-kbd -> ../event4
lrwxrwxrwx. 1 root root 9 Feb 12 13:40 usb-Kingston_HyperX_Virtual_Surround_Sound_00000000-event-if03 -> ../event3
lrwxrwxrwx. 1 root root 9 Feb 12 13:40 usb-Logitech_USB_Receiver-if01-event-mouse -> ../event7
lrwxrwxrwx. 1 root root 9 Feb 12 13:40 usb-Logitech_USB_Receiver-if01-mouse -> ../mouse0
Lack of usb-Logitech_USB_Receiver-if01-event-kbd must be the reason. I’d post bug for that and try to find some workaround.
Would post here if I find anything useful.
You’ve probably already seen this but for reference: [Solved]Kernel update 5.2.11 broke some of Logitech G502 functionality / Kernel & Hardware / Arch Linux Forums
It’s from archlinux forum claiming that a kernel update causes gaming (logitech g502) mouse to no longer be recognised as a keyboard.
I don’t fully understand what is the problem but it seems it is kernel related.
There apparently was an update in the kernel causing (gaming) mice to no be recognised as a mouse and a keyboard but as a single mouse device instead.
As a noob myself I’ll just wait for a fix which should come sooner or later.
I have two Logitech G700 mice and I can reproduce the same issue on two laptops with Fedora 31.
This started happening couple weeks ago.
In my case there should be a event-kbd input but it’s missing:
$ ls /dev/input/by-id | grep Logitech
5:usb-Logitech_USB_Receiver-if01-event-mouse
6:usb-Logitech_USB_Receiver-if01-mouse
OS: Fedora 31 5.4.18-200.fc31.x86_64
Mouse: Logitech G700
Thanks for the link @hoto ! Somehow I have not found it before and it have all the knowledge needed to move on.
So for now I’ve got working WA: disable logitech driver.
It’s possible that it has side effects when you have more Logitech gear, I have only mouse so for me it’s fine but be careful if you have anything more.
-
blacklist it
$ cat /etc/modprobe.d/blacklist.conf
hid_logitech_dj
$ cat /etc/modprobe.d/local-blacklist.conf
install hid_logitech_dj /bin/false -
edit /etc/sysconfig/grub and add to GRUB_CMDLINE_LINUX:
rd.driver.blacklist=hid_logitech_dj -
make grub config:
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Long term fix is still needed but at least now I know what is going on in there and who to blame.
Thanks @gorass!
Disabling the Logitech drivers actually worked!
All my G700 buttons now works (all the macros work) 
I did not have those two files so I’ve created them.
For the less savvy people out there:
$ sudo touch /etc/modprobe.d/blacklist.conf
$ sudo vim /etc/modprobe.d/blacklist.conf
hid_logitech_dj
$ sudo touch /etc/modprobe.d/local-blacklist.conf
$ sudo vim /etc/modprobe.d/local-blacklist.conf
install hid_logitech_dj /bin/false
$ sudo vim /etc/sysconfig/grub
add flag to GRUB_CMDLINE_LINUX:
rd.driver.blacklist=hid_logitech_dj
$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Reboot system.
A stupid question then: how does the mouse still works without Logitech drivers? 
lspci -v shows the “Kernel driver” lines (for PCI things). Maybe a lsusb -v will show which driver is currently “run the mouses around there”?
PS: bookmarked.
You’re right, I simplified description probably slightly to much, your description is more precise.
As for:
With generic usbhid mouse and keyboard driver 
It’s recognized as Logitech Unifying dongle.
EDIT:
BTW that’s how it was before, on 5.3.x kernels and before G700 was handled by usbhid as well, it’s binding to hid_logitech_dj that changed