Dear Luiz,
I now have another issue with remote control HID integration
(non-system; direct implementation).
I am using Java with d-bus BlueZ 5.55 on Debian Linux. I have "hid" and
"input" plugin disabled on bluetooth startup.
I have one remote integrated and working. With this one after boot and
while application startup I iterate over all paired devices with
existing HID service (check for existing service UUID) and then iterate
all Report characteristics and enabling notifying for all of them (if
supported). Everything is running well with this (legacy) remote. After
pairing it also auto-connects using my own registered object manager, as
suggested by you.
Now we received our final custom remote control from our manufacturer
(other chip) and this approach does not work any more. I have tried a
lot of things now. Once the remote control is paired (which is also
somehow still buggy) and I rebooted the system with our application, the
device is found in the list as paired, BUT I cannot access the HID
service any more. Therefore, I cannot enable notifying for this remote.
What I realized is, that this remote control seems to have something
like MAC address randomization enabled (probably for security reasons).
It also does not propagate device information unless I start pairing
mode. Because of MAC address randomization it also seems that pairing is
buggy - only works sometimes with some special procedure.
I know this remote works, because if I connected in manually via
bluetoothctl sometimes I works with enabling of notifying. Also directly
after pairing it seemed to work.
Have you seen something like this before? What should I do?
Thanks,
Martin
Am 09.02.23 um 10:18 schrieb Martin Petzold:
Hi Luiz,
Am 01.02.23 um 22:37 schrieb Luiz Augusto von Dentz:
Hi Martin,
On Wed, Feb 1, 2023 at 1:25 PM Martin Petzold
<martin.petzold@xxxxxxxx> wrote:
Hi,
Linux 5.10, BlueZ 5.55
I have a remote control which implements Bluetooth LE. If I use the
default Bluetooth daemon, I am able to pair and trust using
bluetoothctl. If the connection is lost after a while (or days) and a
button on the remote control is pressed, the daemon re-connects
automatically (because the device is paired). This is basically what
I need.
But, I would also like to manually set notifying for characteristics
(Report) on the HID service within my application (Java via d-bus).
This
is not possible anymore (also not via bluetoothctl) because the "hog"
(or "input") plugin manages the input device and the related HID
services are now hidden.
I then added "--noplugin=input,hog" to my Bluetooth daemon. Which is
okay, because I don't need this support for Kernel HID. Great, now the
HID services are available (also using bluetoothctl), but the
peripheral
does not re-connect automatically any more. I always have to connect
manually first. I also have no signal on the d-bus when I press the
button of the remote control, when it is disconnected.
How can I enable automatic re-connect for devices, when these plugins
are disabled?
The only other way I was thinking of is to leave the "hog" plugin
enabled and use the operating system HID interface. However, my
application runs as non-root which makes it complicated and also I
would
like to have direct connection and control to my device.
https://github.com/bluez/bluez/blob/master/doc/gatt-api.txt#L390
Thanks, I have implemented and registered the HID profile using
org.bluez.GattProfile1 and now the device (remote control) re-connects
automatically.
However, when I enable notifying on the Report characteristics of the
HID service after I received the first device properties update (with
services resolved), I miss the first Report event. If I press a
button, the remote re-connects and dbus events for device properties
updated are fine, but I don't have a Report event. If I then press
again, I do get a Report event, because I set notifying on the Report
characteristics. Setting notify seems to be too late.
What is the trick to get also the first button pressed as a Report
characteristic event?
At the moment I only have the HID service
(00001812-0000-1000-8000-00805f9b34fb) in the properties map of the
org.bluez.GattProfile1.
Thanks,
Martin
