[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 #90 from Swyter (swyterzone@gmail.com) ---
Because it's what I know, plain and simple. It's what I have been using and
it's what I've been comfortable recommending. As long as they are HCI logs and
*they exist* it doesn't matter the format, doing `btmon -w my.log` is much
nicer than `hcidump -X`, that's for sure, so thanks for that. I'm learning as I
go, I figured that if no one was stepping up I might as well give it a try.
Seems like a good way of submitting a first patch and learning a few things.
¯\_(ツ)_/¯

I took a look at your DS4 logs. I would take similar captures on Windows to
compare, maybe the role switch isn't really needed. If you could link your
Windows drivers here it may also be useful, maybe the dongle needs to be
configured with vendor commands before using it. **Update**: Tested DS4 pairing
myself with BlueZ and no, the `Accept Connection Request` packet doesn't show
up and it connects normally, the spec says that this isn't non-fatal, and in
this case the one erroring out due to timeout and disconnecting is the DS4, so
that's something to keep in mind.

From what I see, HCI_OP_ACCEPT_CONN_REQ seems to be called by the SCO layer in
sco_conn_defer_accept():
https://github.com/torvalds/linux/blob/cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/sco.c#L741
Or alternatively from here, I believe:
https://github.com/torvalds/linux/blob/cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/hci_event.c#L2742

It's a wild guess, but it may be sound-related.

--

Another thing to keep in mind is that the bluez-utils package has a nifty
`bccmd` tool for CSR devices (a clone of a proprietary tool, actually) that is
able to get and set most of the internal firmware properties and detect the
chip type, in theory. It doesn't work for me, though. I'm guessing there's an
alternative way of accessing the vendor commands via USB, or the interface has
changed since then.

But at least worth a shot on your end. Maybe you guys have more luck doing
`bccmd chiprev`.

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