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

[Marcel Holtmann]

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.
> 
> and attached is a patch against the latest kernel that represents every
> Bluetooth low-level connection (ACL and SCO) as device under the parent
> device that represents the Bluetooth host controller.

and I also finished the integration of HIDP and BNEP into this new
driver model for Bluetooth. So now you can actually tell which Bluetooth
connection is used by input and network devices:

/sys/class/bluetooth/hci0
|-- acl001122334455
|   |-- address
|   |-- net:bnep0 -> ../../../../../../../../class/net/bnep0
|   |-- power
|   |   |-- state
|   |   `-- wakeup
|   |-- type
|   `-- uevent
|-- acl00AABBCCDDEE
|   |-- address
|   |-- input:event3 -> ../../../../../../../../class/input/input18/event3
|   |-- input:input18 -> ../../../../../../../../class/input/input18
|   |-- input:mouse1 -> ../../../../../../../../class/input/input18/mouse1
|   |-- power
|   |   |-- state
|   |   `-- wakeup
|   |-- type
|   `-- uevent
|-- address
|-- device -> ../../../../../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../../../../../../class/bluetooth
|-- type
`-- uevent

I need to split and clean the patches a little bit and then I will
release a new -mh patch and push them out to my repository.

Regards

Marcel