Re: Bluetooth and HAL (Was Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?)

[David Zeuthen <davidz redhat com>]

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