Le lundi 18 février 2008 à 13:53 -0700, Brad Midgley a écrit :
> Guillaume
> 
> > Better try this new version...
> 
> What problem condition does this patch fix? Should Marcel be
> considering it for merging?

I have issues using "voice"/HSP/HFP profiles with the headset below
(bluetooth 1.2 without optional eSCO support) using a bluetooth 2.0
(eSCO + EDR) usb dongle.

Capture and playback don't work at all, although the "hifi"/A2DP profile
works great.

The other headset, which supports eSCO works with "voice" profile.

I'm using kernel 2.6.25rc2 and bluez 3.26.

Here is info about the headset (Motorola HT820) :

hcitool info xx:xx:xx:xx:xx:xx
Requesting information ...
        BD Address:  xx:xx:xx:xx:xx:xx
        Device Name: Motorola HT820
        LMP Version: 2.0 (0x3) LMP Subversion: 0xa41
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xff 0xff 0x8b 0x78 0x18 0x18 0x00 0x80
                <3-slot packets> <5-slot packets> <encryption> <slot
offset> 
                <timing accuracy> <role switch> <hold mode> <sniff
mode> 
                <park state> <RSSI> <channel quality> <SCO link> <HV2
packets> 
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging
scheme> 
                <transparent SCO> <broadcast encrypt> <enhanced iscan> 
                <interlaced iscan> <interlaced pscan> <inquiry with
RSSI> 
                <AFH cap. slave> <AFH class. slave> <AFH cap. master> 
                <AFH class. master> <extended features> 


About the dongle :

hciconfig -a
hci0:   Type: USB
        BD Address: xx:xx:xx:xx:xx:xx ACL MTU: 1017:8 SCO MTU: 64:8
        UP RUNNING PSCAN 
        RX bytes:706 acl:0 sco:0 events:25 errors:0
        TX bytes:355 acl:0 sco:0 commands:25 errors:0
        Features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: 
        Link mode: SLAVE ACCEPT 
        Name: 'mybt2dongle'
        Class: 0x180104
        Service Classes: Capturing, Object Transfer
        Device Class: Computer, Desktop workstation
        HCI Ver: 2.0 (0x3) HCI Rev: 0x40eb LMP Ver: 2.0 (0x3) LMP
Subver: 0x430e
        Manufacturer: Broadcom Corporation (15)

Joined is the hcidump traces that show the headset accept the
connection, and gives us a handle (0001) but as a sco link (00).

> HCI Event: Synchronous Connect Complete (0x2c) plen 17
  0000: 00 01 00 3f bc f2 a4 07  00 00 00 00 00 00 00
00  ...?............
  0010: 02

Syslog shows a lot of these lines :
kernel: hci_scodata_packet: hci0 SCO packet for unknown connection
handle 1

And "hcitool con" shows this :
Connections:
        > ACL xx:xx:xx:xx:xx:xx handle 11 state 1 lm SLAVE AUTH ENCRYPT
SECURE 
        < eSCO xx:xx:xx:xx:xx:xx handle 0 state 8 lm SLAVE 

Source reading revealed that :
1) eSCO support for the headset is not checked before trying to
establish an eSCO link,
2) if the headset can't do eSCO, when receiving a "Synchronous
Connection Complete event" with SCO link attribute, the hash table
containing eSCO links is not parsed to add the connection handle.

To fix one of these is enough for my headset to work (with the joined
patchs).

I think it affects more people than me alone, anybody that uses a bt2.0+
dongle and old headset(s). And that's why I try to find other cases
helping other people on bluez-users.

My own tests show my patch attempts aren't ready for inclusion, though.
I can try improving my own patches, but I'd need help from someone
knowing bluez and/or kernel development if we want this to be fixed
quickly...

Maybe some spin_lock should be added, or some other field should be
fixed in patch for 2).
I'm not really sure of the problem with patch for 1).

The problem with 2) is : it works the first time (whatever which
headset, sco or esco), but then switching to using the other headset
fails once, and then works :-(

Best regards,

Guillaume B.