Re: Long delay to (re)connect a bluetooth mouse

["Daniel T. Cobra" <dcobra@videam.com.br>]

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