Hi Marcel,
On Mon, Jul 25, 2011 at 4:38 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Dmitriy,
>
>> >> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
>> >> +struct mgmt_cp_set_fast_connectable {
>> >> + __u8 enable;
>> >> +} __packed;
>> >> +
>> >
>> > so I am not 100% sure that doing it this way is the best way.
>> >
>> > What is the down side of just enabling interlaced page scan all the
>> > time? And then maybe allow tuning of the timeout via debugfs for testing
>> > purposes.
>>
>> This mode changes two parameters: page scan type and page scan
>> interval. There two downsides to have those changed all the time:
>> 1) power consumption
>> 2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
>>
>> In this configuration page scanning happening during all dedicated
>> slots and much more frequently. This is why probably it is not very
>> good idea to have it enabled all the time, but only during short time
>> interval when there are benefits out of such changes.
>
> so the expectation is that bluetoothd or some sort of its plugin keep
> changing from connectable to fast connectable multiple multiple times
> during the lifecycle and based on some specific policy.
That's correct.
> Can you give us some more background on how and when you change the
> modes here. Some simple flow-chart or so.
Fast connectable is switched on when incoming/outgoing call alerting
starts and respectively switched off when alerting stops (i.e. call is
answered/rejected/dropped) as it is implemented in telephony-maemo6
pluging.
The use case is that it enables shorter connection time when user
answers incoming call using headset when the headset is switched off
or disconnected.
>
>> > If we really wanna differentiate between connectable and fast
>> > connectable, then we need to fix up also the controller information to
>> > export this kind of detail. That will get pretty messy right now. So I
>> > would really just prefer to go with interlaced page scan by default and
>> > see what downside this gives us.
>>
>> This is the way how fast connectable implementation is done currently
>> for hci_ops. It is disabled by default and default values for page
>> scan type and page scan interval are used. If one wishes to enable it,
>> audio.conf is used for that purpose. In that case, fast connectable
>> configuration is enabled during incoming/outgoing call alerting only.
>> In this case, connection initiated from headset side can be performed
>> much faster during that specific time interval.
>>
>> Hope this clarifies the questions. What do you think? Could you
>> elaborate more on 'then we need to fix up also the controller
>> information to export this kind of detail.'? Why that is needed?
>
> I like to figure out on what is the best interface to the kernel. Is
> this something really specific or should it be more generic. So for
> example program the page scan intervals into the kernel first. And then
> just toggle. Or have the interval as part of the command to toggle.
>
> And main concern is if multiple profiles wanna make us of it. How do we
> handle that part.
It seems like Claudio's input is quite crucial on how to align it with
LE. Looks like it is quite generic.
BR,
Dmitriy
--
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
