Hi Chen, On Wed, Oct 19, 2011 at 4:50 PM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > I'm not so comfortable using the same Device Found event both for discovering devices and for observing. > In addition, maybe the 'broadcaster variable is the wrong name for this variable. The true meaning is 'discoverable'. A peripheral can broadcast services and other advertising information while broadcasting as discoverable, so this flag may be confusing. > > This also means that the upper layer using this API should keep its own state, to differ between discovering devices (where discoverable devices are displayed as discoverable and broadcast data is collected) or just 'observing' advertising data, where the central device just searches for broadcast data, and has no intention of connecting to a device. In this case, a DEVICE_FOUND event is a bit confusing. > > Do you know if anyone is working on extending the capabilities of the EIR parser for more advertising data types (such as services)? We need to think of a proper way to pass the EIR information to the user in the event. I don't know of anyone working on it currently. But again, I don't think it is a good idea to do this on *kernel* side. The kernel has little use for most of the information, and BlueZ can parse it easily (as it already does for EIR on BR/EDR). If everyone agrees that the "Broadcaster" D-Bus property is not good, this can be easily changed on userspace. But it is more difficult to change kernel<->userspace API after it has been added. Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
