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.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
