[Bug 60824] [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60824

--- Comment #69 from Sergey Kondakov (virtuousfox@gmail.com) ---
(In reply to Mikhail Novosyolov from comment #68)
> (In reply to Sergey Kondakov from comment #39)
> > (In reply to Fernando Carvalho from comment #38)
> > > Hi,
> > > 
> > > I merged a few fixes and quirks (including some from this thread) and
> sent
> > > them to linux-bluetooth@vger.kernel.org :
> > > 
> > > https://www.spinics.net/lists/linux-bluetooth/msg81304.html
> > > 
> > > Feel free to test it if you have a simillar CSR device
> > > (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001",
> > > ATTRS{bcdDevice}=="8891").
> > > 
> > > It's not perfect, but it allows the use of the adapter and connect a
> > headset
> > > (with some connect errors/retries now and then).
> > > 
> > > Regards.
> > 
> > Great work ! Unlike the actual maintainers who don't even bother to read
> > bug-tracker anymore or use ready fixes for their code that they themselves
> > don't care about, it seems.
> > 
> 
> I have nothing in common with maintaining bluetooth stack in the kernel, but
> I'd like to comment on this a bit.
> That patch adds a device ID to the list of "Fake CSR devices with broken
> commands".
> And you write that it is a "workaround" of this bug, not a "fix".
> If I were a maintainer of BT stack in the kernel, I would try to avoid
> merging such patches unless I have this piece of hardware and a datasheet.
> So, here, I would not blame kernel maintainers for ignoring such bugs.
> 
> Maybe I misunderstood something, feel free to correct me.
> 
> Actually I did not understand from this bug report if this patch works or
> not. Does btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch
> make device just detectable or actually working?

It's detectable but the only device I tested it was Sony DualShock 4 which acts
as master that connects PC to itself which uses "sixaxis" hacks in bluez. And,
in the end, it was a failure: DS4 does not want to pass input data and then
promptly shuts itself off after "pairing". It does work under Windows® with
that dongle but on Linux I had to resort to old BT 2.1 one.

The more important thing is "fixup" parameter patches that allow to at select
hacks per device and at least figure out what it needs without recompiling and
rebooting kernel every time. But, apparently, BT maintainer is not interested
in BT stack being as robust and easy to test as USB either.

I'm pretty sure that the problem is not just that those CSR chips may require
hacks by themselves but that "manufacturers" have flashed them with
inappropriate/misconfigured firmwares without testing, other than trying
something on Windows®, and then flooded Ebay and Aliexpress with those
unlicensed fakes. It's pretty much all you can get in an adequate "simple
dongle" price range. But Windows® manages to avoid those issues somehow,
meaning that Linux's BT stack is too picky, pedantic and too hardcoded for
unnecessary things. And that is something maintainers should care about. We
shouldn't keep figuring out crutches for every model & revision for things that
are not even required for device's purpose.

-- 
You are receiving this mail because:
You are the assignee for the bug.