On Tue, Jul 1, 2014 at 8:58 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: >>> This would place the EIR/AD/SR data in the device objects as a property then? >> >> we could do that, but I would like to discuss this a bit more. For example we might not duplicate the information that we have properties for. For example device name or appearance. > > coming to think about it, we might should just focus on the manufacturer specific field and make sure that gets exposed over D-Bus. The other ones are Bluetooth SIG defined and we can define good properties for it. > The main missing SIG defined fields which don't have properties would be: - TX Power (CSSv4 1.5) - URL (https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=287247) All of the others are reasonably internal to BlueZ and not of interest to applications. > We could add a property with array{uint16,array{byte}} that allows us to provide all the manufacturer information we find. On BR/EDR they are pretty static and would just stay around. On LE they would be removed (same as RSSI) once the result becomes invalid. For dual-mode devices found on both transports we just combine them. > If multiple fields of manufacturer data for the same manufacturer are found, we'd just duplicate them in the array? e.g. [ ( 004C, [ 01, 08, ... ] ), ( 004C, [ 02, 15, ... ] ) ] For a fruit-flavored device acting as both an Airdrop target and an iBeacon (this seems to be how they show up - but could be a side effect of one field being in AD and one in SR) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- 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
