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

[Marcel Holtmann <marcel holtmann org>]

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 :-)

I didn't know that the driver model can now link class devices to actual
real devices. However it can do that and so I converted all Bluetooth
host controller into real devices with a pseudo platform device as
parent for virtual and serial devices. The patch for this has been
tested since a week and I sent it to David Miller for inclusion.

I also tried to represent every remote device as child, but this failed
so far. It triggers a BUG_ON() in the mutex slowpath and I need more
time to fully understand it. A possible solution is schedule_work() like
David did, but I have to check some possible race conditions first.

So this email is to inform you that I am on my way to fully integrate
local and remote Bluetooth devices into the driver model.

Regards

Marcel