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

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

usertags 464501 - orphaned
submitter 464501 Frédéric Brière <orphaned-bug@fbriere.net>
thanks

On Thu, Dec 18, 2008 at 05:20:55PM -0500, Frédéric Brière wrote:
> Its current purpose is to track a specific regression, introduced with
> eSCO support in b6a0dc82.  Namely, the kernel will always attempt to
> establish an eSCO connection if the Bluetooth adapter supports it,
> regardless of any support from the device itself.  This is a problem for
> those of us who are using a cheap old headset with a not-so-old
> Bluetooth adapter.

I've long since ditched that crappy bluetooth headset for something
better, but I just pulled it out of the mothballs, out of curiosity, to
see if I could replicate my past experience on more recent kernels.

Turns out I didn't even get that far, as I could not get the device to
show up in "hcitool scan" in the first place.  After some mucking
around, this appears to be caused by some regression introduced in bluez
between 4.84-1 and 4.86-1.

Unfortunately, shortly downgrading bluez, that crappy headset eventually
froze and never came back to life.

I therefore find myself unable to provide any further information on
this bug, or even determine if it still exists.  And since I've moved
away from BT headsets (especially crappy old models), I don't really
care about it anymore.

If anyone out there has any interest in this bug, please feel free to
set yourself as its new submitter.  If noone steps forward, the kernel
team has my blessing to handle it as they see fit.

(For the record, this particular headset model was a WNI H1010.)


-- 
How do I type "for i in *.dvi do xdvi $i done" in a GUI?
	-- Discussion in comp.os.linux.misc on the intuitiveness of interfaces