ScpToolkit (XInput Wrapper aka ScpServer Reloaded)
joshg, #5 seems to be related to MTU configuration option. It was already implemented in L2CAP_Configuration_Request, but not L2CAP_Configuration_Response...

Here is sample response with this option.

=== HCI header ===
02 2a 20 12 00 0e 00 01 00 - HCI header, as above, please see the L2CAP CONNECTION REQUEST packet structure
 
=== Actual L2CAP command ===
05 L2CAP_CMD_CONFIG_RESPONSE
4c Packet identifier
0a 00 Command payload length
40 00 SCID (Source Channel Identifier, in other words, local endpoint ID)
00 00 Flag 0
00 00 Result 0 (success)
01 Config Opt: type = MTU (Maximum Transmission Unit) - Hint
02 Config Opt: length
3c 00 MTU

joshg
PANHAI update from my side: I got it working wireless and with bluetooth. Smile

I apologize upfront as this is going to get a little technical .... but hopefully not too much!

I set up Wireshark with USBPCap in Windows and ran a capture of the bluetooth traffic by having it capture traffic on the USB bluetooth adapter itself, while attempting to connect the controller through bluetooth.

Then also used Wireshark with libpcap in Linux and did the same thing - captured traffic on the USB interface for the bluetooth adapter.

Using this I was able to determine exactly where they are different.  Because in Linux it had a lot of built in parsing, plus the libpcap is different than usbpcap used for windows, the output was a little different.  So I had to comb through quite a bit and spent about 3 hours analyzing the flow and the individual bytes to finally find where exactly they are different.

So in general different in these few places:

1) When L2CAP_Connection_Request is received, Linux sixad daemon only sends a single L2CAP_Connection_Response with "success" whereas in Windows ScpToolkit is sending 2 individual L2CAP_Connection_Response -- first a "pending" followed by a "success".
2) ScpToolkit L2CAP_Command is defaulting 2nd byte (buffer[1]) of the sent buffer to 0x20 if it is 0x00 ... in Linux sixad it doesn't do this, it always is sending 0x00 .. this is for all sending L2CAP commands
3) ScpToolkit L2CAP_Configuration_Request has hard-coded byte of 0x96 and 0x00 for bytes 11 and 12 (buffer[10] and buffer[11]) but I noticed in Linux sixad that it seemed to match DCID (e.g. for mine it was sending 0x40, 0x00) so I changed this to dcid[0] and dcid[1] so it would put the dest channel in these bytes instead of this hard-coded value 0x96, 0x00
4) ScpToolkit L2CAP_Configuration_Response in the 3rd byte (buffer[2]) I noticed in linux for me it was sending 0x0a here but ScpToolkit has this hard-coded at 0x06. For now I changed it to hard-coded 0x0a. From what I have poked around, this value could actually be coming from the controller itself when original HCI_Connection_Request or HCI_Accept_Connection_Request event occurs (on mine I am seeing this byte 0x0a coming across as the next byte after the command/event identifier)
5) Also in same method L2CAP_Configuration_Response, in linux sixad they have 4 extra bytes on the end of this buffer that do not exist in ScpToolkit.  They are: 0x01, 0x02, 0xa0, 0x02.  The origin of these 4 bytes could possibly be similar to last 4 bytes L2CAP_Configuration_Request and maybe especially this byte 0xa0 could be sent from the controller somewhere in the stream but I haven't found it as of yet.

Anyway with making those 5 changes to both BthDongle.Tasks.cs and BthDongle.L2cap.cs my PANHAI controllers are working perfectly over bluetooth.

I will try to roll back and maybe make each change one-at-a-time to see if there is one specifically that was the real key or not and post an update shortly Smile

Edit: Ok after trying everything off and on I actually found that only ONE of the above changes is needed and it gets the PANHAI working fine.

It is #5 above -- changing L2CAP_Configuration_Response from host to have 14 length payload instead of 10 with 0x01, 0x02, 0xa0, 0x02.  Not sure if each of these values can be hard-coded or if they need to depend on data sent back from the controller, but this should be the only change needed to get PANHAI controllers to connect.

I confirmed by taking a fresh copy of source and only modified BthDongle.L2cap.cs:L2CAP_Configuration_Response and it is working with only this change.

Sponsored links

(04-19-2016, 05:48 AM)radixon3 Wrote: So I've downloaded scp well, everything, its installed fine but my problem lies with my controller not being recognized by windows, i've plugged it into multiple usb ports and a few of them say installing new device drivers or something along those lines, i hear a few beeps and then no lights flash up on my controller, like it doesnt even exist. can anyone help me with this, or did i post in the wrong thread?

Edit- The controller is showing up in devices and printers just fine. Still no battery charging lights and still not detected by scp dualshock 3 setup

