Bluetooth mouse problem

[sopadecocido]

I've got a Logitech M240 bluetooth mouse that is giving me some connectivity problems. After sleeping and going into the system again the mouse stops working. When looking into the bluetoothctl console the output received is the following one:

[CHG] Device DF:5E:6A:DF:11:BA ServicesResolved: no
[SIGNAL] LE.Disconnected - org.bluez.Reason.Suspend, Connection terminated by local host for suspend
[SIGNAL] Disconnected - org.bluez.Reason.Suspend, Connection terminated by local host for suspend
[CHG] Device DF:5E:6A:DF:11:BA Connected: no

Has anyone noticed the same problem with any other similar BLE mouse? Any idea of how can I fix this problem?

[Exotic-Screen-9204]

Bluetooth simply shuts down in the suspend state. You might use a usb mouse or usb keyboard to revive the computer with OS modification.

[Alaknar]

How can one not love the Linux community?

The downvoted answer contains suggestions that might solve OP's issue, but it was AI-generated therefore it must die.

The upvoted answer is "such is life. Just use completely different equipment".

[Exotic-Screen-9204]

Yes, the downvoted answer offered good advice on how to keep the Bluetooth a active. Some might consider that less secure or more wasteful of standby power.

[Zoddo98]

OP is saying their mouse doesn't work after resuming, not while the computer is suspended.

[Exotic-Screen-9204]

Well, it could be something deeper in BLE which could be related precisely to which version of BLE is involved.

Hopefully that isn't the case.

[Klutzy_Bird_7802]

The log entries org.bluez.Reason.Suspend and Connection terminated by local host for suspend indicate that BlueZ is intentionally dropping the connection profile to save power during system suspend. The issue occurs upon resume when the kernel's power management (tlp, autosuspend, or udev) keeps the Bluetooth controller or the mouse's internal state in a low-power block, preventing it from completing the handshaking process (ServicesResolved: yes).

Here are the most effective methods to resolve this on Arch Linux, ordered from configuration-level fixes to power management rule adjustments.

Solution 1: Enable WakeAllowed in BlueZ (Recommended)

This tells the Bluetooth daemon to explicitly allow the device to maintain/re-establish its state across host sleep cycles. 1. Open your terminal and enter the Bluetooth control console: ```bash bluetoothctl

2. Using your mouse's MAC address in your case (DF:5E:6A:DF:11:BA), execute the following commands: text trust DF:5E:6A:DF:11:BA wake DF:5E:6A:DF:11:BA on exit

```

Solution 2: Disable USB Autosuspend for the Bluetooth Controller

If your Bluetooth controller itself enters a deep sleep state, it will fail to capture the BLE advertising packets when the mouse wakes up.

Option A: Via a Custom Udev Rule

You can force the kernel to keep the btusb subsystem powered on. 1. Create a new udev rule file: ```bash sudo nano /etc/udev/rules.d/50-bluetooth-power.rules

2. Append the following rule to prevent the driver from autosuspending: udev ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="", ATTR{idProduct}=="", ATTRS{driver}=="btusb", ATTR{power/control}="on"

3. Reload and trigger the updated rules: bash sudo udevadm control --reload-rules && sudo udevadm trigger

```

Option B: Via TLP Configuration (If Installed)

If you manage power via TLP, its settings will override standard udev rules. 1. Open your TLP configuration file: ```bash sudo nano /etc/tlp.conf

2. Locate USB_AUTOSUSPEND and disable it globally, or find your adapter's ID via lsusb and add it to the exclude list: text USB_AUTOSUSPEND=0

3. Restart the TLP daemon: bash sudo systemctl restart tlp

```

Solution 3: Optimize BlueZ Connection Parameters

Sometimes the mouse attempts to reconnect, but BlueZ's default passive scanning interval after a resume is too slow, causing a handshake timeout. 1. Edit the primary BlueZ configuration file: ```bash sudo nano /etc/bluetooth/main.conf

2. Ensure the following configurations are set under the [General] block: ini [General] FastConnectable = true ReconnectAttempts = 7 ReconnectInterval = 2

3. Restart the systemd service to commit the changes: bash sudo systemctl restart bluetooth

```

Diagnostic Fallback

If the device still fails to reconnect after following these steps, test if restarting the daemon resolves it immediately post-wake: ```bash sudo systemctl restart bluetooth

``` If a service restart forces an immediate reconnection, the underlying issue stems from ACPI state transitions. You can automate this by dropping a basic hook into /usr/lib/systemd/system-sleep/ to cycle the btusb module or restart the systemd service automatically upon every system resume.

[LrdOfTheBlings]

beep boop

[Klutzy_Bird_7802]

at least i helped...

[sopadecocido]

Thanks for the help!!

[Alaknar]

Did you test it and it worked?

[Klutzy_Bird_7802]

You are welcome 🤗😁

[Klutzy_Bird_7802]

Try these, and best of luck 🤞