Created attachment 276421 [details] hcidump I would like to report that this gasia clone does not pair successfully. I'm using Linux 4.9 and default BlueZ 5.49 on Gentoo. The device works just normally via USB cable, but it doesn't pair with any bluetooth controller. Here's the sequence of commands on bluetoothctl. I made sure to delete the device prior to any attempts. power on agent on default-agent discoverable on pairable on scan on Then connecting the device via USB, the message asking for authorization appears: Authorize service [blue1m[agent] Authorize service 00001124-0000-1000-8000-00805f9b34fb (yes/no): yes After removing the cable and pressing the power button, the device connects, but then nothing happens after that and the device shuts down. Even attempting to pair manually during this sequence doesn't work.
You didn't include a lot of the details I requested. Also make sure to start bluetoothd with "bluetoothd -n -d" and attach the output here.
Sorry, bluez is not compiled with systemd support. Any other way to get the desired output? USE=alsa cups mesh obex python_targets_python2_7 readline udev
(In reply to Lucas Ribeiro from comment #2) > Sorry, bluez is not compiled with systemd support. Any other way to get the > desired output? Stop the old bluetoothd, and run this as root, on the command-line.
Created attachment 276423 [details] bluetoothd
> bluetoothd[6914]: plugins/sixaxis.c:agent_auth_cb() remote 00:26:5C:49:A4:AF > old_master 00:15:83:0C:BF:EB new_master 00:1A:7D:DA:71:13 This means that the device was correctly setup by the sixaxis plugin, ready to be connected via Bluetooth. > bluetoothd[6914]: src/adapter.c:dev_disconnected() Device 00:26:5C:49:A4:AF > disconnected, reason 1 > bluetoothd[6914]: src/adapter.c:adapter_remove_connection() > bluetoothd[6914]: plugins/policy.c:disconnect_cb() reason 1 > bluetoothd[6914]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr > 00:26:5C:49:A4:AF type 0 status 0xe This means that it attempted to bond/pair. Was bluetoothctl still running? Did you see the question about pairing?
Yes, bluetoothctl was still running. After the device shuts down, the message shows up: [CHG] Device 00:26:5C:49:A4:AF Connected: no There was nothing regarding pairing after the auth request.
Nice to see a fresh bug about this. I've managed to track down the problem with mine. It is in sony-hid.c file. It sends a hw_raw_request to controller, but this controller expects a hw_output_report on for sixaxis_output_report function. I got this from scp toolkit for Windows where the guy changed the first byte sent to this controller. He sent 0xA2 (HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT). So event though Bluez stack is ok now, it still needs some kernel work.
BTW, I've also tested with a original dualshock, but it caused lights to blink, so maybe a if/else is needed for the fake vs the original
Links for code and bug of Windows project with same problem Hid Output report written originally: https://github.com/nefarius/ScpToolkit/blob/master/ScpControl/Bluetooth/Ds3/BthDs3.cs#L302 Workaround (not implemented for some reason) https://github.com/nefarius/ScpToolkit/blob/c082de827fb6ec3efdff0a7a632977fbdff898e1/ScpControl/Bluetooth/Ds3/BthDs3.cs#L232 Issue where the guy tells that uncommenting the workaround make things work https://github.com/nefarius/ScpToolkit/issues/652
Guys from retrofit did a really nice fix for this. It keeps already existent behavior and fixes gasia (at least for the model I have here). Change is really neat. https://github.com/RetroPie/RetroPie-Setup/pull/2263/commits/017f00f6e15f04b3272ff1abae8742dc4c47b608#diff-293af5b19ba1d1f50c86e8b9b0b1feaf