Hi Daniel,
> 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?
that is the wrong place. You need to look into net/bluetooth/l2cap.c.
The LMP features are mandatory at all costs. Otherwise hell breaks loose
if you don't do the right.
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
