Get connection info from D-Bus API #1642
Conversation
|
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. |
cschramm
force-pushed
the
libbluetooth
branch
from
bfb4922
to
8f3c485
Compare
cschramm
force-pushed
the
libbluetooth
branch
2 times, most recently
from
61f4114
to
c329f86
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
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). |
|
#1812 is an (unsatisfying) draft for option 2. |
This value is really pointless, especially as it is vendor specific. Also it's only available via libbluetooth, so BlueZ 6 will not have it anymore. This is more or less a subset of blueman-project#1642.
This value is really pointless, especially as it is vendor specific. Also it's only available via libbluetooth, so BlueZ 6 will not have it anymore. This is more or less a subset of blueman-project#1642.
This value is really pointless, especially as it is vendor specific. Also it's only available via libbluetooth, so BlueZ 6 will not have it anymore. This is more or less a subset of blueman-project#1642.
This value is really pointless, especially as it is vendor specific. Also it's only available via libbluetooth, so BlueZ 6 will not have it anymore. This is more or less a subset of #1642.
cschramm
force-pushed
the
libbluetooth
branch
from
c329f86
to
ea2f23b
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
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. |
|
The edit: Quick hack https://gist.github.com/infirit/b9409c9e8108535b374f3cd6bf2ea72e |
|
Looks like this currently breaks all bars, even battery. 🙈 I'll have another try.
Not sure if I get that right. Invalidated properties are only a thing when discovery stops? 🤔 |
It is for the |
|
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 |
|
Kudos, SonarCloud Quality Gate passed!
|
|
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. |
|
I'll test this PR this weekend and if nothing show up for my connected devices I'll post some bluez dbus logs. |
|
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 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. |
|
Here is the log while connecting 4 devices, a mouse, android phone and 2 gamepads. https://gist.github.com/infirit/68e832b8f4c2d74ec28a20940569a685 |
|
Let's see if this aged well... 🫣 I do not see any updates in your logs at all. 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. 😕 |
cschramm
force-pushed
the
libbluetooth
branch
from
689256d
to
87ede5e
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
| if round(row[name], -1) != round(perc, -1): | ||
| icon_name = f"blueman-{name}-{int(round(perc, -1))}.png" | ||
| icon = GdkPixbuf.Pixbuf.new_from_file_at_scale(os.path.join(PIXMAP_PATH, icon_name), w, h, True) | ||
| self.set(tree_iter, **{name: perc, f"{name}_pb": icon}) |
There was a problem hiding this comment.
Somewhere in this function you will need to _disable_power_levels otherwise the bar will remain after ending discovery (until the device is removed).
There was a problem hiding this comment.
🤔 Don't we rather need to handle when the properties get invalidated?
There are device properties for RSSI and Tx power now and link quality is pointless.
|
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.