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.

/sys/class/bluetooth/hci0
|-- acl001122334455
|   |-- address
|   |-- power
|   |   |-- state
|   |   `-- wakeup
|   |-- type
|   `-- uevent
|-- address
|-- device -> ../../../../../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../../../../../../class/bluetooth
|-- type
`-- uevent

Regards

Marcel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-patch
Size: 3917 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20060705/3a35085c/patch-0001.bin