You are not logged in.
After latest kernel and KDE update, my Microsoft bluetooth mouse no longer automatically reconnects upon resume from standby on my Lenovo T480s laptop if that standby was not only a few minutes (which leads me to the assumption that it may have to do with the mouse switching off at some point). If I connect it manually (e.g. through UI, using another mouse or using sudo bluetoothctl connect XX:XX:XX:XX:XX:XX) it works instantly after connecting and klicking once. Bluetooth is set to AutoEnable, and worked fine for monts before. No config change, just updates. I suspect KDE 5.19, or Kernel 5.7.2. Bluez is 5.54 and was last updated in April, so that's not the cause.
I did try bluetooth-autoconnect (AUR), enabled it as root with systemctl enable --now bluetooth-autoconnect. That connected my mouse immediately. Then I left root and pressed the power button. The system went to lock screen, did not suspend. Tried twice, no change. So I did systemctl suspend as user (THAT still worked), waited some seconds, pressed power to wake up system and moved/clicked the mouse: no connection. Since this was not better that without bluetooth-autoconnect, I stopped, disabled and uninstalled it. Suspend behavior is back to normal.
Also tried everything described in the Bluetooth Mouse Arch wiki troubleshooting section although they seemed only slightly related. None helped.
Sidenote: I noticed that my device ID changed each time I removed and reconnected it: One digit of the device ID incremented, so mind to copy the recent device ID!
I had an idea: Move or click the mouse prior to waking/resuming the laptop (with the power button, normal sleep mode aka standby, NOT hibernate/thaw). That seems to immediately connect the mouse in SOME cases.
I had another idea: Try a different mouse (of same type) to make sure it's not a harware issue. Turns out it isn't. BUT: One does NOT need to connect the proper DEVICE, but ANY device. I noticed since I reused a bash command from history:
$ bluetoothctl connect C3:9D:B9:D1:7D:BB
Attempting to connect to C3:9D:B9:D1:7D:BB
[CHG] Device C2:64:DF:6E:5C:A9 Connected: yes
[CHG] Device C2:64:DF:6E:5C:A9 ServicesResolved: yesNote: The first "mouse" is dev C3…, the "different mouse" is C2…, so upon trying to connect the (switched-off) mouse, it actually connects the (also paired) second one. So I tried with "scan on" in bluetoothctl – that works also, after some seconds.
Last edited by nursoda (2020-07-04 18:11:48)
Offline
Great, i'm not the only one encountering this.
I don't use KDE but XFCE, so i don't think it's related to this.
downgrading kernel to 5.6.13 solves the problem, which somehow makes me belive that it's related to bluez 5.53 / 5.54 http://www.bluez.org/release-of-bluez-5-54-and-5-53/ - which mentiones the following:
> Among new features are support for a blocked keys database, initial pieces for the Enhanced ATT bearer (EATT) from Bluetooth 5.2, a new just-works repairing policy (which requires the not-yet-released 5.7 kernel), and a new MTU auto-tuning option for AVDTP.
Maybe there's something which this "just-works" change breaks ... at least that's my suspicion for now.
Some more info:
i'm using bluetoothctl to manage the bluetooth connections - and it's been working fine until now.
Last edited by xmatthias (2020-06-22 11:53:02)
Offline
One thing i found today via btmon (running during sleep):
> HCI Event: Command Complete (0x0e) plen 4 #21 [hci0] 3805.930361
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Command Disallowed (0x0c)
The "disallowed" throws me off - the old kernel (5.6) did not show this - and the mouse did connect.
I think something must've changed in the kernel related to LE scanning - which prevents the mouse from connecting.
Yes, via bluetoothctl scan it's possible to connect the mouse - but it's a manual step which seems highly unnecessary (as it does work with a different kernel).
Offline
Maybe I can also use this thread to ask a question, I've enabled bluetooth.service through systectl, although, every time I boot into the system the bluetooth is off and I have to switch it on, off and then on again to have it working. It's pretty odd, can some of you suggest me a way to have it enabled as soon as the system starts?
Already did this with no luck
/etc/bluetooth/main.conf
[Policy]
AutoEnable=true
I'm using GNOME. Thank you!
edit: Doens't matter, this solved my problem
/etc/bluetooth/main.conf
[General]
DiscoverableTimeout = 0
Discoverable=true
Last edited by noreset (2020-07-14 14:56:25)
Offline
Hi @nursoda and @xmatthias
did you ever solve this problem I am suffering from this since a dew weeks and got as far as you.
Gregor
Offline
Hi Gregor, it works for me since a long while now – and unfortunately I don't remember whether I did something or whether it resolved itself (I think the latter). Sorry!
I have a different issue now that I also reported here but got no reaction. Since approx. 3 Months after a KDE and/or kernel update, my mouse scroll wheel direction is not properly reset: I use "inverse scolling" as with Macs … and it works after a clean reboot … until I go to standby and resume. After that, it's the default mouse wheel direction although the settings dialog says otherwise. If I set it to default and back to my setting "inverse", it works until next standby/resume. Any hits welcome.
Offline
Finally someone that also uses the "correct" way the mouse wheel should work ;-) I do the same but luckily this works for me (in gnome). In gnome this feature has the nicer name "natural scrolling".
Offline