Mouse disappears after disconnect

[peteruithoven]

trafficstars

Normally devices that are paired but not connected are listed under "Paired Devices". Example:

For some reason though my mouse (Logitech M720 Triathlon) disappears completely when I turn it off or press the disconnect button. I need to reopen the bluetooth settings for it to be listed again as Not connected.

Below a screenshot of the following steps:

1. Turning mouse off.
2. You see the mouse disappear from the list
3. I close and reopen the bluetooth settings
4. The mouse is listed as Not connected.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[peteruithoven]

I'm seeing the same behavior with my Logi R500. The issue also happens when pressing disconnect (instead of turning off the device).

The System settings need to be closed completly for these bluetooth devices to appear again.

[peteruithoven]

I'm testing this with a mouse (where the device disappears from the list) and headphones (where their state simply switches to disconnected). Looks like in both cases in the Manager remove_path is called.

• The following path for the mouse:
  • /org/bluez/hci0/dev_D8_2F_80_B9_15_59
• The following paths for the headphones:
  • /org/bluez/hci0/dev_2C_41_A1_E8_2E_1F/player0
  • /org/bluez/hci0/dev_2C_41_A1_E8_2E_1F/fd9

So it looks like in the case of the mouse the whole device disappears and in case of the headphones some kind of subpaths.

Simply not removing the device when this method is called doesn't work because when you un-pair (by selecting it in the list and pressing the remove button) the same method is called, although it then removed a lot of subpaths as well:

remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service0008/char0009/desc000b
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service0008/char0009
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service0008
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char000d
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char000f
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char0011
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char0013
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char0015
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char0017
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c/char0019
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service000c
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service003e/char003f/desc0041
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service003e/char003f
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A/service003e
remove_path: /org/bluez/hci0/dev_D8_2F_80_B9_15_5A

[peteruithoven]

@tintou I noticed you've written this aspect of the Bluetooth.Services.ObjectManager, do you have ideas on how we could better handle this?