[PATCH 3/3] bluetooth: Remove the 'bluez.name' property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux