Hi Szymon, >>> --- >>> >>> client/main.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/client/main.c b/client/main.c >>> index f3369e89a..a1d941e30 100644 >>> --- a/client/main.c >>> +++ b/client/main.c >>> @@ -872,6 +872,7 @@ static void cmd_show(int argc, char *argv[]) >>> >>> print_property(proxy, "Powered"); >>> print_property(proxy, "Discoverable"); >>> print_property(proxy, "Pairable"); >>> >>> + print_property(proxy, "LEAddressType"); >>> >>> print_uuids(proxy); >>> print_property(proxy, "Modalias"); >>> print_property(proxy, "Discovering"); >>> >>> @@ -1447,6 +1448,7 @@ static void cmd_info(int argc, char *argv[]) >>> >>> print_property(proxy, "Blocked"); >>> print_property(proxy, "Connected"); >>> print_property(proxy, "LegacyPairing"); >>> >>> + print_property(proxy, "LEAddressType"); >>> >>> print_uuids(proxy); >>> print_property(proxy, "Modalias"); >>> print_property(proxy, "ManufacturerData"); >>> >>> -- >>> 2.14.3 >> >> Another alternative to adding the LE specific type would be to add it >> as Manufacturer string so we can add the information of OUI if public >> or add the information of "Static Random", "Resolvable Random", etc. > > I'd keep it simple - this should simply match to address type that needs to be > passed when connecting L2CAP socket. frankly, I prefer the capability to establish the L2CAP connection via D-Bus and return the socket fd that way as well. The D-Bus object types for devices do not really match any L2CAP socket address anyway. So if people want to establish a L2CAP connection oriented channel, they should be able to do that right from the D-Bus object manager they already in. We did the same for BR/EDR with the profile-api.txt and that should be a similar approach 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
