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

[Marcel Holtmann <marcel@holtmann.org>]

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