search

bluez / bluer

BlueR — Official BlueZ Bindings for Rust
https://crates.io/crates/bluer
Other
301 stars 46 forks source link

Consider using zbus instead of dbus for easy cross compliation #7

Open sinhpham opened 3 years ago

sinhpham commented 3 years ago

bluer currently depends on dbus, which in turn depends on libdbus, a C library. As a result, cross compiling bluer is hard.

Please consider using a pure Rust alternative to dbus, zbus perhaps? https://crates.io/crates/zbus

See a related issue in a similar crate using dbus: https://github.com/hoodie/notify-rust/issues/85

laszlourszuly commented 3 years ago

What do you mean by "cross compiling bluer is hard"? Cross compiling to different platforms (win, mac linux etc)?

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

sinhpham commented 3 years ago

No not different platforms but different architectures. In our case they're various Raspberry Pi devices (RPi 3, 4, Zero), so armv7-unknown-linux-gnueabihf, armv5te-unknown-linux-gnueabi, maybe more.

Would you be open to accepting PRs to switch dbus to zbus?

laszlourszuly commented 3 years ago

Thanks for clarifying! I'm just an eager follower of bluer project and can't answer your practical questions regarding PR's and such. Sorry.

sinhpham commented 3 years ago

Haha no worries, I guess it's a question for @surban

surban commented 3 years ago

Yes, generally I am open for it, provided that no functionality is lost. I've successfully cross-compiled BlueR myself, but reducing C dependencies is a good idea in my opinion.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

zeenix commented 2 years ago

Hi there, zbus developer here.

I've never worked with zbus before, but from a quick glance over its documentation it seems that async D-Bus server support is still missing. This would have to be implemented in zbus before it becomes usable for BlueR.

This was added some months back in 2.0 beta and last month we had 2.0 stable release (finally). :) To be clear, that was the high-level API that was missing.

Also, sometimes we have to return "no property" errors over D-Bus because BlueZ tests for existence of properties to determine the write/notify method of a GATT characteristic. I don't know if this can currently be done with zbus.

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

However, I just checked and you're right that we don't support returning errors from property getters in dbus_interface currently. Nobody reported this or asked for this before today (when I just happen to stumble on this issue) so that's the only reason we missed out on this.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

zeenix commented 2 years ago

Zbus is currently claimed to be Linux specific. Wouldn't that be equally hard to cross compile, if so?

Now unix-specific but I'm about to merge the PR for windows support and CI. So the coming release should be quite portable in terms of OS.

surban commented 2 years ago

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

zeenix commented 2 years ago

Quick look at the code you linked to, I'm not sure if you're using some kind of high-level API (does dbus-rs even have that?) or lower-level one (where you do message passing). With the (not so) low-level API of zbus, you can do almost anything.

This was a high level API. In fact dbus_crossroads even provides a high-level framework for implementing D-Bus servers.

Gotcha, thanks.

I'll fix this soon. Once fixed, you can easily define custom errors to return on the bus, through DBusError trait and derive macro. You can track the progress in this issue I just created.

I am looking forward to that! Although I cannot make any promises right now when I'll port to zbus due to limited time.

Awesome! There is no hurry. :)

surban commented 2 years ago

Would you be open to accepting PRs to switch dbus to zbus?

@sinhpham Now that zbus is ready for use, would you be willing to provide some PRs? ;-)

wash2 commented 1 year ago

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

zeenix commented 1 year ago

If there is still interest in PRs switching from dbus to zbus, I'd be happy to start working on them :)

Pretty sure there is (right @surban?) but tbh I haven't yet gotten around to addressing https://gitlab.freedesktop.org/dbus/zbus/-/issues/251 yet. If you could contribute that first, that would be great. Otherwise, you'll have to either use low-level API for interface properties until the missing zbus support is added or wait till I get around to that.

surban commented 1 year ago

Yes, definitely!!!

But I agree with @zeenix that we should add missing features to zbus first. Using a low level API would make BlueR more complex without any benefit.

wash2 commented 1 year ago

Ok I will look into that first 👍

zeenix commented 1 year ago

wow @wash2 wasn't messing around. Thanks to them, git main of zbus now supports fallible property getters. @surban There is a small gotcha that currently you can only return fdo::Error though but given that fdo:Error covers a lot of common errors and has a generic variant too, I'm hoping that's not a show-stopper here.

zeenix commented 1 year ago

just FYI I publish zbus 3.10.0 which includes the needed feature.

zeenix commented 1 year ago

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

wash2 commented 1 year ago

@wash2 How is it coming along? Please do let me know if you need any help figuring out the zbus API for this. In case you didn't know already, we've a #zbus:matrix.org Matrix room to get help quickly.

Hi! To be honest, I have not made much progress on this in the last couple weeks. I will hopefully work on it more soon, but I'm worried that I won't be able to test everything that I'm changing 😅. I assume I will need some advice, so thank you for sharing the link :)

zeenix commented 1 year ago

but I'm worried that I won't be able to test everything that I'm changing sweat_smile

Let's hope @surban can help with that part. Maybe a Draft PR first?

I assume I will need some advice

I can certainly try my best to help with the D-Bus and zbus bits. Unfortunately don't know much about bluez.

surban commented 1 year ago

We don't have tests per se, but most of the functionality is exercised by the examples and tools. If they behave as before, you didn't break it ;)

For testing you don't need anything more that two Raspberry Pis and some basic knowledge of Bluetooth.

jhartzell42 commented 1 year ago

Hi @wash2 , I'd be interested in collaborating on this.

wash2 commented 1 year ago

Hi @wash2 , I'd be interested in collaborating on this.

@jhartzell42 Honestly, I really haven't had a chance to work on the PR yet, so if you'd like to work on it, go ahead. I would be happy to help where I can but I've unfortunately been very busy on some other projects :smiling_face_with_tear:

Athorus commented 6 months ago

Hello, any news about zbus ? I would like to cross compile from x64 linux to raspberry zero, so it would help a lot.

I was used to compile for target arm-unknown-linux-gnueabi, but since bookworm, ld-linux.so.3 file lib is no longer available on raspberry, so I cannot use anymore the package libdbus-1-dev:armel on compilation host.

Maybe buildroot can do the job…

zeenix commented 6 months ago

@Athorus I think it's just waiting on someone to do the work.

surban commented 6 months ago

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

Athorus commented 6 months ago

@Athorus A workaround for you might be to switch to a distribution that has a desktop counterpart and Raspberry Pi version. For example Ubuntu is available for both x86_64 and aarch64.

It works for Raspberry pi Zero 2, because aarch64 is compiled with same options, but doern’t work for armhf, because Raspberry Pi armhf (arm v6 + hf) is not compiled with same options as standard Debian armhf (arm v7). In bulleyes I used the trick to compile to armel (arm v5 without hf), but doesn’t work anymore.