Re-plug event log is not informative (as I can judge it): it saying that new device detected only (but yet can show it’s work mode).
here is mine plug in log if you want to compare
Sep 29 01:06:49 pc kernel: usb 1-5: USB disconnect, device number 4
Sep 29 01:07:01 pc kernel: usb 1-5: new full-speed USB device number 7 using xhci_hcd
Sep 29 01:07:01 pc kernel: usb 1-5: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.07
Sep 29 01:07:01 pc kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 29 01:07:01 pc kernel: usb 1-5: Product: USB Receiver
Sep 29 01:07:01 pc kernel: usb 1-5: Manufacturer: Logitech
Sep 29 01:07:01 pc kernel: logitech-djreceiver 0003:046D:C52B.0009: hiddev96,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-5/input2
Sep 29 01:07:01 pc kernel: input: Logitech K360 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.2/0003:046D:C52B.0009/0003:046D:4004.000A/input/input21
Sep 29 01:07:01 pc kernel: logitech-hidpp-device 0003:046D:4004.000A: input,hidraw2: USB HID v1.11 Keyboard [Logitech K360] on usb-0000:00:14.0-5/input2:1
Sep 29 01:07:01 pc kernel: input: Logitech Wireless Device PID:4055 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.2/0003:046D:C52B.0009/0003:046D:4055.000B/input/input22
Sep 29 01:07:01 pc kernel: logitech-hidpp-device 0003:046D:4055.000B: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4055] on usb-0000:00:14.0-5/input2:2
Sep 29 01:07:05 pc kernel: logitech-hidpp-device 0003:046D:4055.000B: HID++ 4.5 device connected.
Sep 29 01:07:09 pc kernel: logitech-hidpp-device 0003:046D:4004.000A: HID++ 2.0 device connected.
It is wireless USB receiver plugged out and in with 2 devices paired to it: keyboard and mice.
The current kernel is:
$ mhwd-kernel -li
Currently running: 5.15.0-1-MANJARO (linux515)
The following kernels are installed in your system:
* linux515
$ pacman -Qi linux515 | grep Version
Version : 5.15.rc3.210926.g5816b3e-1
$
May be log messages of the suspend action itself is more valuable?
What if to:
- write down local system time of the PC to a paper
- make that 60 secs delay,
- write down system time again as end of suspending
- view what happened during that 60 seconds
?
And after delay better to make
$ sync
first: it let to dump all info which could still be in cached in RAM into journals (to synchronize cached writes to persistent storage)
and than
$ journalctl -k
or even to view all events during that time interval
$ journalctl -b
may be you will find something there? at least to find the source (app name / kernel module name) which reports that mouse has been suspended. And after that to dig into learning that app/kernel module in try to setup it to fix that behavior? Also there is a small chance that UEFI/BIOS fimware or USB mouse firmware update will fix that (case of USB Controller needs to be replugged in to work - #18 by thecrimsoneye But that user “prefer to hide” (not noted) the info which firmware update fixed that issue of: UEFI or USB device).