Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get connection info from D-Bus API #1642

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cschramm
Copy link
Member

@cschramm cschramm commented Dec 5, 2021

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
Copy link
Contributor

infirit commented Dec 6, 2021

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.

@sonarcloud
Copy link

sonarcloud bot commented Jul 31, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@cschramm
Copy link
Member Author

cschramm commented Aug 3, 2022

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
Copy link
Member Author

cschramm commented Aug 3, 2022

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

@cschramm cschramm mentioned this pull request Aug 30, 2022
cschramm added a commit to cschramm/blueman that referenced this pull request Aug 30, 2022
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.
@cschramm cschramm mentioned this pull request Aug 30, 2022
cschramm added a commit to cschramm/blueman that referenced this pull request Aug 30, 2022
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.
cschramm added a commit to cschramm/blueman that referenced this pull request Sep 6, 2022
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.
cschramm added a commit that referenced this pull request Sep 6, 2022
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.
@sonarcloud
Copy link

sonarcloud bot commented Sep 6, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@cschramm cschramm marked this pull request as ready for review October 20, 2022 08:32
@cschramm
Copy link
Member Author

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
Copy link
Contributor

infirit commented Nov 12, 2022

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
Copy link
Member Author

Looks like this currently breaks all bars, even battery. 🙈 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? 🤔

@infirit
Copy link
Contributor

infirit commented Nov 20, 2022

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
Copy link
Contributor

infirit commented Jan 17, 2023

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

@sonarcloud
Copy link

sonarcloud bot commented Mar 5, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@cschramm
Copy link
Member Author

cschramm commented Mar 5, 2023

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
Copy link
Contributor

infirit commented Mar 8, 2023

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

@cschramm
Copy link
Member Author

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
Copy link
Contributor

infirit commented Mar 10, 2023

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

@cschramm
Copy link
Member Author

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. 😕

@sonarcloud
Copy link

sonarcloud bot commented Oct 29, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

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})
Copy link
Contributor

@infirit infirit Nov 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somewhere in this function you will need to _disable_power_levels otherwise the bar will remain after ending discovery (until the device is removed).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 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.
Copy link

sonarcloud bot commented Jan 7, 2024

Quality Gate Passed 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

@cschramm cschramm modified the milestones: 2.4, 2.5 Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants