Hi David, > > That said, nothing stops us from allowing to make our AMP polices > > dynamic and allow the application to change it threshold during > > lifetime. For example it starts out as BR/EDR only and then during the > > usage of the link it decides that now AMP preferred would make sense. In > > that sense you would have manual switching to some level. > > If the policy is dynamic throughout the lifetime of the connection then > that's okay for best effort links. > > I think applications (especially those that stream real-time data at > high rates) will need to know the currently available bandwidth. This > will be useful for even simple file transfer profiles -- if that file > transfer is going to take 100x as long the user probably want to know > about this so they can (for example) turn HS mode on the other device. > > This information could be conveyed in some sort of "channel move > complete" event or a more generic "available bandwidth changed" event. so here you have the following problem, the only interface you get from an application point of view is a L2CAP socket. So you have to work with these constraints. Potentially we can provide something additional via the OOB msg structs (like we do for timestamps), but I am really careful in adding to much into these ones. 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
