https://bugzilla.kernel.org/show_bug.cgi?id=60824 --- Comment #91 from Sergey Kondakov (virtuousfox@xxxxxxxxx) --- Created attachment 289883 --> https://bugzilla.kernel.org/attachment.cgi?id=289883&action=edit ISSC_ds4_pass.btsnoop (In reply to Swyter from comment #90) > 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. ¯\_(ツ)_/¯ Sure, it's just that not only hcidump likely to not be installed by default or even packaged, the fact that it's long time obsoleted means that it can also be incorrect and no one is going to debug it. btmon's file dumps are binary though, so you would need to use `tee` to dump text as it scrolls or use `btmon -r`. > 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. > I might have made that dump with '-S' option which adds SCO messages that otherwise might be ignored, just for completeness. DualShocks 3 and 4 are fiddly to connect, when connecting to "new" dongle you need to: 1) Remove any OS entries of it. 2) Force DS4 into pairing mode by holding SELECT+PS until light flashes rapidly, for DS3 you need to connect it to USB. It will write dongle's MAC/UID into itself. 3) Now you can switch it on normally. I'm pretty sure DS wants to be the master in that connection. It works fine on my old 2.x ISSC dongle which I tried to replace with fancier 4.x dongles twice while having 2.x as backup. First 4.x dongle killed itself for no reason a minute after plugging in, bastards didn't even refund me for its corpse. And second one is this CSR. But timeouts seem irrelevant, sometimes they just don't react properly fast enough during pairing and they also refuse to connect to a dongle that's not in their memory. On Windows I just use Windows' stock drivers and DS4Windows https://github.com/Ryochan7/DS4Windows for polling rate / latency, lights controls, battery state tracking and xinput emulation. On Linux there is no control (polling/latency would be really nice for battery/responsiveness balancing and parity with new generation of consoles that advertise 1ms wireless latency which DS4 should be well capable of) but I'm trying out https://github.com/TheDrHax/ds4drv-cemuhook now. I think that Windows' BT stack just not as picky. There is no way they would do per-device workarounds for garbage bin dongles like that. They JUST recently (like last year or something) added USB audio driver after years of relying on crappy, often licensed separately, third-party per-device implementations. > > 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`. Fails for me with "Can't execute command: No such device or address (6)" -- You are receiving this mail because: You are the assignee for the bug.
