Hi Dan, > Here's the ideal NM situation. > > Users will need to pre-pair and preconfigure their BT devices for use > with NM. We'll likely include an application that will allow users to > scan for and select a BT device, pair with it, and set up the > carrier-specific GSM/CDMA settings for the dialup connection. > > Once the BT device is set up and known to NetworkManager, NM will > periodically request scans from BlueZ much like it does for wireless > networks from wpa_supplicant now. If a "known" BT device is around and > supports DUN, NM will show that device in its menu. The user will then > be able to select that device and use it for a DUN connection. > > For this, we'll need a few things from BlueZ and HAL: > > a) dbus methods to request scans and return scan results, along with > capabilities of each device (ie, DUN, handsfree, etc, or however that > works)
you will get discovered devices via signals. This basically only includes the BD_ADDR, the class of device and the RSSI value. So you don't have to actually scan for devices. This already works and the BlueZ D-Bus API also signals you when it starts scanning for new devices and when a scan is finished. It is designed the way that even when another application scans for new devices you can also see the list of devices. In the future it will also take care of the service discovery and send signals for available services. However this hasn't been implemented so far. Remember that Bluetooth devices can be switched invisible and thus you won't see them anymore. So you need to store "used" devices by yourself. > b) dbus methods to pair with a device. We _don't_ want NM to do the > actual pairing or anything, but NM should be able to just call pair(), > have whatever BlueZ dialog is need for PIN pop up, and then receive a > return code of success or failure. We have this already. Just fixing some minor details, but this is one of the most tested features of the new BlueZ D-Bus API. For the PIN dialog you can choose to provide one for yourself or actually let the default one handle it for you. I actually would advise to provide your own one, but this is a minor detail. > c) dbus methods to retrieve the rfcomm serial port device name for a > specific, paired BT device We have something like that, but by default it is not activated now. It needs more testing and I wanna release the other features first. > It doesn't really matter to me where I get the list of available BT > devices from, whether it's BlueZ or HAL, but I'd rather get them from > HAL if I can. Who cares in the end. I would go for the HAL solution by myself, but that's a long way to go. It is not that easy to get a really nice and easy implementation. Bluetooth is not an easy solution. It is full of weird protocols. Regards Marcel _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
