https://bugzilla.kernel.org/show_bug.cgi?id=60824 --- Comment #90 from Swyter (swyterzone@xxxxxxxxx) --- 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.
