Re: Odd eSCO behavior with BCM2045-based receiver

[Peter Hurley <phurley@charter.net>]

Peter Hurley wrote:
> While attempting to setup a Motorola S9 headset with a BCM2045-based 
> USB dongle (Dell-branded Logitech device), I've observed some strange 
> eSCO behavior.  I'm running 64-bit 2.6.31 kernel with bluez 4.52.
>
> Behavior # 1:  when attempting a SCO connection, frequently the 
> connection is rejected with Reserved Slot Violation status return from 
> the Synchronous Connect Complete event.  The SCO connection 
> occasionally succeeds as an eSCO connection in CVSD mode. I've been 
> experimenting with this for a while. (After some more observation, it 
> may be that the successful path is preceded by a mode change to sniff 
> mode) Any ideas?
>
> Behavior # 2:  The bt receiver's LM crashes when the eSCO connection 
> is disconnected (here's the hcidump):
>
>
> After this, *all connections with every device* are terminated (note 
> that in the above sequence handle 11 was disconnected as well) and 
> cannot be restarted without unplugging the dongle ('hcitool reset' 
> operates but is ineffective) and restarting the daemon.  Again, I'd 
> welcome any suggestions for further experimentation.  I do not have a 
> sniffer.
>
> Thanks,
> Peter Hurley
Answered my own question by discovering the sco kernel module parameter, 
'disable_esco'.  However, it doesn't make sense to me that one device 
incompatibility disables an entire transport type.  Wouldn't it be 
better if the user-space daemon controlled (or at least had the ability 
to override) which transport was attempted?  At least, control would be 
finer-grained (e.g., only HSP profiles could optionally connect to 
SCO-only).  The sco driver has no idea that the connection attempt is 
being driven for a headset.

Regards,
Peter