Hi Jo?o Paulo,
On Fri, Apr 26, 2013 at 5:30 PM, <jprvita at gmail.com> wrote:
> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org>
>
> The org.bluez.Device1.Name property is optional and may not be present
> (that happens with the PTS 4.7.0), so it's better not to expose it to
> clients so they don't rely on its existence.
> ---
> src/modules/bluetooth/module-bluetooth-device.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/modules/bluetooth/module-bluetooth-device.c b/src/modules/bluetooth/module-bluetooth-device.c
> index 11c6e5f..542f0af 100644
> --- a/src/modules/bluetooth/module-bluetooth-device.c
> +++ b/src/modules/bluetooth/module-bluetooth-device.c
> @@ -2242,7 +2242,6 @@ static int add_card(struct userdata *u) {
>
> pa_proplist_sets(data.proplist, "bluez.path", device->path);
> pa_proplist_setf(data.proplist, "bluez.class", "0x%06x", (unsigned) device->class);
> - pa_proplist_sets(data.proplist, "bluez.name", device->name);
> pa_proplist_sets(data.proplist, "bluez.alias", device->alias);
> data.name = get_name("card", u->modargs, device->address, &b);
> data.namereg_fail = b;
> --
Ack from my side to the three patches, also for the master branch.
As a minor improvement, the commit messages in patches 2 and 3 could
avoid referring to the org.bluez.Device1 interface, which is BlueZ
5-specific. In particular, the commit message in this patch should
mention that this is future-proof, even though BlueZ 5 is not
supported yet (given that the property is actually *not* optional in
BlueZ 4).
Cheers,
Mikel
