Get connection info from D-Bus API

[cschramm]

There are device properties for RSSI and Tx power now and link quality is pointless.

BlueZ 6 will drop (most of) libbluetooth in favor of the D-Bus API, so we will have to make that switch at some point.

Opposed to the libbluetooth getters, the D-Bus properties might or might not be set. In many cases (for LE devices) the libbluetooth functions return RSSI 255 and tx power 10 while the D-Bus properties are not set. I think it is better to not indicate any values in that case. However, that currently leaves us without a connection indicator in those cases (unless the battery API is provided) as the bars basically act as one.

[infirit]

I'll look into this properly later but.. The main problem I have with the RSSI property is that it only shows up when discovering. And then only for some devices. I wish they just made RSSI always available.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[cschramm]

The concept in #1620 would solve the problem that there is no connection info without those bars as it adds an explicit "connected" item to the right. Another option could be a connected emblem (that could override the paired emblem to not add another one).

[cschramm]

#1812 is an (unsatisfying) draft for option 2.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[cschramm]

Now that #1812 is in main, I'm curious to merge this and (maybe) get feedback on the new behavior from users of git-based packages.

[infirit]

The RSSI and TxPower properties are invalidated when not available anymore on the bus but we ignore this (see #620). It will require a rework of bluez/Base.py (stop subclassing Gio.DBusProxy basically) to handle invalidated properties. Or just clear these when Discovering is False.

edit: Quick hack https://gist.github.com/infirit/b9409c9e8108535b374f3cd6bf2ea72e

[cschramm]

Looks like this currently breaks all bars, even battery. :see_no_evil: I'll have another try.

Or just clear these when Discovering is False.

Not sure if I get that right. Invalidated properties are only a thing when discovery stops? :thinking:

[infirit]

Not sure if I get that right. Invalidated properties are only a thing when discovery stops? 🤔

It is for the TxPower and RSSI properties. These properties are only created when discovering (inquiry or advertising according to dbus api). And when this stops both are invalidated by BlueZ.

[infirit]

While I was working on #2009 i notices rhat bluez never sends a property changed signal for these on existing devices. They do show up on newly discovered device and get invalidates once discovery ends. To be sure I monitored the dbus traffic and it's just never there

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[cschramm]

Are you sure that you tried with legacy devices? My experience with LE devices is that the property does exist but is never actually set, so it makes sense that no updates show up.

[infirit]

I'll test this PR this weekend and if nothing show up for my connected devices I'll post some bluez dbus logs.

[cschramm]

I just checked two LE devices that I use regularly and remain completely confused about the values.

Both do not provide any such values via D-Bus (consequently nothing is shown with this branch nor do any update signals appear in the system).

For one of the devices connection_init fails and current blueman shows 100 % bars. For the other one, init works but the RSSI value seem like nonsensical to me. It varies between 0 and -1, completely independent of the distance of the device etc., so blueman shows a 49 or 50 % bar. TPL constantly stays at 10, so blueman shows a 53 % bar.

I do not get why D-Bus provides nothing while the C interface does but I'm actually wondering if it's worth showing those values at all with LE being the standard case nowadays.

[infirit]

Here is the log while connecting 4 devices, a mouse, android phone and 2 gamepads. https://gist.github.com/infirit/68e832b8f4c2d74ec28a20940569a685

[cschramm]

Let's see if this aged well... 🫣

I do not see any updates in your logs at all. /org/bluez/hci0/dev_D2_0C_FD_5A_21_27 and /org/bluez/hci0/dev_64_A2_00_10_C7_CF (mouse and phone I suppose) seem to be LE devices, so that's totally expected.

The other two seem to be the gamepads with no indication of LE or BR/EDR, but my guess would be not LE, so that I would expect updates on their RSSI and power. :confused:

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarqubecloud[bot]]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

1 New issue
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud