[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5D9353FF-6A69-4039-9033-C0EBD1CDA756@holtmann.org>
Date: Wed, 27 Feb 2008 16:21:14 +0100
From: Marcel Holtmann <marcel@...tmann.org>
To: Louis JANG <louis@...i.com>
Cc: Dave Young <hidave.darkstar@...il.com>,
linux-bluetooth@...r.kernel.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
bmidgley@...il.com, David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>
Subject: Re: [Bluez-devel] forcing SCO connection patch
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists