We’ve implemented support to use BlueZ’s D-Bus ‘newly discovered device’ signal for our ‘live’ discovery feature. Use BluetoothComponent.DiscoverDevicesAsync as always.   It appears that a signal is only raised if the device wasn’t seen the last time discovery was run — I haven’t found whether this is per application or is controllable through their “session” features.  Maybe we need to store the old set each time, adding when we see the DeviceFound signal and removing from it when we see the DeviceDisappeared signal.

Radio.set_Mode is also now supported.  Note that once a radio is ‘PoweredOff’ I can’t find a way through the BlueZ control panels to re-enable it, we don’t load it either so I had to use a custome application to re-enable it.

Finally we’ve also had some feedback from the Mono team that they don’t want to support Bluetooth sockets specifically and have to pull in their header file, so we suggested having their socket layer stop blocking unknown address families and sockaddr types but instead pass them through. We submitted a new patch to them for this[1] and have updated out BluetoothEndPoint class to match[2].

[1] https://bugzilla.novell.com/show_bug.cgi?id=655153#c6

[2] http://32feet.codeplex.com/SourceControl/changeset/changes/82268

(Further to: https://32feetnetdev.wordpress.com/2010/12/05/further-support-for-bluez/ and https://32feetnetdev.wordpress.com/2010/11/24/bluez-support/)

Advertisements