Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

vivitron · 2019-08-01 13:01:09

Recently I've had issues with my mouse MX Ergo having high latency... you can feel the sluggish movement across the screen. Using a usb dongle, everything is fine.

I was finally able to resolve by changing the latency, min, max connection intervals with hcitool like so:

export MOUSEHANDLE=`hcitool con  | grep "E1:95:80:B8:2F:31" | awk '{print $5}'`
hcitool lecup --handle $MOUSEHANDLE --min 6 --max 7 --latency 0

I'm currently running this each time the mouse connects, but this seems wrong.

What is the proper method of configuring the default intervals and latency? Is it possible to put in a permanent configuration for this device without running a script?

Appreciate any insights.

vivitron · 2019-08-02 13:30:38

I wouldn't consider this solved, but I have bandaided the situation. I understand hcitool is depreciated. I researched all the new bluetooth tools (bluetoothctl, btmgmt) and explored /sys; I do not see a method to set latency / min interval / max interval. There are two files at /sys/kernel/debug/bluetooth/hci0/conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval that are writable, but I could never get it to physically do anything. I've set them pre connection & post connection to no avail.

I decided to setup a udev rule to run the hcitool command. Unexplainibly, the hcitool cannot detect or control any bluetooth devices when run from a udev rule. There are no errors; I tried everything I could, but never could get it to work. I'm not the only one who has experienced this. As this user did, I attempt to put in sleeps, interactive terminals, reviewed env vars and replicated. Nothing worked.

At the end of the day, I setup a udev rule that simply writes a file to /tmp/. Another process uses inotifywait to then trigger the hcitool call on demand. This is ugly, but I'm out of ideas. I've read that you can control bluetooth through dbus, but that is for people smarter than myself.

My udev rule:

SUBSYSTEM=="bluetooth", ACTION=="add", RUN+="/usr/local/sbin/signalBluetooth.sh"

Within 1-2 seconds, the inotifywait/watch runs a fixBluetoothLatency.sh script. It changes the latency/min/max interval for all bluetooth devices. This works for me, but may not for everyone.

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

I hope this helps someone. It's been fun trying to solve a 100ms lag on this mouse.

Last edited by vivitron (2019-08-02 13:42:41)

Busata · 2019-08-05 21:19:23

echo 0 > /sys/kernel/debug/bluetooth/hci0/conn_latency
echo 6 > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
echo 7 > /sys/kernel/debug/bluetooth/hci0/conn/max_interval

not sure what other consequences there are, but these commands seem to survive the mouse disconnects (but not reboots)

Thanks a lot for this post though, finally solved the mx ergo issues.

I've just added this to a script & set it to run @reboot with crontab, always open for better suggestions

Last edited by Busata (2019-08-05 21:40:42)

vivitron · 2019-08-06 13:22:13

For some reason, setting /sys/kernel/debug/bluetooth/hci0/conn_* has no effect on my system. I attempted to reset it prior to connecting any devices and I also tried turning bluetooth on/off after setting it. The latency persists no matter what.

Using hcitool to set the three values solves the issues on my machine. I'm guessing this is something to do with the hardware configuration.

lspci -knn | grep Net -A2; lsusb

00:14.3 Network controller [0280]: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] [8086:9df0] (rev 11)
	Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] [8086:0030]
	Kernel driver in use: iwlwifi
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 06cb:00a2 Synaptics, Inc. 
Bus 001 Device 003: ID 056a:5159 Wacom Co., Ltd 
Bus 001 Device 002: ID 04ca:7070 Lite-On Technology Corp. 
Bus 001 Device 008: ID 0bda:8152 Realtek Semiconductor Corp. RTL8152 Fast Ethernet Adapter
Bus 001 Device 006: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 005: ID 8087:0aaa Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

ohhskar · 2019-08-06 15:23:16

I tried both setting /sys/kernel/debug/bluetooth/hci0/conn_* and I had some weird effects. The first time i tried setting it, it worked, however the following times I tried it did not Setting it through hcitool worked reliably.

I dont think that it has something to do with the hardware configuration. I ran lspci -knn | grep Net -A2; lsusb and this is what I got:

02:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32)
	Subsystem: Bigfoot Networks, Inc. Killer 1435 Wireless-AC [1a56:143a]
	Kernel driver in use: ath10k_pci
	Kernel modules: ath10k_pci
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID feed:6464  
Bus 001 Device 003: ID 0489:e0a2 Foxconn / Hon Hai 
Bus 001 Device 002: ID 0c45:6723 Microdia 
Bus 001 Device 005: ID 27c6:5385  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

we have different wireless cards, but we are experiencing the same issue

ingolfured · 2019-08-07 19:05:24

I'm having the same issue. Using evhz, I'm getting

Dell WM527 Mouse: Latest    20Hz, Average    17Hz
Dell WM527 Mouse: Latest    20Hz, Average    17Hz

and

lspci -knn | grep Net -A2; lsusb

3b:00.0 Network controller [0280]: Intel Corporation Device [8086:2723] (rev 1a)
	Subsystem: Bigfoot Networks, Inc. Device [1a56:1654]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 27c6:5395  
Bus 001 Device 003: ID 8087:0029 Intel Corp. 
Bus 001 Device 005: ID 0c45:6723 Microdia 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Running

echo 0 > /sys/kernel/debug/bluetooth/hci0/conn_latency
echo 6 > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
echo 7 > /sys/kernel/debug/bluetooth/hci0/conn_max_interval

Doesn't help at all. Still getting the same output from evhz. However, if I use the USB dongle atm, everything is fine. Any ideas of how I could debug it further?

Last edited by ingolfured (2019-08-07 19:11:21)

pablox · 2019-08-12 01:13:27

Hey vivitron, I had the same issue. It started to happened after my last "big" update, I'm guess it had to do with the linux package, but I'm not sure. I posted the full update list in case someone can make something else:

https://gist.github.com/pablox-cl/e3fda … 2db5d6653b

Setting /sys/kernel.... didin't work for me either, but the hcitool helped. I'm gonna add your udev solution as a workaround until we have news about what happened.

worryag · 2019-08-13 17:44:42

