Bug 204585 - Bluetooth Mouse Polling Rate Regressed to 20hz
Summary: Bluetooth Mouse Polling Rate Regressed to 20hz
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL: https://bbs.archlinux.org/viewtopic.p...
Keywords: trivial
Depends on:
Blocks:
 
Reported: 2019-08-14 18:22 UTC by Ivan Svalov
Modified: 2022-02-20 23:54 UTC (History)
5 users (show)

See Also:
Kernel Version: Linux arch 5.2.8-arch1-1-ARCH
Subsystem:
Regression: No
Bisected commit-id:


Attachments
pairing issue capture (7.61 KB, application/x-pcapng)
2019-09-12 12:47 UTC, Pavel
Details

Description Ivan Svalov 2019-08-14 18:22:59 UTC
The problem arose with Microsoft BluetoothMouse3600. When you turn on the mouse behaves sluggishly. The evhz utility shows a polling rate of 20Hz. The problem is solved by changing the max and min values of the connection.

/usr/bin/hcitool con | grep " handle " | awk '{print $5}' | xargs -I {} /usr/bin/hcitool lecup --handle {}  --min 6 --max 7 --latency 0

Maybe you should change the default value of conn_min_interval and conn_max_interval.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/bluetooth?h=v5.2.8&id=33401f6ba0d9f23ca5877540375b88d7cd5b1f8f
Comment 1 Leif Liddy 2019-09-08 11:56:02 UTC
I'm seeing this exact same issue with an orochi (2015) mouse on my laptop running kernel 5.2.11
What'd odd is that this issue isn't present when using this mouse on my other laptop running the same distro + kernel (but different bluetooth chipset).

Not sure when this issue started exactly, but it was either kernel 5.1.x or 5.2.x.  

The stated hcitool command solves the issue for me. Since hcitool is deprecated, what is the 'proper' method we're meant to use to implement this change?

I'm not able to change the polling intervals via debugfs as conn_min_interval and conn_max_interval don't exist

# find /sys/kernel/debug/bluetooth/hci0 -type f 
/sys/kernel/debug/bluetooth/hci0/le_max_key_size
/sys/kernel/debug/bluetooth/hci0/le_min_key_size
/sys/kernel/debug/bluetooth/hci0/vendor_diag
/sys/kernel/debug/bluetooth/hci0/dut_mode
Comment 2 Leif Liddy 2019-09-08 13:27:05 UTC
Looks like that patch is getting reverted:
https://www.spinics.net/lists/linux-bluetooth/msg81251.html
Comment 4 Pavel 2019-09-12 12:47:19 UTC
Created attachment 284937 [details]
pairing issue capture

I am experiencing pairing issues after reversal
Comment 5 Pavel 2019-09-12 12:53:06 UTC
My device is rapoo 550 made on MXCHIP btle chipset
Comment 6 Pavel 2019-09-14 13:17:32 UTC
Guys on https://bbs.archlinux.org/viewtopic.php?id=248133 clearly singled out the issue as a matter of changes in default settings and conn_min_interval
Comment 7 Ivan Svalov 2019-09-17 13:22:27 UTC
Applying a patch https://www.spinics.net/lists/linux-bluetooth/msg81235.html solves a problem with my mouse. Kernel 5.2.15
Comment 8 Leif Liddy 2019-09-24 11:53:37 UTC
This is only a temporary solution (until commit c49a8682fc5d gets reverted). If you read the very next message in that email chain:
https://www.spinics.net/lists/linux-bluetooth/msg81251.html

The subsystem maintainer, Marcel Holtmann replies to the proposed change:
"I decided to revert c49a8682fc5d and we need an overall better solution for handling connection parameters"
Comment 9 Sar 2019-11-06 15:53:58 UTC
The problem is still here on kernel 5.3.0-19-generic

I discovered it with my Logitech M535 bluetooth mouse.

The workaround (overriding /sys/kernel/debug/bluetooth/hci0/conn_min_interval and conn_max_interval) works.

Note You need to log in before you can comment on or make changes to this bug.