Hi Hemant, > > Please sync with Anderson Briglia, he already sent a RFC to the ML > > some months ago. > > In the Bluetooth Summit(Prague), we decided to not proceed with RSSI > > monitor emulation in the kernel until we have a clear idea or spec > > defining how the controllers will implement RSSI monitoring. > Could you please provide some details about what was discussed in the summit. > > > The ideia was to provide transparency, the userspace doesn't need to > > know if RSSI monitoring is emulated or not. > > As per my understanding the BT spec (4.0, Volume 2, Part E, Section > 7.5.4) the HCI_Read_RSSI command can be used to retrieve the RSSI from > the controller. In our case, I have tested it against ST-Ericsson BT > controller and it works in our case. Are you suggesting that until we > know how the RSSI is determined in controller, we should not implement > this functionality in kernel ? I ask this because in Proximity Spec, > it is mentioned that the monitor should use appropriate calculations > to prevent false alerts on reporter, so if we leave this to layer > above BlueZ to do this part, then we are pretty independent with the > approach of implementation of Path Loss RSSI Monitoring in BlueZ and > Kernel. > > If I misunderstood anything please clarify. we need proper notifications about RSSI changes triggered by the Bluetooth controller and not having the host polling the controller all the time. So just the existence of HCI_Read_RSSI is not enough to make this part efficient. And we can only emulate the RSSI notification via polling once we know how the new HCI commands will look like. We are kinda stuck here. 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
