>
Whatever you read in the link layer section is something you can forget about right now. That is why the mgmt API actually does not mention advertising delay or internal or alike. It is a bit higher level API with the same affect. It is just less efficient to do that in kernel, then in the controller.
So here is how it is suppose to be done. The duration parameter controls the length an advertising instance stays active. Let say you have two instances, both with 5 seconds each as duration parameter. All instances will be scheduled in round robin fashion.
instance 1 -> 5 seconds, instance 2 -> 5 seconds, instance 1 -> 5 seconds and so on
One thing we need to figure out if controllers let us change the advertising data and scan response data on the fly without disabling advertising or if we have to disable it first. Maybe this needs quirking if different controllers behave differently.
This is as close as we get towards multi-advertising that we just emulate in the host. If there is a controller with offload capabilities, we can at some point just start using it. However that is not the main concern. It has to work on standard hardware as well. Even if it is less efficient.
Got it. Makes all sense to me.
I also found the documentation for the command in mgmt-api.txt in the
meantime.
I'll see how far I get from here then...
--
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
