~]$ sudo systemctl status bluetooth-autoconnect
● bluetooth-autoconnect.service - Bluetooth autoconnect service
Loaded: loaded (/usr/lib/systemd/system/bluetooth-autoconnect.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2022-01-03 07:49:59 CET; 2h 2min ago
Main PID: 712 (bluetooth-autoc)
Tasks: 1 (limit: 18382)
Memory: 21.4M
CPU: 79ms
CGroup: /system.slice/bluetooth-autoconnect.service
└─712 "/usr/bin/bluetooth-autoconnect -d"
janv. 03 07:49:59 ordi1 systemd[1]: Started Bluetooth autoconnect service.
janv. 03 07:50:00 ordi1 bluetooth-autoconnect[712]: connecting to device /org/bluez/hci0/dev_D7_62_CF_AB_6F_F7
janv. 03 07:50:00 ordi1 bluetooth-autoconnect[712]: connecting to device /org/bluez/hci0/dev_F4_4D_92_5D_3C_10
janv. 03 07:50:00 ordi1 bluetooth-autoconnect[712]: connecting to device /org/bluez/hci0/dev_F4_4E_FD_8F_F4_9B
janv. 03 07:50:00 ordi1 bluetooth-autoconnect[712]: error connecting to device /org/bluez/hci0/dev_F4_4E_FD_8F_F4_9B: br-connection-profile-unavailable
janv. 03 07:50:25 ordi1 bluetooth-autoconnect[712]: error connecting to device /org/bluez/hci0/dev_D7_62_CF_AB_6F_F7: Did not receive a reply. Possible causes include: the remote application did not send a repl>
janv. 03 07:50:25 ordi1 bluetooth-autoconnect[712]: error connecting to device /org/bluez/hci0/dev_F4_4D_92_5D_3C_10: Did not receive a reply. Possible causes include: the remote application did not send a repl>
I personally think that’s how it’s supposed to work. Perhaps because of battery power, or security (although, there I have no specifics.) Making the device (the “client”) request a connection (from the “server”) would, in my opinion, be more energy-efficient than the device constantly broadcasting its availability with the device (the “clientt”), which is very often battery powered, constantly “listening”.
I have the same extra problem with my MX Master mouse. As the OP says, it is only for Bluetooth. And I tried an MX anywhere2 mouse, which does not have this issue.
I have tried 5.15, 5.14, 5.10 kernels, the problem is the same.
This issue only showed up after a recent big update, which includes bluez and a bunch of other Bluetooth related packages. The reason I am so sure is that I notice this issue when I switch from stable branch to testing branch and did a bunch of updates. Then I switch back to stable and the issue disappeared. Then a few weeks later when the update reached the stable branch, we all have this issue now.
In my case, the mice being a Christmas present I only experienced it since and only saw one significant update.
I have another (minor) issue : the scrollwheel has one deadclick before scrolling when in click mode, if freewheel, the scroll is instantaneous. Is this a feature ?
I experience the exactly same annoying behaviour. I never had these issues with the older MX Master 2 but now with the MX Master 3 for MAC. I use the mouse both for my business notebook running Win10 and my own Notebook running Manjaro. (Btw. According to Logitech the MAC version should be exactly the same as the normal but in defferent color and without Unifiing receiver, I don’t think that this should be the Problem)
Here are some random hints i collected:
My Bluetooth connects at every startup automatically to my Amp (which is annoying) and shows for me that it is not a problem of the bluetooth card as it is up and running.
The mouse is beeing recognized by the system, the green LED flashes for a short time and battery status is shown correctly even though the mouse doesn’t move.
To get the mouse running on can either switch it off and on by the hardware switch or by disconnectin an connecting in the bluetooth system tray menu.
The interesting thing is now, that it works perfectly fine with my old 5.4 kernel. Thus I watched out for differences in the output of bluetoothctl and the difference I can see is WakeAllowed: no on 5.4 kernel where it is on, on the current 5.15 kernel.
I tried this old kernel because I have it as my backup kernel and because I read this the topic about Problems with all BLE devices on kernel 5.9+ in the Arch-Wiki (sorry I’m not allowed to post links)
Any ideas about that?
Output of bluetoothctl on Linux manjaro 5.4.169-1-MANJARO
[MX Master 3 Mac]# info
Device FC:01:23:BF:96:F8 (random)
Name: MX Master 3 Mac
Alias: MX Master 3 Mac
Appearance: 0x03c2
Icon: input-mouse
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: no
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00010000-0000-1000-8000-011f2000046d)
Modalias: usb:v046DpB023d0015
Battery Percentage: 0x64 (100)
Output of bluetoothctl on Linux manjaro 5.15.12-1-MANJARO
[MX Master 3 Mac]# info
Device FC:01:23:BF:96:F7 (random)
Name: MX Master 3 Mac
Alias: MX Master 3 Mac
Appearance: 0x03c2
Icon: input-mouse
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00010000-0000-1000-8000-011f2000046d)
Modalias: usb:v046DpB023d0015
Battery Percentage: 0x64 (100)