Hi, Sorry for the lag, I was on vacation traveling Friday through Wednesday.
On Thu, 2006-06-08 at 18:45 +0200, Marcel Holtmann wrote: > Hi David, > > > > So the missing pieces are to link other Bluetooth kernel services like > > > RFCOMM, HID, BNEP or CAPI with the Bluetooth adapter. I haven't come up > > > the best approach to do this right. The obvious problem is if you have > > > a /dev/rfcomm0 device for example. How do you tell which Bluetooth > > > adapter it is assigned to. And of course RFCOMM is capable of picking > > > any available adapter if you give it the wildcard source address. > > > > What's wrong with having the actual Bluetooth devices (not the adapter) > > live in sysfs below the adapter > > > > http://people.freedesktop.org/~david/bt.txt > > > > as described in that link? > > I spent a lot time argumenting about this with myself and I haven't come > to final conclusion yet. In general you have to create a new device for > every device you discover or connect to. Which is actually not a bad > idea after all and I saw that the UWB subsystem is actually doing such > thing everytime they get a beacon. > > If we gonna go into this direction then it needs massive changes in the > Bluetooth core itself. At the moment we only have adapters presented > through hci_dev and connection (ACL and SCO) presented through hci_conn. > And the assumption that you only have one ACL link per connection might > not be longer true in the future. The inclusion of UWB as transport for > Bluetooth will change some things. > > However it might be worth to define an empty bt_dev structure and > actually link it with inquiry results and hci_conn to create a bus alike > device tree. This also means we need to present hci_dev as bt_host, > because otherwise we can't differentiate between devices seen from two > different adapters. > > I am open for suggestions here. It is not easy to tell if Bluetooth > better fits into the class device model or be better a simple device on > a bus. Right. It's also interesting how things like Wireless USB is going to fit in here. For me it comes down to this: since you seem to provide kernel drivers for e.g. input and ALSA functionality from Bluetooth devices don't you think it would be nice with the device-> symlink so it's easy to figure out the relationship between class devices and bus devices? I mean, the kernel _already_ knows about the remote Bluetooth devices, all I'm asking for is to put them in sysfs. My crappy patch here http://people.freedesktop.org/~david/bt.txt http://people.freedesktop.org/~david/davidz-bluetooth.patch did exactly that. I really don't know how we'd integrate Bluetooth input and audio devices if HAL doesn't know about this. Going forward it would be super useful to also have e.g. a 'pair' file you could read from ("is the device paired?") and write to ("attempt to pair a device"), e.g. have parts of the Bluetooth control functionality through sysfs. I don't know the details and if you say there are good reasons to go through a user space Bluez D-BUS interface instead of just sysfs that's fine with me. But I thought I'd raise this anyway :-) Cheers, David _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
