Bug#464501: eSCO support breaks (SCO?) headsets

[Frédéric Brière <fbriere@fbriere.net>]

On Sat, Feb 14, 2009 at 01:14:10PM -0500, Frédéric Brière wrote:
> The bad news is that I can't give 2.6.27+ a try, since 769be97 breaks
> things even further; any connection attempt just hangs there, with

Turns out the problematic part of 769be974 is the last patch in
hci_conn_complete_evt().  Reverting it does the trick for me, and it was
properly fixed by c89b6e6b.

I could therefore (finally) try out more recent kernels; unfortunately,
I'm still unable to connect to my headset without ripping out eSCO
support, even with 2.6.30-rc7.

(I should point out that there have been several commits addressing this
issue of late; see efc7688b, 732547f9 and 9499237a.  I guess I'm the
unlucky owner of a differently-broken Bluetooth adapter.)

Furthermore, the disable_esco, added in 7cb127d5, does not work for me.
This only turns off the one lmp_esco_capable() in net/bluetooth/sco.c,
which is not enough; there are two more in net/bluetooth/hci_conn.c
which will make any connection attempt fail.  (There are also two others
in net/bluetooth/hci_event.c, but they don't appear to have any impact.)


-- 
<Overfiend> ltd: Fine, go through life just pointing and grunting at
            what you mean.  Works for Mac users.