Created attachment 275475 [details]
Trace of a pairing/connection attempt created with btmon
I'm unable to use my new Microsoft Surface Precision Mouse(https://www.microsoft.com/en-us/surface/accessories/surface-precision-mouse) on any of my available systems.
The following example is based of my desktop system:
hci0: Type: Primary Bus: USB
BD Address: 00:01:95:3F:C8:4A ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:8980 acl:60 sco:0 events:677 errors:0
TX bytes:8705 acl:51 sco:0 commands:483 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Service Classes: Rendering, Capturing, Object Transfer
Device Class: Computer, Desktop workstation
HCI Version: 4.0 (0x6) Revision: 0x2031
LMP Version: 4.0 (0x6) Subversion: 0x2031
Manufacturer: Cambridge Silicon Radio (10)
Bus 003 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Please let me know if you need additional information. Thx.
Created attachment 275477 [details]
Text version of the pairing/connection trace
So this is interesting issue as this mouse is using ID address during initial connection but distributes IRK key with different ID address (well, address is same, but address type is different, public instead of static random).
This is causing clash on creating new object as (for historical reasons) BlueZ doesn't use address type in object path.
Also, since this is undefined behavior from mouse (as it should use same ID address in connection and key distribution) to workaround this we would have to verify which address will mouse use after pairing. My guess is that it will use static random and that address type in IRK is bogus (bug in mouse).
I'll try to prepare testing patch later this week.
BTW you should report this issue to mouse manufacturer as well.
I'd just like to ask if there is any update on this. Is there anything you would like me to test?
I got the same mouse as a present and are having the same problem that I can't use it on my Ubuntu Linux because of this issue.
Is there anything we can do to help to get let Bluez support the Microsoft Surface Precision Mouse?
Is there still something I can do to help with progress on solving this issue? I'd really like to use my mouse without the USB cable...
Proposed fix https://marc.info/?l=linux-bluetooth&m=156089812329480&w=2
thanks a lot for your effort! I've applied your patch on top of kernel 5.1.11 and I can confirm the mouse is working now.
The only downside I've noticed so far is that the scroll wheel stopped working after 1-2h of usage.
the scroll wheel that stops working is not related to Bluetooth.
I experienced the very same issue with the scroll wheel when using the mouse via USB. This happened since the upgrade to Ubuntu 19.04 and I think it is related to the desktop environment. It seems to be sometimes triggered by lock screen or suspend (but not 100% reproducible). Reconnecting the USB (or reconnecting via bluetooth) lets the desktop re-initialize the mouse and resolves the scroll wheel issue.
You may also check if https://www.spinics.net/lists/linux-bluetooth/msg80344.html fixes scroll issue
I've patched bluez according to your link and after some hours of usage I couldn't reproduce the scroll wheel issue. So on my primary device (laptop) everything works!
Unfortunately on my desktop system I've another issue, again this could be entirely unrelated:
After applying the kernel patch (and in anticipation the bluez patch) on my desktop system, the pairing process also went smoothly.
The mouse is shown as paired and connected according to the KDE plasma UI tools, but apparently the mouse is not detected by the input system.
Dmesg only shows warning added by the patch and not any of the following input stuff (taken from my laptop):
[ 7.973258] input: BTLE Precision Mouse as /devices/virtual/misc/uhid/0005:045E:0821.0004/input/input19
[ 7.973526] input: BTLE Precision Mouse Keyboard as /devices/virtual/misc/uhid/0005:045E:0821.0004/input/input20
[ 7.973646] input: BTLE Precision Mouse Consumer Control as /devices/virtual/misc/uhid/0005:045E:0821.0004/input/input21
[ 7.973697] input: BTLE Precision Mouse as /devices/virtual/misc/uhid/0005:045E:0821.0004/input/input22
[ 7.973746] input: BTLE Precision Mouse as /devices/virtual/misc/uhid/0005:045E:0821.0004/input/input23
[ 7.973819] hid-generic 0005:045E:0821.0004: input,hidraw3: BLUETOOTH HID v1.05 Mouse [BTLE Precision Mouse] on XX:XX:XX:XX:XX:XX
What could I missing out?
Ok, I compared the kernel configs between the working and non-working systems, it seems like the kernel config entry CONFIG_UHID (User-space I/O driver support for HID subsystem) was missing.
Everything is running fine now. I hope both patches are picked up in their following release.
Kernel patch is merged into bluetooth-next and is on its way to linus tree. It is also marked as stable candidate.
Mentioned scroll issue fix is now also merged into bluez tree.
I think this bug can be now closed.
Thank you Szymon!
A small question about when we can expect a new Bluez release. Last one is from a year ago and it would be great to get all fixes of last year into Linux distributions.
I am also wondering when can I get the fixes... I ave both issues, the mouse not pairing and the mouse wheel issue when paired using a workaround.
I am running elementary juno with kernel 5.3.8-050308-generic
The BlueZ fix is released in version 5.51.