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

BlueZ version is not verified to be compatible #105

Open
not-my-profile opened this issue Sep 16, 2023 · 5 comments
Open

BlueZ version is not verified to be compatible #105

not-my-profile opened this issue Sep 16, 2023 · 5 comments
Labels
enhancement New feature or request external caused by bluetoothd or kernel

Comments

@not-my-profile
Copy link

not-my-profile commented Sep 16, 2023

#[tokio::main]
async fn main() {
    let session = bluer::Session::new().await.unwrap();
    let adapter = session.default_adapter().await.unwrap();
    adapter.set_powered(true).await.unwrap();

    let events = adapter
        .discover_devices()
        .await
        .expect("discover devices failed");
}

Failed with the following message on my laptop:

thread 'main' panicked at 'discover devices failed: Error { kind: InvalidArguments, message: "Invalid arguments in method call" }', src/main.rs:10:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

which had bluez 5.50-1.2~deb10u3 (Debian buster) installed.

Upgrading to Debian bullseye (bluez 5.55-3.1) fixed the problem.

I don't know if this library is intended to support bluez 5.50, however I think in any case it probably makes sense for Session::new to perform a version check, returning a helpful error if the detected bluez version is lower than the minimum bluez version supported by this library.

@not-my-profile not-my-profile changed the title Adapter::discover_devices fails with bluez 5.50: "Invalid arguments in method call" discover_devices fails with bluez 5.50: "Invalid arguments in method call" Sep 16, 2023
@not-my-profile not-my-profile changed the title discover_devices fails with bluez 5.50: "Invalid arguments in method call" discover_devices fails with bluez 5.50 (invalid arguments) Sep 16, 2023
@surban
Copy link
Collaborator

surban commented Sep 19, 2023

I agree that this would be helpful, but unfortunately bluetoothd does not expose its version number over D-Bus, thus we cannot perform a version check.

@surban surban self-assigned this Sep 19, 2023
@surban surban changed the title discover_devices fails with bluez 5.50 (invalid arguments) BlueZ version is not verified to be compatible Sep 19, 2023
@surban surban added enhancement New feature or request external caused by bluetoothd or kernel and removed enhancement New feature or request labels Sep 19, 2023
@surban surban removed their assignment Sep 19, 2023
@not-my-profile
Copy link
Author

Ah yeah ... that is unfortunate. Checking the output of /usr/sbin/bluetoothd --version would of course not be completely reliable since there is no guarantee that this is actually the daemon running (which I think precludes it from being done automatically on Session::new). Perhaps a new assert_bluetoothd_version_is_supported method could be introduced that checks /usr/sbin/bluetoothd --version (with the caveat that this might not be the bluetoothd version actually running being documented)?

@surban
Copy link
Collaborator

surban commented Oct 6, 2023

This would be a possibility. However, I am a bit reluctant to add a feature that is potentially unreliable and maybe misleading due to the limitations you described.

I believe the best option is to ask the BlueZ developers to expose their version number over D-Bus and see what they think about it.

@surban
Copy link
Collaborator

surban commented Oct 6, 2023

Feature request opened at at bluez/bluez#619.

@surban surban self-assigned this Oct 6, 2023
@not-my-profile
Copy link
Author

Thanks for opening the feature request there! I gave it a 👍.

The only caveat I see is that the new feature probably won't be backported, so it will probably take quite some time till the bluez version in Debian stable has this feature ... but I'm looking forward to a future where you could rely on this .. even if it's distant.

@surban surban removed their assignment Feb 1, 2024
@surban surban added the enhancement New feature or request label Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request external caused by bluetoothd or kernel
Projects
None yet
Development

No branches or pull requests

2 participants