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.
Can you give us some more background on how and when you change the
modes here. Some simple flow-chart or so.
> > 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.
Regards
Marcel
--
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
