Group Details Private

administrators

 

Member List

  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    @daltz333 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Quite interesting research. So putting this into simple terms, the filter driver will pickup the DS4 and will interpret it's requests instead? Which is bad because the DS4 has bluetooth support already.

    The filter is stupid and has no idea what kind of device is connecting, it looks for Protocol/Service Multiplexer values 0x11 (HID Control) and 0x13 (HID Interrupt) and patches them to artificial values the profile driver listens on. So now the profile driver is in charge of handling the connection requests. The profile driver needs to know what kind of device connects because anything else than the PS3 peripherals could in theory use those PSMs as well. Now we also know that the DS4 tries them as well for whatever reason. It doesn't need to because it has a valid SDP record but I guess it does it to "poke" the Bluetooth host and switches to native PS4 mode if the PSMs get accepted. Who knows what would happen then.

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    @nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Oddly enough I wasn't able to find an official way to get the remote device name from an incoming connection, just the MAC address. This isn't a showstopper but odd and annoying for device identification. Or am I missing something

    Wait a minute... if I got this right, calling IOCTL_BTH_GET_DEVICE_INFO returns a BTH_DEVICE_INFO_LIST containing BTH_DEVICE_INFO which can then be matched against address and contains a name member:

    Name of the remote Bluetooth device, as reported by the device, encoded in UTF8. The user may have locally provided a display name for the remote Bluetooth device; that name is overridden, and does not appear in this member; it is accessible only with a call to the BluetoothGetDeviceInfo function.

    Bingo! The name isn't a 100% safe to rely on in device identification compared to the MAC address, but it's the best shot. It's important to react differently depending on the device type (DualShock 3, Navigation Controller, Motion Controller or DualShock 4 a.k.a. Wireless Controller). This is how it's currently done in WireShock:

    BD_ADDR_FROM_BUFFER(clientAddr, &buffer[3]);
    
    ULONG length;
    
    //
    // Scan through rest of buffer until null-terminator is found
    //
    for (length = 1;
    	buffer[length + 8] != 0x00
    	&& (length + 8) < NumBytesTransferred;
    	length++);
    
    //
    // Store remote name in device context
    //
    WireBusSetChildRemoteName(
    	Device,
    	&clientAddr,
    	&buffer[9],
    	length
    );
    
    switch (buffer[9])
    {
    case 'P': // First letter in PLAYSTATION(R)3 Controller ('P')
    	WireBusSetChildDeviceType(
    		Device,
    		&clientAddr,
    		DS_DEVICE_TYPE_PS3_DUALSHOCK
    	);
    	break;
    case 'N': // First letter in Navigation Controller ('N')
    	WireBusSetChildDeviceType(
    		Device,
    		&clientAddr,
    		DS_DEVICE_TYPE_PS3_NAVIGATION
    	);
    	break;
    case 'M': // First letter in Motion Controller ('M')
    	WireBusSetChildDeviceType(
    		Device,
    		&clientAddr,
    		DS_DEVICE_TYPE_PS3_MOTION
    	);
    	break;
    case 'W': // First letter in Wireless Controller ('W')
    	WireBusSetChildDeviceType(
    		Device,
    		&clientAddr,
    		DS_DEVICE_TYPE_PS4_DUALSHOCK
    	);
    	break;
    default:
    	TraceEvents(TRACE_LEVEL_ERROR,
    		TRACE_INTERRUPT,
    		"Couldn't determine device type from remote name (%c)",
    		buffer[9]
    	);
    	break;
    }
    

    I've discovered that a DS4 (Rev1) paired in PC-mode will also try to directly connect with PSM 0x11 and 0x13 in addition to the correct 0x01 and gets denied. It continues to work though; my best guess is that the controller simply tries if the Bluetooth host is a PS4 and changes its behavior accordingly. This is unfortunate for my profile driver, because now I need to know that it is a DS4, not a DS3, and deny the connection request because the filter will rewrite the PSMs as well. This rabbit hole... 😡

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Oddly enough I wasn't able to find an official way to get the remote device name from an incoming connection, just the MAC address. This isn't a showstopper but odd and annoying for device identification. Or am I missing something πŸ€”

    posted in Research & Development
  • RE: Controlling DS4 input programmatically (PC)

    @nefarius said in Controlling DS4 input programmatically (PC):

    Sorry to beat around the bush but I don't like talking about unfinished business

    don’t count your chickens before they hatch

    Seems like the closest English translation to the German figure of speech "ΓΌber ungelegte Eier spricht man nicht" πŸ˜‰

    posted in Discussion and Support
  • RE: DS4 Extended Support

    @tbpanda said in DS4 Extended Support:

    I feel really bad for resurrecting such an old thread, but I don't think a new one is necessary in this case.

    I was just wondering - is this still planned/being worked on? This functionality could really help Davidobot's BetterJoyForCemu development, and definitely would help everyone who's using it with their Joy-Cons.

    No worries. It's still on the road map but overshadowed by other tasks regarding the DS3 and other projects in the framework. And with way too little manpower as we currently are I can't give reliable estimates πŸ˜•

    If it's really such a big thing we could discuss the need in greater detail ofc. I have no experience with the tools you mentioned nor am I in contact with dev or user base so I can't judge the demand.

    posted in Discussion and Support
  • RE: Controlling DS4 input programmatically (PC)

    @harry said in Controlling DS4 input programmatically (PC):

    Of course, I wouldn't be asking for anything. PowerCLI gets the job done just fine, so everything's good. I was just wondering if I've missed something.

    PowerCLI... I've spotted a VMware user it seems πŸ˜‰

    @harry said in Controlling DS4 input programmatically (PC):

    By the way, do those legal stuff have anything to do with the work you've been doing on this?

    It has indeed. I will shed light on it in greater detail in a dedicated news post. Sorry to beat around the bush but I don't like talking about unfinished business πŸ˜‰

    posted in Discussion and Support
  • HID-related stuff - link collection posted in Research & Development
  • RE: Controlling DS4 input programmatically (PC)

    @harry PowerShell is the way to go until things have cooled down and I can work on a new setup-based installer and publish a long awaited new release. The government is currently holding me back (no, I'm not in prison, I'm waiting on some important legal documents to get processed πŸ˜ͺ )

    posted in Discussion and Support
  • ScpToolkit Removal Guide

    Manual removal of ScpToolkit residue

    This article will walk you through the process of removing any traces of various versions of ScpToolkit from your machine 😊

    How to determine ScpToolkit version

    If you're not sure if you're either running version 1.6.x or 1.7.x you can check this by going to Programs and Features and inspect the version column like demonstrated below:

    0_1547648849469_93cffbdb-ab71-4467-8c36-3d411e25a17c-image.png

    In this case, version 1.6.x is installed and the according removal procedures apply.

    Hint

    If you don't find this entry because your installation is damaged or partially removed, don't worry, just read on and try all the steps provided in this guide!

    Stop processes, remove the service

    Attention

    Make sure to run the following commands in an administrative prompt!

    These instructions terminate all SCP components that might currently run:

    taskkill /F /IM ScpServer.exe
    taskkill /F /IM ScpMonitor.exe
    taskkill /F /IM ScpTrayApp.exe
    

    Should look similar to this output (notice that the server wasn't running, therefore displaying an error):

    0_1547641629603_kill-scp-processes.png

    If none were running, that's perfectly fine, just continue.

    Now let's stop and delete the background service:

    sc stop Ds3Service
    sc delete Ds3Service
    

    Resulting in:

    0_1547641585980_remove-scp-service.png

    Hint

    Depending on your installation, the service might not be installed. In that case, just ignore reported errors.

    Remove drivers from v1.6

    Attention

    For this procedure to work properly make sure you've got your controller(s) and Bluetooth dongle(s) connected. If you don't have enough USB ports just repeat the described steps for each device, plugging it in one after another.

    Download and run the DriverStore Explorer tool. We'll use this to safely remove the driver files from the system. Make sure to run it with administrative permissions!

    You'll be presented with a list of drivers found on your machine:

    0_1547643404037_rapr-scp-devices.png

    The highlighted entries belong to the toolkit installation. Select those, tick the Force Deletion box on the right and then click Delete Package:

    0_1547643433501_2018-09-29_13-20-55.png

    Confirm the, uhm, confirmation πŸ˜ƒ

    0_1547643923904_rapr-remove-confirm.png

    A few moments later they shall be gone:

    0_1547643936838_rapr03.png

    Sweet! Now we need to instruct Windows to revert the devices to their default drivers. Open Device Manager and look for a node titled libusbK USB Devices:

    0_1547643952460_libusbK-highlighted.png

    Expanding said node shall reveal the devices running under SCP's drivers:

    0_1547643969053_device-highlighted.png

    Right-click on each of those and select Uninstall:

    0_1547643983556_device-uninstall.png

    We're sure we wanna do that πŸ˜‹

    0_1547644009420_uninstall-ds3-confirm.png

    Same goes for the Bluetooth host:

    0_1547644023469_uninstall-bth-confirm.png

    Pitfall

    You might think that you're done now but there's a twist! A copy of the driver can still remain in memory and therefore won't be deleted. I strongly recommend you re-plug all devices and check if they are still running under the SCP drivers!

    If your controller or Bluetooth dongle is still showing up in the libusbK node, right-click, uninstall and re-plug until it's gone for good 😲

    0_1547671644075_2019-01-16 21_44_43-Device Manager.png

    Observe and repeat carefully or you'll be left with unusable devices ☝

    If you've done well, this is how your devices should pop up as again:

    0_1547672112662_ff77611b-ba07-466f-89da-c75a716d081c-image.png

    Great! Now there's the Bluetooth dongle back running the default Windows drivers and the controller is under Human Interface Devices where it belongs πŸ‘Œ

    Remove drivers from v1.7

    The procedure for 1.7 is very similar to the steps described for 1.6 above, except that the node you'll find the devices under is called Universal Serial Bus devices:

    0_1547673297195_898c75c5-3a06-436d-a617-78f2628f126c-image.png

    In Driver Store Explorer, things will pop up slightly different, nevertheless select and force removal:

    0_1547673555323_6af98579-e5ee-4e6c-b141-c25e9e514092-image.png

    Then, in Device Manager go through the same "right-click, Uninstall" procedure:

    0_1547673657863_77217807-da5e-4010-a910-c64cf48059b2-image.png

    Rinse and repeat until the devices won't show up under this node anymore.

    Remove SCP Virtual Bus driver

    While still in Device Manager, expand the System devices node:

    0_1547648277693_16bc680c-3bce-4c67-b63a-7d9270bcb456-image.png

    Locate the device named Scp Virtual Bus Driver:

    0_1547648357371_c1d504bc-b769-4114-8520-90cfe6ff032f-image.png

    Same deal here; right-click, select Uninstall and confirm:

    0_1547648432765_0e145c30-934b-4c9e-a1c1-9bcdefe55e7e-image.png

    Remove program files

    As a last step you can now safely delete the ScpToolkit installation directory, typically C:\Program Files\Nefarius Software Solutions\ScpToolkit (may be subject to change depending on your installation, consult your brain memory to find the correct path πŸ˜‰ )

    Congratulate yourself and reboot

    You've done it! πŸŽ‰ You escaped the curse! Give yourself a pat on the back and reboot your PC, just to be sure πŸ˜‰

    posted in Guides & Documentation
  • RE: I've taken the old blog offline

    A refresher: I've migrated all of the posts to the archive, have a browse there if you're looking for an old post! 🀠

    posted in News & Announcements