Connection via bluetooth PS(R) Ga`epad

[ManHunter]

Hi. Thank you for all that you do.

I have bluetooth in my laptop (VID_04CA&PID_300B) and gamepad PS(R) Ga`epad (VID_054C&PID_0268). Gamepad perfect works via USB cable, but not working with bluetooth. Also gamepad fine working with android via bluetooth. This video showing connection to SCPServer 1.7.265.16077 (compile from latest source). https://www.dropbox.com/s/cgwkhv93ok1zu55/Gamepad2.avi?dl=0 This video connect gamepad to android via usb and bluetooth: https://www.dropbox.com/s/tga7was2qj6w8ek/gamepad%20android.avi?dl=0

Please!!! help me to connect a gamepad for bluetooth. Sorry for my bad English.

[sylveon]

Have you installed the Bluetooth Driver?

The video on Dropbox doesn't looks to show "Initialising Bluetooth host " in the server log, wich only show when Bluetooth driver is installed and working.

[ManHunter]

Have you installed the Bluetooth Driver?

yes. http://joxi.ru/12M14JMH7xno2J http://joxi.ru/BA0dOBziNK9RAy And necessary download video for better quality.

[sylveon]

Probably related to #51, then.

[nefarius]

Beware that the current state of the code isn't stable nor have I changed anything regarding the counterfeit pads so I'm not surprised it doesn't work. It's on my To-Do.

[nefarius]

@ManHunter thanks btw. for your dedication of even making a video! Images say more than a thousand words.

[LOSSLOSS]

I have exactly the same issue: PS(R) Ga`epad VID_054C&PID_0268

Works through cable but wont pair with bluetooth. "Trying workarounds" and ends with "HCI_Disconnection_Complete_EV [05]

If you need more info just mention it. Love to get this to work. Gamepad will pair with my raspberry.

[LOSSLOSS]

I have tried a different BThost. VID_0A12&PID_0001&REV_8891 "Trying workarounds" and keeps on trying this one.

[LOSSLOSS]

Output of my onboard BThost: VID_8087&PID_07DC&REV_0001

Did not keep on connecting the first time but actually now it does. But does not complete pairing process.

[nefarius]

Thanks but don't waste your time polishing bug reports on this issue, I already know what's the problem but haven't had enough time and/or play with the controllers to invent a fix.

[LOSSLOSS]

Got it. Sorry for wasting your time then. Thanks for making great software.

[nefarius]

@LOSSLOSS no problem, just wanted to point this out for other readers.

[joshuagrisham]

Hi nefarius, Not sure if you have had a chance to look into this PANHAI issue as of late or if you have very specific things already in mind that would fix this problem. I know that you said you have it on the table but my curiosity always gets the best of me so I tried to take a little look :)

First I have tried 3 different kind of gamepads with varying degrees of success.

The first is this one from Slickblue: http://www.amazon.com/Slickblue-Bluetooth-Controller-Playstation-Black-Orange/dp/B00GNX4ZC2

This one works perfectly with the drivers with both wired and bluetooth. Everything works exactly like it should. The only problem is, the buttons on this gamepad are TERRIBLE. You can push and tap the buttons over and over and the only way they will register a button click is if you press exactly in the center very firmly. It doesn't sound like a big deal but it is actually VERY distracting and impossible for me to get used to after growing up playing console games (Nintendo, Sega Genesis, etc :) ). So I wanted to try others to see...

The second I tried is called FiveStar: http://www.amazon.com/FiveStar-Controller-Wireless-Gamepad-Playstation3/dp/B016XF0Y4M

And the third I tried is called GAME-O: http://www.amazon.com/GAME-O-Bluetooth-Wireless-Controller-Playstation/dp/B00WUX9RCW

For these pads, they both had great button clicking and tapping - the sensors worked immediately and every time no matter how or which angle I pressed the buttons. The physical properties of the pad and sensors on both of them are great. Wired they work perfectly, but I cannot get them to work wireless over bluetooth with the same issue mentioned here as well as many times in both PCSX2 forum threads (the original Scarlet Crush as well as yours). The output in ScpServer and logs is identical to what LOSSLOSS posted above.

All three of these gamepads I linked here come up as VID_054C&PID_0268 (with REV0100) but the name when you plug in via USB is a little different for each of them.

Slickblue: PLAYSTATION(R)3 Controller (MAC 8A:5D:66) Fivestar: PS(R) Ga`epad just like above.. for MAC I don't remember because it is already in the box to return :) GAME-O: PS3 GamePad (MAC 03:82:88)

