Raspberry Pi | Bluetooth HID device reconnects slow

[DrCWO]

Creating a bug report/issue

Required Information

• DietPi version |
  -G_DIETPI_VERSION_CORE=8
  G_DIETPI_VERSION_SUB=10
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version |
  bullseye 0

• Kernel version |
  Linux rooExtend 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux

• SBC model |
  RPi 4 Model B (aarch64)

• Power supply used |
  5V 15W

• SD card used |
  SanDisk ultra

Additional Information (if applicable)

• Software title |
  bluez

• Can this issue be replicated on a fresh installation of DietPi?
  yes

Steps to reproduce

Please take a look at the Issue I opened in Github: bluez/bluez#466
I currently have no idea who's responsibility this is.
Support would be very welcome:-)

Expected behavior

Immediate availability of HID device after reconnection

Actual behavior

Take more than 2s that HID device is available after reconnection

Extra details

none

[MichaIng]

Many thanks for your report.

So it is a touch screen device attached via Bluetooth to an RPi to control stuff at the RPi, right?

Indeed very hard to say what is responsible, kernel, system libraries, bluez, system setup/settings, ...

First place to look for matching bug reports would be the Debian bug tracker: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=bluez

I see it works well with Linux 5.10 on a Buster system? Are you open to test with a more recent kernel version there, to see if it then slows down the same way?

apt install rpi-update
rpi-update

You could also run the same on the Bullseye system and see whether this helps.

And to test a more recent bluez, you could also test it with one of our Bookworm images: https://dietpi.com/downloads/images/

Also RPi firmware and kernel repos could be searched for matching issues:

• https://github.com/raspberrypi/firmware/issues
• https://github.com/raspberrypi/linux/issues

[DrCWO]

Hi @MichaIng,
great input :-)

I will start with updating the Raspberry system as you wrote and see if the issue also occurs there. In my eyes firmware cannot be the reason why as I use the same Pi4 and only swap the SD-Card.

I will be busy with a lot of other tasks the next two weeks so I expect I can work on this issue at the beginning of March.

So please leave this issue open I will come back with my findings.

Best DrCWO

[DrCWO]

I posted another issue in bluez for that:
bluez/bluez#663

[DrCWO]

Hi @MichaIng,
any idea how I might downgrade bluez at bullseye to from 5.55 to 5.5.0. I will do this to see if the issue persists.
Also it might be interesting to upgrade to a more recent release.

Best DrCWO

[DrCWO]

Hi @MichaIng,
today I tried to downgrade bluez from 5.55 to 5.50 as bluez 5.50 did not show the lag with Buster. This was not straight forward as no package is offered for that release. Here what I did:

cd ~
mkdir bluez
cd bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz
tar xvf bluez-5.50.tar.xz
cd bluez-5-50 
nano tools/rctest.c 
nano tools/l2test.c 
sudo apt-get update
sudo apt-get install -y libusb-dev libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev
./configure --enable-library
make

In this procedure you find two nano commands. In these .c files I had to add #include <linux/sockios.h> as a literal was missing. Without that make throws an error.
I did not nun make install as this would overwrite all my config files. Instead I did:

cp ./src/bluetoothd /usr/libexec/bluetooth/bluetoothd
cp ./client/bluetoothctl /usr/bin/bluetoothctl

I know this is a bad hack as dpkg still believes bluez is at 5.55 but I have no idea how to make a .deb to install ist properly.

In the end this solved the issue of slow reconnection and proves that bluez 5.55 causes this issue 👍 👍 👍 👍

Thanks for keeping the issue open for such along time but maybe my input helps others.

If you have the chance to add bluez 5.50 as a .deb to properly install it I will be very happy.

Best DrCWO

[MichaIng]

Would be interesting whether the same issue exists with bluez 5.66 on Bookworm.

Btw, as long as you did not replicate the issue with the latest upstream version, upstream devs won't have much motivation to look into it. Better report to the Debian bug tracker. But since current stable is Bookworm, it only makes sense if the Bookworm package is affected as well.

EDIT: Ah wait, the package is provided by the RPi repo, to correct place to report first is: https://github.com/RPi-Distro/repo/issues
But better test on official RPi OS first.

[DrCWO]

If I run dietpi-upgrade am I already on Bookworm? I saw a new kernel but still bluez 5.55?
What have I to do to get on Bookworm with bluez 5.66 using DietPi?

[Joulinar]

No, there is no dietpi-upgrade existing. And dietpi-update will not do any Destro upgrade. For this we created a different script. See https://dietpi.com/blog/?p=3128

[DrCWO]

If you like you can close this now.
Bluez 5.50 works now and all later releases have the slow reconnection issue.

[MichaIng]

So Bluez 5.66 from Bookworm is affected as well?

Just in case it is a kernel/driver issue in combination with newer Bluez, would be interesting whether the new kernel/firmware packages for RPi solve it: #6676

[DrCWO]

As my image did is not useable for Pi 5 I have to install all my things on your new Pi 5 release during the next months.
What I can offer is to test this with the Bluez delivered with this release before downgrading.
If you are interested in this please leave it open an I'll report back if I did the installation...

[MichaIng]

As my image did is not useable for Pi 5 I have to install all my things on your new Pi 5 release during the next months.

As said, you can update and migrate it, hence not necessarily need to install everything freshly. But have a backup of the whole image, at best, since the migration cannot be trivially reversed.

What I can offer is to test this with the Bluez delivered with this release before downgrading.
If you are interested in this please leave it open an I'll report back if I did the installation ...

If you go that route anyway, or find time for an upgrade (and in case downgrade) loop, that would be nice. I am still not sure where/how to report best, as I am not sure whether it more a kernel/driver issues with the RPi BT adapter, or Bluez, and if Bluez, upstream or Debian package/config. But if the latest version on Bookworm, or the new RPi kernel solve it, we would no longer have to rack our brains about it.

EDIT: In case, https://github.com/RPi-Distro/repo/issues really is best, re-reading my post above.

[MichaIng]

@DrCWO cycling through open issues, did you find time to give it a try?