Recently some distros have started shipping Bluez 5 — this introduces a completely new DBus API, meaning that bluetooth support for Impress Remote was broken on such systems (openSuse and Fedora being the more notable distros now shipping Bluez 5, whereas e.g. Ubuntu still seems to be sticking with Bluez 4 for now).
LibreOffice has gained Bluez 5 support — this is now available in LO 4.1.6, and will also be included in 4.2.4 (to be released soon).
API Changes: Bluez 4 -> Bluez 5
There is not a huge amount of documentation explaining the changes between Bluez 4 and 5. Fortunately the new API turns out to be fairly clean, and overall is much simpler to use than what we had to do for Bluez 4. However in LibreOffice we restrict ourselves to the low-level dbus library (“If you use this low-level API directly, you’re signing up for some pain.“) which makes things a bit harder and hugely verbose (this is primarily for buildability on older systems and to avoid new dependencies — there is hardly enough dbus use to warrant a slew of new dependencies). (Python however seems to be a much more elegant language for dbus work, as is evidenced by the Bluez 5 unit tests.)
The key differences between the Bluez 4 and 5 DBus APIs that are likely to be of interest to those wanting to add Bluez 5 support to their applications can be found in a document on the bluez homepage, however it’s probably worth adding:
- In most cases you probably no longer need to retrieve any Bluetooth adapters, since Profile registration no longer happens via the devices (unless you want to fiddle with things like discoverability). This is good as the DefaultAdapter no longer exists, so to get hold of an adapter we need to retrieve all objects from the Bluez ObjectManger and filter that for adapters (a complete pain with the low-level library due to multiple levels of dicts which have to be traversed).
- Trying to portray ourselves as a “server” (via the properties passed in to ProfileManager1.RegisterProfile) prevented connections from reaching LibreOffice — this still needs some investigation on my part… (Overall, profile registration is much simpler than with Bluez 4 since we can now just pass in a UUID and not have to construct our own XML SDP record as before.)
- No need to detect Adapters appearing/disappearing (as happens on resume/suspend) in order to reregister profiles thanks to the ProfileManager doing this for us — much simpler main loop as a result.
- New connections are passed to us via the org.bluez.Profile1 callback object which we (the application) have to implement (which provides a socket, connected to the remote device, ready to use in any pre-existing network code you may have, i.e. you can jump straight into send/recv’ing) — however you need to make sure to provide an (empty) reply when you receive the NewConnection call, or Bluez will simply shut down your connection after some timeout.
It’s worth noting that there is also a direct C library for bluez which appears to be quite stable (and as far as I can tell would’ve been the simplest way to do our SDP registration in combination with manual socket management as before — however as I’ve never used it I may be completely misguided on this) — however it is GPL’d and hence not of much use for LibreOffice.
Reliability
Unfortunately Bluez 5 doesn’t seem fully reliable yet, i.e. it can seemingly randomly (but fortunately rarely) break after a suspend/resume cycle (no obvious reproduction recipe known yet, I’m still to get round to debugging in detail). The kde bluetooth management tools in openSuse 13.1 are also a bit crash-prone (but that is known and mentioned in the release notes — the relevant libraries are still in active development). If you are after a more reliable experience it is probably best to stick with Bluez 4 for a while longer.
(Bluez 4 support in LibreOffice continues to exists without change.)