However when connecting via bluetooth, the response to the HCI name request seems exactly the same for all of them: PLAYSTATION(R)3Conteroller-PANHAI

So I pulled down the source code for the latest release and decided to do a little debugging to see if I could either do a quick-fix to get it working or find more out about the problem.

The first thing I noticed was that the Slickblue (the one working) seemed to work exactly as the driver was expecting.. after name request and "Trying workarounds..." I sends a L2CAP connect request as HID_Command (0x11 in position 12 of RawBytes buffer) and then another HID_Command on the L2CAP config request, then it sends a connect request as HID_Interrupt (0x13 in position 12) followed by L2CAP config request also as HID_Interrupt ... this leads to connect.CanStartService set to true and ScpServer continues by establishing the connection with the controller. It works perfectly.

The Fivestar and GAME-O seem to be doing the same thing as in this post, though. They are able to come all the way to where name response is given but then it immediately executes an HCI_Disconnection_Complete_EV. So I dug a little more to see if I could find what is happening.

First off I noticed that the position 12 never changes over from 0x11 to 0x13 on the 2nd pass.. it always just stays at 0x11. The second thing I noticed is that MTU was showing as 672 yet on every other working example (and even the Slickblue) it looks like MTU is 0. The ones that aren't working are setting value in position 20 and 21 while the ones that are working fine seem to have 0 in these positions on L2CAP Config response. The third thing I noticed, (and maybe this is more important?), the bytes for Source Channel Identifier that the controller is sending back is different on the working vs non working.

So now looking at HciWorker ... when the working controller is sending as HCI_Connection_Complete_EV (position 8 of this raw buffer is 0x03) then byte 14 and 15 both have a value which looks like are the 2 valid SCI (0xee and 0x20 in this case). HCI_Connection_Complete_EV (0x03) is received twice and the value stays same in 14 and 15, but then when it goes to HCI_Connection_Request_EV (0x04 in position 8) then these 2 values (0xee and 0x20) move to position 12 and 13 just like the code seems to be expecting (as per code in getter of SourceChannelIdentifier). When it is first on 0x03 the values for byte 12 and 13 are 0x40 and 0x00 so it looks like this: First: [8]=0x03 [9]=0x01 [10]=0x08 [11]0x00 [12]=0x40 [13]=0x00 [14]=0xee [15]=0x20

Then: [8]=0x04 [9]=0x01 [10]=0x08 [11]0x00 [12]=0xee [13]=0x20 [14]=0x00 [15]=0x00

For the non-working controllers, on HCI_Complete_Connection_EV (0x03) it has a value for byte 14 for the first SCI but the value in byte 15 is 0 .. so is there only 1 source channel? Or is this bogus? Also I noticed that the value is always the same 0x40 so maybe that is actually supposed to be in 12 and 13 instead but the controller is sending things in the wrong position? It looks like this:

First: [8]=0x03 [9]=0x01 [10]=0x08 [11]0x00 [12]=0x43 [13]=0x00 [14]=0x40 [15]=0x00

Then: [8]=0x04 [9]=0x03 [10]=0x08 [11]0x00 [12]=0x40 [13]=0x00 [14]=0x00 [15]=0x00

So it looks like 0x40 is moving up from 14 to 12 when 8 = 0x04 (HCI_Connection_Request_EV) like it is supposed to but why is the 2nd channel not set? Is it even valid for the controller to only have 1 Source channel?

Anyway the short version just from my observations is that it seems like there are some issues with these "non-working" PANHAI and not following bluetooth spec. Some things seem way off or just missing completely... I am not sure. Do these actually work wirelessly with a PS3? I have never tried and I do not own a PS3 .. just looking for cheaper but good wireless controller options for HTPC and didn't want to spend $80-100 for a pair of genuine when they will only be used a few times a month at most!

Hopefully this helps but maybe some of this is irrelevant or just TMI .. just observations that I made. My current conclusion is that it might be nearly impossible to get these controllers like this working since they seem to be this far out of bluetooth spec but it could be also that I just do not know enough about it to be certain.

I am returning the Fivestar controllers and planning to return the Slickblue controllers to Amazon as well pretty soon since the button response is so poor. I will probably return the GAME-O controllers as well at some point when I am ready to give up on the hope for them :) As an aside, does anyone know of decently priced fake controllers that have good button response and DO work wirelessly with ScpToolkit just fine? I would love to know ;)

[joshuagrisham]

And just as a followup ... this GAME-O controller I referenced above works perfectly on Android using Sixaxis Controller. I wonder what the magic is? :) http://forums.pcsx2.net/Thread-ScpToolkit-XInput-Wrapper-aka-ScpServer-Reloaded?pid=514297#pid514297

[nefarius]

@j0shg I actually tried to get in touch with the developer but got no reply sadly.

[joshuagrisham]

@nefarius I have found the one thing to change which fixes PANHAI connecting on bluetooth for me. Here is a patch for BthDongle.L2cap.cs that solves it for me:

133c133
<             var buffer = new byte[10];
---
>             var buffer = new byte[14];
144a145,148
>             buffer[10] = 0x01;
>             buffer[11] = 0x02;
>             buffer[12] = 0xa0;
>             buffer[13] = 0x02;

More information here: http://forums.pcsx2.net/Thread-ScpToolkit-XInput-Wrapper-aka-ScpServer-Reloaded?pid=515994#pid515994

Basically for L2CAP_Configuration_Response changing it to have a 14 byte payload instead of 10 and adding these 4 bytes to the end. You will probably want to test this change with genuine controllers but for my GAME-O pad I mentioned previously this works perfectly.

[joshuagrisham]

@nefarius More info also in this later forum post here thanks to a find by hman77: http://forums.pcsx2.net/Thread-ScpToolkit-XInput-Wrapper-aka-ScpServer-Reloaded?pid=516146#pid516146

Looks like this packet should be very similar to L2CAP_Configuration_Request where MTU option is specified.

buffer[10] = 01 Config Opt: type = MTU (Maximum Transmission Unit) - Hint buffer[11] = 02 Config Opt: length buffer[12] and [13] = MTU (and in case of my PANHAI pad, 0xa0, 0x02 (672), same as in screenshot above as well from @LOSSLOSS )

[cysap1321]

@ManHunter if you didn't managed to make it work here are the steps. I am using the same controller, PS(R) Ga`epad (VID_054C&PID_0268). Following @j0shg's guide, I tried to modify the source code but I had no clue how to continue (build it :D).

After checking the forum he provided I managed to get this piece of gold: http://forums.pcsx2.net/attachment.php?aid=59632 This ScpControl.dll was built for ScpToolkit-1.7.277.16103-BETA, so I installed this version, killed the ScpService, then replaced the dll and restart it. When I unplugged the cable, after 1 second the magic happened and the controller was working via Bluetooth.

Anyway, you guys did a great job here so thank you.

[ManHunter]

@cysap1321 installed ScpToolkit-1.7.277.16103-BETA, replaced your ScpControl.dll but still doesn't work for me(

[LOSSLOSS]

I can confirm this patch is working! Great stuff!

@ManHunter Make sure deinstall everything. (Wipetool possibly) Install beta j0sh pointed out. Make sure it is working through cable like before. Then stop the service and replace the dll. Worked for me!

[sylveon]

If the modified source code for the dll is provided, maybe @nefarius could see into merging the changes.

[cysap1321]

@ManHunter, as @LOSSLOSS suggested make sure to have a clean install and that it works via usb. Also, I should mention that after several re-installs and versions my ScpServer was not even starting anymore, so I did a fresh install of Windows. I would suggest to use a Windows VM first to check if it works ( it should since we are using the same controllers )

[ManHunter]

I deleted all drivers (gamepad, bluetooth, xbox), execute ScpCleanWipe.exe and remove all files SCP Toolkit. Make reboot. Install xbox 360 drivers; Install SCP Toolkit; Run SCP Driver Installer with admin and execute all steps; Download modify SCPControl.dll and replace old; Run SCPServer; After disconnection the gamepad, SCPServer get loop (screenshot).

[cysap1321]

I remember having this loop the first time I installed an older version of the ScpToolkit. I would suggest you to create a Windows Virtual Machine ( ~15min ) and try to install it there. If it is not working, the dll probably won't help you.

[joshuagrisham]

Hi, the patch text I provided above completely represents everything that I had to modify in the source for this to work .. there is really nothing more. I can upload the new version of the file but I assume that @nefarius would know what to do using what I already provided :) basically changing the byte array to 14 length instead of 10 and then adding the last 4 bytes to the end.

Also my modification only probably works if your controller is reporting MTU of 672 as per screenshots in this thread. If your controller is reporting a different MTU then it probably might not work.

Someone on the PCSX2 forums mentioned it is working with both their PANHAI pad as well as a genuine Sony controller at the same time ... wonder if all controllers are reporting either 0 or 672 for MTU ?

