On 11-03-14 11:29 AM, Brad Midgley wrote: > Brian, Hey Brad, > iirc, the hcitool output tells you the role of the local adapter in > the connection. So when you see 'master' in that list, it's what you > want. You should also be requesting master when you try hcitool. How does this reconcile with that though: $ hcitool con Connections: > ACL 00:1F:20:0F:30:6A handle 12 state 1 lm MASTER < SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE < ACL 00:1A:45:1B:19:89 handle 11 state 1 lm SLAVE AUTH ENCRYPT If that "MASTER/SLAVE" at the end of those lines is telling me what the disposition of the B/T adapter is, how can it be both MASTER for one device and SLAVE for another? Is this "MASTER/SLAVE" relationship per device and the adapter can be master for some and slave for others? I can't seem to change the connection for 00:1A:45:1B:19:89 to be master: $ sudo hcitool sr 00:1A:45:1B:19:89 master Switch role request failed: Input/output error so I am back at this place again. And device co-existence is not at all stable again. The mouse keeps dropping out. ~sigh~ Is the "MASTER" in this at all relevant? Isn't it telling me that my adapter should be trying to negotiate being master in all of the connections it tries to create? $ hciconfig hci0 lm hci0: Type: BR/EDR Bus: USB BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1 Link mode: MASTER b.
Attachment:
signature.asc
Description: OpenPGP digital signature
