Hi Dan, > > > > 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. > > > > > > > Scanning may or may not be the way forward. We'll have to see what > > > comes out in the wash with that. For the moment, provided the necessary > > > logical bit to enable/disable connections (by some abstract criteria) is > > > in place, > > > we may simply use more liberal criteria. For Bluetooth connections the > > > presence > > > of an hci device would suffice for example. > > > > You also get signals for plug/unplug events for the Bluetooth adapters > > from the BlueZ D-Bus API. > > Seriously, this needs to be done with HAL. There's really no reason to > use another daemon for hotplug of the adapters themselves, I'd probably > reject patches that listened to BlueZ for this. It's fine if BlueZ > sends these out, but HAL they should be duplicated in HAL and that's > where any responsible Linux app needs to get them from.
currently there is a difference between a Bluetooth adapter attached to a driver, a adapter that has been activated and an adapter in raw mode. I now this is messed up, but this is historically grown stuff that won't change over night. The BlueZ D-Bus API is a big step into an easier way to deal with Bluetooth devices. Don't get me wrong. I am all for it to go with HAL for the final solution, but right now we are simply not there. Regards Marcel _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