Hi radixon3, it almost sounds like there is already a different driver installed for your controllers or the installed driver is disabled or not working right. Have you previously used MotioninJoy or a prior version of Scp?

Which version of ScpToolkit are you using?  Latest stable release 1.6.238.16010 or beta?  The reason I ask is because the driver installer interface is completely different in the beta vs the stable release from January.

If you are using the stable release 1.6.238.16010 then here's what I would do.  

  1. First unplug all of the controllers so that nothing is connected to your PC.
  2. Run the ScpDriverInstaller.exe and click Uninstall
  3. Run ScpCleanWipe.exe and click the button to wipe away any old drivers.
  4. Next I would also go to Control Panel > Device Manager, then click on View > Show hidden devices. Then open up each of the following and delete any grayed-out entries for game controllers
    - Human Interface Devices (they will probably be called something like HID-compliant game controller)
    - libusbK devices (look for PS3 GamePad or PS Gamepad or anything similar)
    - Universal Serial Bus devices (look for PS3 GamePad or PS Gamepad or anything similar)
    - Xbox 360 Peripherals (delete any Xbox 360 controller entries)
  5. After all of this I would then plug the controllers back in to USB and see if they act like they are installing new drivers. Hopefully they should!
  6. After their "driver installation" is complete I would then run the ScpDriverInstaller.exe and install drivers for them (keeping controllers plugged in from step #5 the whole time)


If you are using the latest beta then I am not sure exactly as it looks like ScpDriverInstaller.exe doesn't give any option to remove or uninstall the drivers.  I would probably do each of the following steps above after except excluding ScpDriverInstaller.exe just because I don't think it is possible? (or I don't know where it has been moved in the beta, if it is still possible... Smile  )

Hope this helps and let us know if this fixes it for you!
(04-19-2016, 04:00 PM)hman77 Wrote: joshg, #5 seems to be related to MTU configuration option. It was already implemented in L2CAP_Configuration_Request, but not L2CAP_Configuration_Response...

Here is sample response with this option.

=== HCI header ===
02 2a 20 12 00 0e 00 01 00 - HCI header, as above, please see the L2CAP CONNECTION REQUEST packet structure
 
=== Actual L2CAP command ===
05 L2CAP_CMD_CONFIG_RESPONSE
4c Packet identifier
0a 00 Command payload length
40 00 SCID (Source Channel Identifier, in other words, local endpoint ID)
00 00 Flag 0
00 00 Result 0 (success)
01 Config Opt: type = MTU (Maximum Transmission Unit) - Hint
02 Config Opt: length
3c 00 MTU
Thanks hman77 I believe you are right. I suspected this based on what I was seeing in the code but didn't really dig around in the spec or anywhere else to verify Smile

Also one of my earlier comments regarding MTU and wondering if it is being incorrectly reported using ScpToolkit - well I think now it is being reported correctly because it also comes up in linux as MTU = 672 even detected using the L2CAP standards-based parsing with Wireshark and libpcap.

My ScpControll.dll I posted earlier does not modify to pass the mtu or make the payload length dynamic as was already done in L2CAP_Configuration_Request .. it is more of a brute force. But for a permanent fix (nefarius? Smile ) then I would assume this might need to be done and tested with other controllers (especially genuine ones). I only have these 2 GAME-O pads (PANHAI) so it doesn't really matter for my use to have this forced in the code because it is working for my controllers Smile 

But per your post, it looks like it should be 0x01 (MTU hint), 0x02 (length), then the MTU read from controller.  For mine it is 672 (0xa0, 0x02) which is why it is working with 0xa0, 0x02 for me ... sounds like the correct fix then, in that case!

Also hman77 just as a friendly and hopefully helpful suggestion, it is a little difficult to read your responses because you have quotes mixed with your text and not using the BBcode for [quote] ing someone .. it almost all looks like your own text until I realize that some of it are things that I wrote Smile

Thanks again and good find!
Hey I was using an older version successfully for over a year, but I decided to update to the latest version. Now everytime I reboot the computer it requires me to reinstall the drivers everytime. If I try run any of the programs (e.g SCPToolkit Profile Manager) I get an error saying:

Oh Shi...
A Fatal error has occurred. Consult the logs for details.

I tried looking at the logs but wasn't able to open them, but can anyone help me solve this? Reinstalling every time is a bit of a hassle.
Thumbs Up 
SCP has been working great for my Playstation 3 NAV controller - no issues there.  I have an XBOX 360 controller now so I can play Dark Souls 3 in Steam.  When I connect the XBOX 360 controller it does not work in game.  Shows as responsive in Game Controllers and calibration.  I do note that it identifies itself as second controller via the LED indicator on the controller.  Is this due to the SCP reserving first controller for the PS3 NAV controller when not connected?

If this is the case, is there a way to correct it so I can easily switch between both controllers as required?  Any help would be greatly appreciated.
Unfortunately had to uninstall as I'm getting massive NETWORK lag spikes in ANY game while the controller is paired with the PC (wirelessly).

Eg, when I'm playing Rocket League with the controller active, everything is rubberbanding while playing online and I can see the 'connection error' icon flashing - turn the controller off, problem goes away.

I can see a lot of work has gone into this software and I'd really like to get it working properly Smile

Please help.

[Windows 10 64]
hi guys

so i just bought this fake ps3 controller and decide to try using XInput Wrapper by Scarlet and when i run Driver Installer it just says


Quote:SCP Driver Installer 1.2.0.160 [4/22/2016 7:32:36 AM]

Detected - Microsoft Windows 7 Ultimate Service Pack 1 (6.1.7601.65536 x86)
Could not find a valid configuration.

so i decided to try ScpToolkit and when i run Driver Installer it show this

[Image: ivvwr7r.png]

http://prnt.sc/av9447


i'm using Windows 7 64 bit
i have checked all the software requirement i'm only using USB cable to connect the controller
i've run the Clean Wipe Utility

idk what else to do..
(04-18-2016, 10:10 PM)joshg Wrote: Link back to https://github.com/nefarius/ScpToolkit/issues/241

And screenshot of both PANHAI pads connected via bluetooth using this code modification  Smile

Also I have attached a modified ScpControll.dll zipped in this post if anyone has a PANHAI fake DS3 controller and has been desperately wanting it to work wirelessly for them while waiting on a permanent fix. Smile This was built against ScpToolkit-1.7.277.16103-BETA so you would probably need to use that same version with this file.

My PANHAI controler and a genuine SONY are working perfectly wirelessly (sadly, SONY controller is "broken).

Thanks to Nefarius for his Toolkit and for your modified SCpcontrol.dll .
(04-19-2016, 04:08 PM)joshg Wrote: Hi radixon3, it almost sounds like there is already a different driver installed for your controllers or the installed driver is disabled or not working right. Have you previously used MotioninJoy or a prior version of Scp?

Which version of ScpToolkit are you using?  Latest stable release 1.6.238.16010 or beta?  The reason I ask is because the driver installer interface is completely different in the beta vs the stable release from January.

If you are using the stable release 1.6.238.16010 then here's what I would do.  

  1. First unplug all of the controllers so that nothing is connected to your PC.
  2. Run the ScpDriverInstaller.exe and click Uninstall
  3. Run ScpCleanWipe.exe and click the button to wipe away any old drivers.
  4. Next I would also go to Control Panel > Device Manager, then click on View > Show hidden devices. Then open up each of the following and delete any grayed-out entries for game controllers
    - Human Interface Devices (they will probably be called something like HID-compliant game controller)
    - libusbK devices (look for PS3 GamePad or PS Gamepad or anything similar)
    - Universal Serial Bus devices (look for PS3 GamePad or PS Gamepad or anything similar)
    - Xbox 360 Peripherals (delete any Xbox 360 controller entries)
  5. After all of this I would then plug the controllers back in to USB and see if they act like they are installing new drivers. Hopefully they should!
  6. After their "driver installation" is complete I would then run the ScpDriverInstaller.exe and install drivers for them (keeping controllers plugged in from step #5 the whole time)


If you are using the latest beta then I am not sure exactly as it looks like ScpDriverInstaller.exe doesn't give any option to remove or uninstall the drivers.  I would probably do each of the following steps above after except excluding ScpDriverInstaller.exe just because I don't think it is possible? (or I don't know where it has been moved in the beta, if it is still possible... Smile  )

Hope this helps and let us know if this fixes it for you!


So i followed all these steps and when I run ScpDriverInstaller and install the drivers, I get a bunch of windows that pop up and then my mouse becomes inoperational and the only way to get it working again is to do a system restore. There's also a big long error window that pops up with many references to something called dbreeze somethingorother.
(04-23-2016, 11:45 AM)Velz Wrote: So i followed all these steps and when I run ScpDriverInstaller and install the drivers, I get a bunch of windows that pop up and then my mouse becomes inoperational and the only way to get it working again is to do a system restore. There's also a big long error window that pops up with many references to something called dbreeze somethingorother.

Velz is your mouse wireless with Bluetooth?  If so then you may not be able to use it with ScpToolkit.. I know that Nefarius was looking into a way to avoid having the driver for the bluetooth adapter completely taken over so that you could still use other bluetooth devices but I am not sure what the status on this is or if it is even possible.




Users browsing this thread: 6 Guest(s)