If not I have tried to think of a few ways to first fetch the MTU from the controller and then send in this packet. I looked at the stream of bluetooth data in my Wireshark captures both in Linux as well as Windows. In Linux with sixad it is sending a different packet for "get extended features" that is not being sent in Windows by ScpToolkit but when I inspected the bytes in the buffer that is returned I don't see reference to the MTU anywhere, as well as have not noticed it anywhere else in the stream of packets. If it is really needed to first get the MTU and then send the L2CAP Configuration Response packet then I have 2 different ideas. Both are based on the premise that when you send L2CAP Config Response first without the MTU option specified, then when controller sends back a response it does include the MTU in its response. That is how it is able to print the MTU in the log, as well, getting it from this same packet. And again this is all assuming that sending MTU of 672 does not work with all controllers (it might work fine to send 672 for everything.. I just don't know if it does or not!!)

So if sending 672 does not work for everything, here are 2 ideas I had:

1. Send an L2CAP Config Response packet without MTU and then read the MTU from the Controller's L2CAP Config Response packet, and then immediately send another L2CAP Config Response that includes the MTU if the MTU was not 0. The issue I worry about with this option is that I think the PANHAI controller is sending an HCI Disconnect immediately after sending L2CAP Config response without specifying the MTU ... like this is its way of rejecting that packet, by immediately disconnecting and then trying again. Which leads me to....
2. Take the MTU from above that is sent back (again if it is not 0) and then store it in an array maybe with 2 positions: MAC address, MTU. Then allow the controller connection to fail and get into that HCI disconnect > connect request loop. With each pass of the connection, read this MTU array to see if MAC address exists in it before sending the L2CAP config request. If it does, then send the packet with MTU option specified. This means that the PANHAI controllers would try to connect and then fail once, but then should pick up and connect on the 2nd pass. The flow would look sort of like this:

Connect request # 1 > ... > L2CAP Config Response to controller without MTU specified > controller sends back L2CAP Config Response with MTU provided > Store MAC + provided MTU into an array > Controller sends HCI Disconnect .... Connect request # 2 > ... > L2CAP Config Response to controller, but this time the MAC address would exist in the array so we would send with MTU specified > ... > successful connect for PANHAI controllers on 2nd attempt.

Edit: or 3rd option I had considered but forgot about before posting... create a quirk table similar to how it is done for Linux kernel modules, and depending on the controller name and/or MAC address ranges you could send different MTU values. This would rely on having to build in a quirk for each different name that has different MTU than 0 (or is not working without sending MTU option) so it might take time and reports from the community to get them all covered.

Also @ManHunter this loop you posted, that is the connect / disconnect loop that I think is the original issue and what my modified version of the ScpControll.dll tries to address for PANHAI controllers. It is working for me with the beta (tried on my dev laptop where I made the change as well as installed it on my HTPC and working in both places) as well as several people here as well as on PCSX2 forums. A few things I am wondering -- did you install the beta version, and did you stop the Scp DS3 service before trying to replace the ScpControll.dll ? It should probably be located under C:\Program Files\Nefarius Software Solutions\ScpToolkit\ and you can tell if you are using the modified version by looking at the file size of ScpControll.dll -- my file is around 201 KB (206,336 bytes) while the original is around 204 KB (209,408 bytes) .. not sure why mine is smaller with a few lines more of code except that I compiled it in Release configuration in Visual Studio where @nefarius may have compiled in debug mode for this beta.

[Reigninwild]

I installed windows 7 on VirtualBox and still not working. After disconnecting gamepad from usb, I get once MTU-672, Instead loop. My steps:

1. Install windows;
2. Install xbox 360 driver;
3. Install SCP toolkit;
4. Run SCP Driver Installer with admin privileges;
5. Connect gamepad and install drivers;
6. Install driver for bluetooth;
7. Install xbox 360 virtual device;
8. Reboot system;
9. Stop SCP Service;
10. Replace SCPControl.dll (206,336 bytes);
11. Run SCP Server.

[joshuagrisham]

@Reigninwild I am not sure on Windows 7 , I have only tried on Windows 8 and Windows 10. I assume it should work the same however :(

So you are saying it only tries to connect once and then stops? What kind of controller do you have? Is it a PANHAI also? Maybe screenshot or full Service / Server log would be helpful

[cysap1321]

@Reigninwild for the record I have Windows 10. Steps:

1. Install windows 10 as VM
2. Connect controller
3. Install ScpToolkit-1.7.277.16103-BETA ( do a complete install using the installer: xbox driver, bluetooth, gamepad; ScpService will start automatically and your gamepad should work via usb at this step )
4. Replace dll; it should complain about the fact that ScpService is running so kill it
5. Start ScpService
6. Disconnect Gamepad

[ManHunter]

Sorry, @Reigninwild it's me. I forgot change profile on github.

[nefarius]

Daaaaaamn... coming back looking at the progress you guys made, wanted to test it out and my last working PANHAI just bit the dust >_< Bluetooth won't work anymore. Guess I tortured them too much with the soldering iron last time... Won't get a refund I'm afraid X)

[redeven]

@cysap1321 I tried your fix but if I install that BETA build the controller doesn't work at all (not even wired). Is there any way to get the ScpControl.dll for fake gamepads to work with the current stable version? (v1.6.238.16010)

[cysap1321]

@redeven I found this fix on the above mentioned forum, so I guess you need to get in touch with the developer. But I find it unusual that your controller won't work with cable either.

[redeven]

@cysap1321 So... I installed the beta version and replaced ScpControl.dll. Opened ScpServer, it shows the dongle's MAC and detects the gamepad. When wired, it "connects" but the gamepad itself doesn't work, and it doesn't connect at all wirelessly.

[joshuagrisham]

@redeven I went ahead and changed this code on the version 1.6.238.16010 for you and uploaded it back to my original post in the forum. I did not test it (don't have that release installed anywhere!) but assume it should behave in the same way. Here is a link to that post again: http://forums.pcsx2.net/Thread-ScpToolkit-XInput-Wrapper-aka-ScpServer-Reloaded?pid=516013#pid516013

[redeven]

@j0shg It throws an exception: "Couldn't plug in virtual device 1: System.ComponentModel.Win32Exception (0x80004005): The parameter is incorrect" when trying to connect with BT.

[bhw11]

@redeven I get the same but strangely my controller still works with BT. At least for some time before inputs start failing to register. This is using j0shg's fix for both stable and beta versions. Without the fix, the controller only works wired. @j0shg did mention his fix was for PANHAI which doesn't apply to this controller. The controller I'm using identifies as PS(R) Ga`epad (VID_054C&PID_0268), same as OP. I can wait for an official fix and use a cable in the meantime.

On a side-note; the actual controller is so close to the original in terms of build quality and accuracy that no one who has used it so far has any idea it's fake. The only letdown so far has been this issue. Once this has been fixed, I would highly recommend it considering all of the terrible 3rd party controllers on the market.

The seller I bought from ran out of stock but one this looks like the same controller: http://www.ebay.com/itm/172172794441

[redeven]

Well, I've known it was a fake since the moment I bought it. It was worth 13 USD. Also mine identifies as 'PS(R) Gamepad' (everyone else's seems to have a grave accent (`) instead of an 'e').

If there was a guide on how and what to modify on the files so that my gamepad worked, I wouldn't mind doing it myself.

[OfAnthony]

Thank you j0shg! After almost two years, finally got my Panhai fakes working. On both Win 7 and Win 8. I followed all of cysap1321's instructions; only thing I had to do additionally to get the beta SCP to recognize the controllers via USB was to manually delete the drivers for the panhai and any genuine ds3's from the device manager. Then run the new scpdriver...and after that pasting the .dll.....VICTORY!!! Thanks everyone, been waiting for this.

[redeven]

So... some feedback:

• joshg's ScpControl.dll for ScpToolkit-1.6.238.16010 throws an error message ("Couldn't plug in virtual device 1: System.ComponentModel.Win32Exception (0x80004005): The parameter is incorrect") when attempting to connect through bluetooth. v1.6.238.16010 works fine with USB though.
• I tried installing ScpToolkit-1.7.277.16103-BETA and I can't get the gamepad to work, either wired or wireless. A thing I noticed is that the service (SCP DSx Service) won't start. No matter what I do or how many times I try, I can't manually start it and restarting computer won't work. It'll only say Windows couldn't start the service (error 1068). ScpServer correctly detects my BT dongle and MAC address, and it shows the correct information for the gamepad while plugged in but it won't work.

[OfAnthony]

"redeven" did you install the ScpDriver after doing a wipe? I had no success on my first install of SCP-Beta-7.277.16103. After using Nefarious' wipe tool a second time, I went in to my device manager and noticed the Panhai's were showing up with the original scpds3 driver; I still have Scarlet's last working SCP installed, for SCP-Pair. I uninstalled those drivers and had windows re-install the original drivers. I then ran the ScpDriver installer for SCP-Beta-7.277.16103, this time the installer recognized the Panhai's, and when running ScpServer manually the devices showed up connected through USB. I then quit SCPServer, and pasted the modified .dll "j0shg" provided in to the appropriate folder, ran ScpServer again, and the .dll worked! Panhai connected through Bluetooth! I can still use Scarlet's SCP-Pair, however it still doesn't recognize the Panhais. I don't want this running as a windows service, I prefer to manually start SCP, just click next when you get to the "Install Windows Service" during the ScpDriver installer. I have a somewhat complicated system and I was able to get the Panhai's working on two windows machines, an 8.1 laptop with on board Bluetooth and a USB Bluetooth dongle, also got this working on a 7.1 desktop with two Bluetooth USB dongles, one dongle on each system successfully running SCP-Beta-7.277.16103 with Scarlet's last SCP build working as well (For ios pairing). And my genuine DS3's are working too. You'll figure this out, I'm an idiot and I did. Big thanks to Nefarious and j0shg... Thanks a billion, I owe you guys a gift card or something. Now if we can get an updated SCP-Pair for Beta-7.277.16103, that would be perfect...is this possible?

[redeven]

@OfAnthony Yes, I've tried everything. I've checked all services, devices, drivers and programs one by one and removed anything even remotely related to ScpToolkit, gamepads, dongles and otherwise. I clean everything after every uninstall whenever I try switching versions. The Beta version just doesn't work for me.

That's why if someone pointed me on how and what to modify on my own version's ScpControl.dll to make my gamepad's bluetooth work, I'd be more than grateful.

[OfAnthony]

I had some trouble first; one thing I've noticed is that one wipe or one deleting of a driver didn't always revert back to a clean machine. For example I had to delete the drivers for my BT dongle on my laptop twice, only because my on board BT driver replaced the dongle's after the first un-install. It also happened with the genuine DS3s and the Panhais; I had to delete drivers multiple times in order for the beta driver installer to detect the controllers. I never had any problems with Scarlet's original SCP builds, I've only lurked on Nefarious because of the work towards getting the Panhais working. You'll figure this out, maybe running Scarlet's last build and installing his drivers for SCP first and then running the beta might work, I've got both running on two systems manually starting with SCPServer.

[arekhn]

Well, i have four controllers, two from Fivestar (https://www.amazon.com/gp/product/B016XF3S4K/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1)

and two from Exuby (https://www.amazon.com/gp/product/B011D5F8V6/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1) They are all working wired with latest beta, but bluetooh does not tried the fixed dll, but bluetooh doesnt work either, curiosly, mine ones say MTU=672, here´s a screenshot: http://www.mediafire.com/download/lslq7f2jffdfu2s/Captura.PNG

Also i dont know if they are "Panhai" or not xD

[dan83sama]

Thanks @j0shg , finally works panhai, bluetooth and rumble, thank you very much. There any way to increase the power/strenght or sensitivity rumble?, the rumble in games is very low in both usb and bt.

[gunns]

Same problem here but mine appears as PLAYSTATION(3)Conteroller (VID: 054C, PID:0268)

bluetooth appears as PLAYSTATION(R)3Conteroller-ghic (in the log appears this way)

installed everything, when wired it works fine, but when i unplug it, it start flashing the 4 leds and in the SCP server notifications it shows "Genuine Sony DualShock 3 found"

here i attach a log of the scpServer, in timestamp 1464886095612 i pressed the PS button while unplugged, it "tries" to connect but something went wrong.

MTU figures 0 every time.

Thanks in advance.

ScpDsxServer_gustavo.log.xml.zip

[winny83]

Hi I created an account to just say that j0shg's fix works for genuine and fake PANHAI controllers and should definitely be added to the next nefarius build. I have been looking at this kind of fix for ages.

[n00bC0d3]

@LOSSLOSS when you said the patch is working, which bluetooth device it's worked on ? is it "onboard BThost: VID_8087&PID_07DC" ?

Dear All, one question ( sorry if it's a dumb question ) is SCPTool working with built in bluetooth ?

[sylveon]

@n00bC0d3 It depends on your built-in Bluetooth chipset.

I recommend you to try it by yourself.

Although at first try it may seem to work, problems such as #51 may arise.

[Chibliss]

Mine is a ps(r) gamepad that connect to my ps3 game console wirelessly but does not connect to my pc with the Bluetooth but connects with the charger connected on the pc need assistance