dbus programming

dbus programming

[sathish]

Hi,
Is there any one who can help for writing bluez avrcp application with 
dbus programming

Regards,
Sathish N

LE discovery procedure

[Ganir, Chen]

Hi.

I'm trying to figure out how the current implementation of the discovery procedure for LE. I'm using the mgmtops plugin, and a rather recent version of the Bluetooth-next git.
My reference is Bluetooth Core 4.0, Part C, 9.2 Discovery modes and precoedures.

According to the code in hci_event.c :
----->8------------------
static inline void hci_le_adv_report_evt(struct hci_dev *hdev,
						struct sk_buff *skb)
{
	u8 num_reports = skb->data[0];
	void *ptr = &skb->data[1];
	s8 rssi;

	hci_dev_lock(hdev);

	while (num_reports--) {
		struct hci_ev_le_advertising_info *ev = ptr;

		hci_add_adv_entry(hdev, ev);

		rssi = ev->data[ev->length];
		mgmt_device_found(hdev->id, &ev->bdaddr, NULL, rssi, ev->data,
								ev->length);

		ptr += sizeof(*ev) + ev->length + 1;
	}

	hci_dev_unlock(hdev);
}
-----8<------------------

In this code, we use the hci_add_adv_entry to add the device to the connectable list, without even looking at the eir data itself. We simply check if it is connectable by checking the evt_type to be either ADB_IND or ADV_DIRECT_IND.

After that, a mgmt_device_found event is fired, which is then translated into btd_event_device_found, and then into adapter_update_found_devices, which calls adapter_emit_device_found. At no point there is a check for flags value, other than making sure it's not <0 for LE indication.

According to the spec, there are 3 discoverable modes available : None, Limited and general. Here's how the spec defines General discovery procedure :
"The Host shall check for the Flags AD type in the advertising data. If the Flags
AD type is present and either the LE General Discoverable Mode flag is set to
one or the LE Limited Discoverable Mode flag is set to one then the Host shall
consider the device as a discovered device, otherwise the advertising data
shall be ignored."

We do not do that right now. Moreover - we simply ignore the flags, and just treat every advertising event as device found.

Am I missing something here ? If not, I am going to sumbit a patch for fixing this, like this :

----->8------------------
#define EIR_FLAGS	0x01
static inline int get_le_discoverable_mode(struct hci_ev_le_advertising_info *ev)
{
	u8 *eir_data = ev->data;
	u8 idx = 0;

	if (!is_connectable_adv(ev->evt_type))
		return 0;

	while (idx < HCI_MAX_EIR_LENGTH - 1) {
		u8 field_len = ev->data[0];
		if (field_len == 0)
			break;
		switch (ev->data[1]) {
		case EIR_FLAGS:
			return eir_data[2] & 0x3;
		default:
			break;
		}
		idx += field_len + 1;
		eir_data += field_len + 1;
	}
	return 0;
}

static inline void hci_le_adv_report_evt(struct hci_dev *hdev,
						struct sk_buff *skb)
{
	u8 num_reports = skb->data[0];
	void *ptr = &skb->data[1];
	s8 rssi;

	hci_dev_lock(hdev);

	while (num_reports--) {
		struct hci_ev_le_advertising_info *ev = ptr;

		if (get_le_discoverable_mode(ev) > 0) {
			hci_add_adv_entry(hdev, ev);

			rssi = ev->data[ev->length];
			mgmt_device_found(hdev->id, &ev->bdaddr, NULL, rssi, ev->data,
								ev->length);
		}
		ptr += sizeof(*ev) + ev->length + 1;
	}

	hci_dev_unlock(hdev);
}
-----8<------------------

A proper patch will be sent once I get to test this properly.

Thanks,
Chen Ganir

Re: LE discovery procedure

[Anderson Lizardo]

Hi Chen,

On Wed, Oct 19, 2011 at 4:17 AM, Ganir, Chen <chen.ganir@ti.com> wrote:
> According to the spec, there are 3 discoverable modes available : None, Limited and general. Here's how the spec defines General discovery procedure :
> "The Host shall check for the Flags AD type in the advertising data. If the Flags
> AD type is present and either the LE General Discoverable Mode flag is set to
> one or the LE Limited Discoverable Mode flag is set to one then the Host shall
> consider the device as a discovered device, otherwise the advertising data
> shall be ignored."
>
> We do not do that right now. Moreover - we simply ignore the flags, and just treat every advertising event as device found.

Actually we check it, but on the BlueZ side (as you know, our host
stack is composed of kernel+userspace). From
adapter_emit_device_found() in src/adapter.c:

        if (dev->le) {
                gboolean broadcaster;

                if (dev->flags & (EIR_LIM_DISC | EIR_GEN_DISC))
                        broadcaster = FALSE;
                else
                        broadcaster = TRUE;

                emit_device_found(adapter->path, paddr,
                [...]

But note that we still send the "DeviceFound" D-Bus signal, but with a
"Broadcaster" property which UI can use to ignore the device.

Filtering on the kernel requires parsing Adv. data, and may not allow
us to implement Broadcaster role on BlueZ (and on external
applications as well) in future.

IMHO the kernel should still notify userspace of the device, then
BlueZ can filter out the Broadcaster devices as necessary, *unless* we
plan to parse all AD information on kernel, which is not a good idea
IMHO.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

RE: LE discovery procedure

[Ganir, Chen]

Hi Anderson

> 
> Actually we check it, but on the BlueZ side (as you know, our host
> stack is composed of kernel+userspace). From
> adapter_emit_device_found() in src/adapter.c:
> 
>         if (dev->le) {
>                 gboolean broadcaster;
> 
>                 if (dev->flags & (EIR_LIM_DISC | EIR_GEN_DISC))
>                         broadcaster = FALSE;
>                 else
>                         broadcaster = TRUE;
> 
>                 emit_device_found(adapter->path, paddr,
>                 [...]
> 
> But note that we still send the "DeviceFound" D-Bus signal, but with a
> "Broadcaster" property which UI can use to ignore the device.
> 
> Filtering on the kernel requires parsing Adv. data, and may not allow
> us to implement Broadcaster role on BlueZ (and on external
> applications as well) in future.
> 
> IMHO the kernel should still notify userspace of the device, then
> BlueZ can filter out the Broadcaster devices as necessary, *unless* we
> plan to parse all AD information on kernel, which is not a good idea
> IMHO.
> 

I'm not so comfortable using the same Device Found event both for discovering devices and for observing.
In addition, maybe the 'broadcaster variable is the wrong name for this variable. The true meaning is 'discoverable'. A peripheral can broadcast services and other advertising information while broadcasting as discoverable, so this flag may be confusing.

This also means that the upper layer using this API should keep its own state, to differ between discovering devices (where discoverable devices are displayed as discoverable and broadcast data is collected) or just 'observing' advertising data, where the central device just searches for broadcast data, and has no intention of connecting to a device. In this case, a DEVICE_FOUND event is a bit confusing.

Do you know if anyone is working on extending the capabilities of the EIR parser for more advertising data types (such as services)? We need to think of a proper way to pass the EIR information to the user in the event.

Best regards,
Chen Ganir.

Re: dbus programming

[Lucas De Marchi]

Hi Sathish

On Wed, Oct 19, 2011 at 3:54 AM, sathish <sathish.n@globaledgesoft.com> wrote:
> Hi,
> Is there any one who can help for writing bluez avrcp application with dbus
> programming

Take a look in test/mpris-player.c if you want to use C or
test/simple-player if you prefer python.



Regards,
Lucas De Marchi