Hi Marcel,

I changed what you said below and attached patch again.

And did you check Guillaume's patch for this issue? his patch try to
find again when ev->link_type is SCO_LINK only. I think his way is
better than mine. I haven't saw other case (LM is not support esco but
ESCO_LINK is connected) and I think it shouldn't happen in a normal
situation.

Best regards,
Louis JANG


Marcel Holtmann ¾´ ±Û:
> Hi Louis,
>
>> When bluez tried to connect SCO channel with
>> HCI_OP_SETUP_SYNC_CONN(ESCO_LINK),
>> a real connection may be connected with SCO_LINK instead of ESCO_LINK
>> when
>> peer device doesn't support eSCO. however bluez try to find
>> connection handle
>> by event's link type(SCO_LINK in above case) and the valid connection
>> handle
>> for this event is waiting for ESCO_LINK. so bluez can't find
>> connection handle
>> and discarded the event.
>
> using HCI_OP_SETUP_SYNC_CONN doesn't mean eSCO. It is perfectly fine
> to request SCO links via that command. The difference here is
> Bluetooth 1.1 or 1.2 and later.
>
>> This patch is to handle different type of synchronous link is
>> estabilished
>> with its request.
>>
>> If bluez can't find connection handle, it try to find with different
>> link type again. (For the above case, if bluez can't find connection
>> handle with SCO_LINK, it try to find connection handle with ESCO_LINK
>> again.)
>> and update link type of this connection handle with event's link type.
>
> Inside the kernel it is not called BlueZ :) It simply is the Bluetooth
> subsystem and in case the HCI core.
>
> Regards
>
> Marcel
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>