Hi Luiz, >>> Add the Bluetooth quality report event in doc/mgmt-api.txt. >>> >>> Signed-off-by: Joseph Hwang <josephsih@xxxxxxxxxxxx> >>> --- >>> >>> Changes in v2: >>> - This is a new patch for adding the event in doc/mgmt-api.txt >>> >>> doc/mgmt-api.txt | 20 ++++++++++++++++++++ >>> 1 file changed, 20 insertions(+) >>> >>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt >>> index ebe56afa4..a0e71a732 100644 >>> --- a/doc/mgmt-api.txt >>> +++ b/doc/mgmt-api.txt >>> @@ -4978,3 +4978,23 @@ Advertisement Monitor Device Lost Event >>> 2 LE Random >>> >>> This event will be sent to all management sockets. >>> + >>> + >>> +Bluetooth Quality Report Event >>> +============================== >>> + >>> + Event code: 0x0031 >>> + Controller Index: <controller_id> >>> + Event Parameters: Quality_Spec (1 Octet) >>> + Report_Len (2 Octets) >>> + Report (0-65535 Octets) >>> + >>> + This event carries the Bluetooth quality report sent by the >>> + controller. >>> + >>> + Possible values for the Quality_Spec parameter: >>> + 0 Not Available >>> + 1 Intel Telemetry Event >>> + 2 AOSP Bluetooth Quality Report Event >> >> can we swap this around please: >> >> 0 AOSP Bluetooth Quality Report Event >> 1 Intel Telemetry Event >> >> Regards >> >> Marcel > > I wonder if we shouldn't have these as bit fields though, so one can > select multiple reports if available. the current code only allows for enabling one of these. If a driver specific one is specified, it takes precedence over the AOSP one, other AOSP is chosen (if supported). Reality is that all major vendors are settling on the AOSP extension since they already have that in their firmwares. So actually I don’t expect to see any other than AOSP or Intel. Regards Marcel
