Thanks, Marcel:
Great! It is starting to make sense. Next, let me ask two questions:
1) You say the information request is needed, but do you mean it is
needed at every reconnection with the device or, as Stefan suggested,
would it make sense to request it only when the connection is first
established and cache the result?
2) Is there a way to know that the device does not support extended
features, to avoid sending a request that is going to time out without a
reply? In net/bluetooth/hci_event.c I found this:
1171 if (conn->state == BT_CONFIG) {
1172 if (!ev->status && lmp_ssp_capable(hdev) &&
1173 lmp_ssp_capable(conn)) {
1174 struct
hci_cp_read_remote_ext_features cp;
1175 cp.handle = ev->handle;
1176 cp.page = 0x01;
1177 hci_send_cmd(hdev,
1178 HCI_OP_READ_REMOTE_EXT_FEATURES,
1179 sizeof(cp),
&cp);
1180 } else {
1181 conn->state = BT_CONNECTED;
1182 hci_proto_connect_cfm(conn, ev->status);
1183 hci_conn_put(conn);
1184 }
1185 }
Is this the right place to look? It seems SSP capability is used as a
test for whether to read the device's extended features. Is this really
the best way, or could there be a more suitable indicator of whether the
device supports extended features, thus avoiding the timeout?
Regards,
Daniel
--
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
