Hi Claudio,
>There are four Connection
>Establishment Procedures:
>Auto, General,
>Selective and Direct.
>CreateDevice/CreatePairedDev
>ice will use Direct. But
>after pairing or
>create device("known"
>devices) we need a more
>transparent procedure. I
>am not saying that we will
>implement straitly Auto
>procedure, we will
>also need to handle the
>resolvable address, a hybrid
>approach seems to
>be more appropriated.
>
> We could use Direct
>procedure,
>managing(serializing) the
>connection
>establishment implementing
>logic in the kernel or
>userspace for the
>"known" devices. However, I
>prefer to transfer the
>responsibility to
>the controller. If I choose
>connections using whitelist,
>how the STE
>controller prioritizes the
>advertises? Does directed
>advertises have a
>higher priority?
>
Agreed but not sure whether we have a choice to use both a)auto connection via white-lists and b)direct connection ignoring white-lists - at the same time?
In my opinion for doing either a) or b) you need to set the intitiator filter plicy to either use white-list or ignore it for direct connection. So, if you eventually implement auto-connection, you may not be able to do direct connect at all unless of course if you change the filter policy everytime. STE controller behaves the same way as per controller spec requirements letting the host decide on the filter policy and act suitably.
Coming back to the connection policy debate, we can as well have this as configurable option in bluetoothd to give a choice whether to use auto connection or direct connect policy by default?
Also all the seven steps you need[9.3.5] for auto connection could either be done from user-space itself. And doing same from user-space would make more sense once the connection policy is configurable in bluetoothd?
Please excuse if these sound too wild ...
>At API level, what is the
>benefit of exposing this
>option to the API users?
>
>Some profiles define the
>recommended connection
>parameters, there is
>also the Slave Connection
>Interval Range AD type that
>may be used to
>in the connection
>establishment.
>
I donât have a strong reason to give this option as an API to profiles but considering that a profile may have more flexibiltiy to set the connection parameters etc while initiating a new connection etc. As if this is done by Auto- Connection policy, you may have to set same connection parameters for all devices --something which be undesirable from profile point of view ...
Thanks,
Arun
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
