Hi Arman, On Wed, Dec 10, 2014, Arman Uguray wrote: > For GATT, applications using bluetoothd currently need to use > Device1.Connect and Device1.Disconnect when they want to initiate a > connection to a peripheral, though these functions are really > primarily meant for UI usage. BlueZ already has a D-Bus API for BR/EDR > profiles such as ConnectProfile/DisconnectProfile and the > ProfileManager API which is more geared towards applications and I > think we'll need something for GATT as well. The basic features that > I'm thinking of are: > > 1. Sessions per D-Bus connection that provide a reference count for > the ACL connection. > 2. Correctly handling the reference count if the connection was > initiated via Device1.Connect or via auto-connect. > 3. This would be GATT only at first but it could perhaps expand to > connection-oriented channels eventually? > > I don't really have an RFC API proposal at this point but I wanted to > get this discussion going. What would make most sense here? I have nothing to directly contradict what Marcel already replied, but I'm curious why you've omitted the kernel-managed passive scanning based connection establishment from the description of the issue. I'd expect that to be the principal way of connecting to peripheral devices, I'd also expect this to work in the same way for bluetoothd-external applications as it does for bluetoothd plugins: the application declares its support for a UUID and bluetoothd then adds devices supporting the UUID to the kernel-side connect list. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
