Hi Luiz, On Wed, Oct 19, 2016, Luiz Augusto von Dentz wrote: > > Hmm I wonder.. why not just expose full AD + SCAN_RSP this way? > > Are we going to add prop for every data type? > > Then there is no reason to parse the AD, and even broken/unknown AD > should be send which sounds like a very dangerous think to do so Id > leave this for application that can deal with the management socket > but not over D-Bus. I'm not so sure about this (having a "raw" AD/EIR API). We don't necessarily need to expose the raw data as such, but it could be a dictionary where the key is the data type and the value a byte array. That'd at least prevent common pitfalls with broken parsing. We could also consider making this a subscription based thing so that it's not a broadcast signal but either a unicast signal or a method call to whomever has requested to receive the information. Side note: I think the approach the bus1 folks would like to take is to get rid of broadcast signals completely and rely on a service-based subscription mechanism. Johan -- 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
