Hi Daniel, > I have already imposed a "powered" requirement for both MGMT > advertising commands and in the documentation here. In our discussions > regarding this feature, we had chosen to emit a Tx Power Selected > event because these "extended" advertising commands may be used even > on platforms without controller support for extended advertising > features. In other words, we thought it would make more sense to emit > a Tx Power Selected event when relevant, rather than always returning > a Tx power in the MGMT response, even if it is not relevant. If you > think I should return the selected Tx Power directly, I can do so. > Perhaps we can populate the response with > HCI_ADV_TX_POWER_NO_PREFERENCE if extended advertising is not > available. Please let me know your thoughts. I would prefer to directly return Selected_TX_Power value since then you know for sure that the controller has chosen one or does not support it (for that use -127 / TX_POWER_INVALID as value). It has the advantage that you clearly know what you have. Otherwise we have to wait and hope for an event that might come or might not come. Meaning we have to start a timer in userspace and handle the case when it doesn’t come. So I think just return the value and we set it to INVALID if we don’t have it. >> I was thinking we rename Read Security Information Command and also return these values there. I think it is a bit of waste to introduce yet another command to return controller capabilities. > > My mistake, I was under the impression that you preferred adding a new > command. I will look into adding the new Tx power range parameters to > the "Read Security Information Command". Please let me know your > preferred new name for the command. Maybe we keep it simple as “Read Controller Features” command. Regards Marcel