Same issues with Microsoft BluetoothMouse3600. Only solution with hcitool helps. Alternatively, changing the default values when connecting.
[https://git.kernel.org/pub/scm/linux/ke … d7cd5b1f8f]
[https://git.kernel.org/pub/scm/linux/ke … 5214a25429]

Last edited by worryag (2019-08-13 18:14:06)

beanaroo · 2019-08-13 23:12:02

Thank you for this workaround! I'm experiencing the same issue with a Logitech MX Master.

Strangely, I noticed this as soon as I rebooted after removing the contents of `/var/lib/bluetooth/[ADAPTER]/*` in an attempt to clear the cache. The difference was so bad, it led me to find this post and the proposed hci workaround has the desired effect.

Could there have been an attribute/setting in `/var/lib/bluetooth` relating to my mouse / adapter? In which case there could be a permanent solution.

@worrywag linked a recent commit. Is this the suspected breaking change?

Last edited by beanaroo (2019-08-13 23:20:29)

peter.berg · 2019-08-14 05:20:47

I've the same Problem with my Logitech M590 BLE Mouse. To Workaround the problem I've written an script, which monitors the dbus for connection change and exec the hcitool command on connect.

#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_D4_C7_5F_2F_F7_63

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true" && /usr/bin/hcitool lecup --handle 64 --min 6 --max 7 --latency 0
done

Script is startet through a systemd service with type simple. After dbus and bluetooth of course

worryag · 2019-08-14 09:21:16

beanaroo wrote:

Thank you for this workaround! I'm experiencing the same issue with a Logitech MX Master.
Strangely, I noticed this as soon as I rebooted after removing the contents of `/var/lib/bluetooth/[ADAPTER]/*` in an attempt to clear the cache. The difference was so bad, it led me to find this post and the proposed hci workaround has the desired effect.
Could there have been an attribute/setting in `/var/lib/bluetooth` relating to my mouse / adapter? In which case there could be a permanent solution.
@worrywag linked a recent commit. Is this the suspected breaking change?

I think yes. At least the author of the patch wrote about something similar to our case.

The one downside that I see is that the current default Linux values for
conn_min_interval and conn_max_interval typically correspond to 30ms and
50ms respectively. If this change were accepted, then it is feasible that
some devices would no longer be able to negotiate to their desired
connection interval values. This might be remedied by setting the default
Linux conn_min_interval and conn_max_interval values to the widest
supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
behavior as the current implementation, where the remote device could
request to change the connection interval value to any value that is
permitted by the Bluetooth specification, and Linux would accept the
desired value.

rafaelgov95 · 2019-08-14 12:50:56

vivitron wrote:

Recently I've had issues with my mouse MX Ergo having high latency... you can feel the sluggish movement across the screen. Using a usb dongle, everything is fine.
I was finally able to resolve by changing the latency, min, max connection intervals with hcitool like so:
export MOUSEHANDLE=`hcitool con  | grep "E1:95:80:B8:2F:31" | awk '{print $5}'`
hcitool lecup --handle $MOUSEHANDLE --min 6 --max 7 --latency 0
I'm currently running this each time the mouse connects, but this seems wrong.
What is the proper method of configuring the default intervals and latency? Is it possible to put in a permanent configuration for this device without running a script?
Appreciate any insights.

The my Mouse Dell also had this problem. Thanks for the temporary solution.

pablox · 2019-08-14 22:39:39

peter.berg wrote:

I've the same Problem with my Logitech M590 BLE Mouse. To Workaround the problem I've written an script, which monitors the dbus for connection change and exec the hcitool command on connect.
#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_D4_C7_5F_2F_F7_63

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true" && /usr/bin/hcitool lecup --handle 64 --min 6 --max 7 --latency 0
done
Script is startet through a systemd service with type simple. After dbus and bluetooth of course

Can you share the systemd service too?

beanaroo wrote:

Thank you for this workaround! I'm experiencing the same issue with a Logitech MX Master.

Same mouse here, and same problem =/

peter.berg · 2019-08-15 17:14:08

# /etc/systemd/system/m590.service
[Unit]
Description=M590 Service

[Service]
Type=simple
ExecStart=/usr/local/bin/dbus-watcher-ble-mouse.sh &

[Install]
Require=dbus.service
After=bluetooth.target
WantedBy=multi-user.target

Of course you've to insert the correct values for your specific hardware into the script.

famz · 2019-08-19 04:21:35

beanaroo wrote:

Thank you for this workaround! I'm experiencing the same issue with a Logitech MX Master.
Strangely, I noticed this as soon as I rebooted after removing the contents of `/var/lib/bluetooth/[ADAPTER]/*` in an attempt to clear the cache. The difference was so bad, it led me to find this post and the proposed hci workaround has the desired effect.
Could there have been an attribute/setting in `/var/lib/bluetooth` relating to my mouse / adapter? In which case there could be a permanent solution.
@worrywag linked a recent commit. Is this the suspected breaking change?

Yes, reverting this bummer perfectly fixes the mouse lag for me.

rafaelgov95 · 2019-08-20 04:10:51

peter.berg wrote:

I've the same Problem with my Logitech M590 BLE Mouse. To Workaround the problem I've written an script, which monitors the dbus for connection change and exec the hcitool command on connect.
#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_D4_C7_5F_2F_F7_63

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true" && /usr/bin/hcitool lecup --handle 64 --min 6 --max 7 --latency 0
done
Script is startet through a systemd service with type simple. After dbus and bluetooth of course

I made it a modification to get the auto handle!

#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_C7_49_8A_FF_7C_EF

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true"  &&   /usr/bin/hcitool lecup --handle `/usr/bin/hcitool con  | /usr/bin/grep "C7:49:8A:FF:7C:EF" | /usr/bin/awk '{print $5}'` --min 6 --max 7 --latency 0
done

eskiya · 2019-08-20 13:37:41

I confirm that this bug is introduced in the latest kernel update 5.2.8. Rolling back to 5.1.11 fixes it.

pablox · 2019-08-22 02:29:21

eskiya wrote:

I confirm that this bug is introduced in the latest kernel update 5.2.8. Rolling back to 5.1.11 fixes it.

Hm, I rolled back to 5.2.5 and it's okay, problem started with 5.2.7 (I updated from 5.2.5 → 5.2.7; so I dunno if the problem were somewhere between).

EDIT: corrected guilty? kernel version

Last edited by pablox (2019-08-22 23:12:41)

worryag · 2019-08-22 17:40:32

Funny, on 5.2.9 my problems disappeared.

pablox · 2019-08-22 23:12:04

Wow, this is so confusing. I update again to 5.2.9 and the problem is gone. I don't have any udev rules nor systemd service.

worryag wrote:

Funny, on 5.2.9 my problems disappeared.

I meant 5.2.7, sorry.

CesarPantoja · 2019-08-29 09:54:17

rafaelgov95 wrote:

peter.berg wrote:
I've the same Problem with my Logitech M590 BLE Mouse. To Workaround the problem I've written an script, which monitors the dbus for connection change and exec the hcitool command on connect.
#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_D4_C7_5F_2F_F7_63

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true" && /usr/bin/hcitool lecup --handle 64 --min 6 --max 7 --latency 0
done
Script is startet through a systemd service with type simple. After dbus and bluetooth of course
I made it a modification to get the auto handle!
#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_C7_49_8A_FF_7C_EF

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    echo $line | /usr/bin/grep "boolean true"  &&   /usr/bin/hcitool lecup --handle `/usr/bin/hcitool con  | /usr/bin/grep "C7:49:8A:FF:7C:EF" | /usr/bin/awk '{print $5}'` --min 6 --max 7 --latency 0
done

Had to change my script to get the handle in another line to make it work:

#!/bin/bash

INTERFACE=org.freedesktop.DBus.Properties
MEMBER=PropertiesChanged
PATH=/org/bluez/hci0/dev_D7_00_70_8B_AA_00

/usr/bin/dbus-monitor --system "path='$PATH',interface='$INTERFACE',member='$MEMBER'" |
while read -r line; do
    HANDLE=`/usr/bin/hcitool con  | /usr/bin/grep "D7:00:70:8B:AA:00" | /usr/bin/awk '{print $5}'`
    echo $line | /usr/bin/grep "boolean true" && /usr/bin/hcitool lecup --handle $HANDLE --min 6 --max 7 --latency 0
done

Stellarator · 2019-08-29 19:39:10

Colleagues, one lonely soul reminded me today of an annoying problem. So I dug out my MX Master to make sure there was a problem.

Well ... I'm here to propose a different solution. I think the key point that many of you missed is hidden in #9 post by @beanaroo (check the second paragraph). This (and previous) post also mentioned the suspicious commit. So we can try to chat with the author of the work. But I assume that there were some reasons to change the logic, so for now let’s leave this point.

OK, step by step:

I assume that no connections are made/paired/stored in /var/lib/bluetooth
Temporary remove all hacks/whatever described in this thread
Reboot
Your /sys/kernel/debug/bluetooth/hci0/conn_* parameters should (be restored to) look like (at the time of writing this [Linux 5.2.10]):
```
conn_latency: 0
conn_max_interval: 40
conn_min_interval: 24
```
# echo 6 > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
Pair/Trust/Connect as usual
That's it!

Now look in /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/ZZ:ZZ:ZZ:ZZ:ZZ:ZZ/info file. It should contain interesting section:

...
[ConnectionParameters]
MinInterval=6
MaxInterval=9
Latency=44
Timeout=216
...

This is info from my notebook (with Intel(R) Centrino(R) Advanced-N 6235 controller and MX Master mentioned above). I assume that your numbers may differ or there may not be the section at all.

If section is present and value of MinInterval=X is 6..10 you're lucky. Don't forget about multiplier (1.25), so in case of 6 your maximal polling rate will not exceed ~133Hz (1000/7.5). Other numbers are interesting too. And it looks like my mouse probably works under MaxInterval=Y condition mostly (~90Hz). BUT, as you can guess - these numbers can be adjusted for your needs! Like 6/7 combination mentioned above.

More importantly, you DON'T need to restore /sys/kernel/debug/bluetooth/hci0/conn_min_interval value every time on reboot/suspend or do other hacks! Mouse should connect with parameters mentioned in [ConnectionParameters] section regardless of other settings.

If the section did not appear, well, try adding it by hand.

I also guess that original paired values are more or less optimized for energy saving (I could be wrong here). Therefore, if energy saving is a priority - just leave them alone...

Stellarator · 2019-08-29 19:50:59

As a side note: I'm using https://aur.archlinux.org/packages/bluez-git to cover outstanding issue with "A2DP sink profile is unavailable". But I'm pretty sure it doesn't matter because the root problem is hidden inside kernel module(s) / settings.

Temet · 2019-08-29 20:12:18

Thank you Stellarator.
That worked for me.
I removed the folder corresponding to my mouse in /var/lib/bluetooth otherwise it was not working (you mentionned it in step 1, but I just tried the echo thing and pairing )

On my side, the info file generated has Min and Max interval both to 6.

hoome · 2019-08-30 22:01:47

Stellarator wrote:

Colleagues, one lonely soul reminded me today of an annoying problem. So I dug out my MX Master to make sure there was a problem.
Well ... I'm here to propose a different solution. I think the key point that many of you missed is hidden in #9 post by @beanaroo (check the second paragraph). This (and previous) post also mentioned the suspicious commit. So we can try to chat with the author of the work. But I assume that there were some reasons to change the logic, so for now let’s leave this point.
OK, step by step:
I assume that no connections are made/paired/stored in /var/lib/bluetooth
Temporary remove all hacks/whatever described in this thread
Reboot
Your /sys/kernel/debug/bluetooth/hci0/conn_* parameters should (be restored to) look like (at the time of writing this [Linux 5.2.10]):
conn_latency: 0
conn_max_interval: 40
conn_min_interval: 24
# echo 6 > /sys/kernel/debug/bluetooth/hci0/conn_min_interval
Pair/Trust/Connect as usual
That's it!
Now look in /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/ZZ:ZZ:ZZ:ZZ:ZZ:ZZ/info file. It should contain interesting section:
...
[ConnectionParameters]
MinInterval=6
MaxInterval=9
Latency=44
Timeout=216
...
This is info from my notebook (with Intel(R) Centrino(R) Advanced-N 6235 controller and MX Master mentioned above). I assume that your numbers may differ or there may not be the section at all.
If section is present and value of MinInterval=X is 6..10 you're lucky. Don't forget about multiplier (1.25), so in case of 6 your maximal polling rate will not exceed ~133Hz (1000/7.5). Other numbers are interesting too. And it looks like my mouse probably works under MaxInterval=Y condition mostly (~90Hz). BUT, as you can guess - these numbers can be adjusted for your needs! Like 6/7 combination mentioned above.
More importantly, you DON'T need to restore /sys/kernel/debug/bluetooth/hci0/conn_min_interval value every time on reboot/suspend or do other hacks! Mouse should connect with parameters mentioned in [ConnectionParameters] section regardless of other settings.
If the section did not appear, well, try adding it by hand.
I also guess that original paired values are more or less optimized for energy saving (I could be wrong here). Therefore, if energy saving is a priority - just leave them alone...

This totally works for me. Thanks! Soo many thanks! The same issue with Linux 5.2.10 and evhz reporting 20hz polling rate.

After following this procedure in sequence worked flawless. And you need to unpair before because otherwise the `[ConnectionParameters]` wont show.

Last edited by hoome (2019-08-30 22:02:13)

Arch Linux

#1 2019-08-01 13:01:09

Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#2 2019-08-02 13:30:38

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#3 2019-08-05 21:19:23

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#4 2019-08-06 13:22:13

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#5 2019-08-06 15:23:16

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#6 2019-08-07 19:05:24

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#7 2019-08-12 01:13:27

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#8 2019-08-13 17:44:42

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#9 2019-08-13 23:12:02

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#10 2019-08-14 05:20:47

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#11 2019-08-14 09:21:16

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#12 2019-08-14 12:50:56

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#13 2019-08-14 22:39:39

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#14 2019-08-15 17:14:08

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#15 2019-08-19 04:21:35

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#16 2019-08-20 04:10:51

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#17 2019-08-20 13:37:41

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#18 2019-08-22 02:29:21

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#19 2019-08-22 17:40:32

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#20 2019-08-22 23:12:04

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#21 2019-08-29 09:54:17

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#22 2019-08-29 19:39:10

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#23 2019-08-29 19:50:59

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#24 2019-08-29 20:12:18

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

#25 2019-08-30 22:01:47

Re: Bluetooth mice latency/sluggish; Fixed by hcitool, permanent options?

Board footer