..:: PCSX2 Forums ::..

Full Version: DS4 To XInput Wrapper
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(02-26-2014, 09:33 PM)InhexSTER Wrote: [ -> ]I will be releasing 1.2.2 shortly with some fixes including that. Main new feature of 1.2.2 will be quick BT disconnect. As it talks to Win API will have to see how it works for everyone, so far we have tested on dev machines it works well.

Great! So, is there a chance to include "idle timeot" function in the next version of your tool?
(02-26-2014, 10:45 PM)itakumre Wrote: [ -> ]Great! So, is there a chance to include "idle timeot" function in the next version of your tool?

It's definitely doable, i don't want to add too much to 1.2.2, as i want to release it today. And since i think soon we will be switching to using controllers unique IDs to store configs instead of by number i don't want to write code that will have to be rewritten soon anyways
I tried on my game machine (Windows 8.1) and i can confirm that DS4ToolServiceTester require admin rights.
But it's working flawless, the service is created correctly, correctly disposed on close and the log is read correctly both into the Tester and into the System EventLog (btw, i'm curious to know if someone is experiencing strange log messages in DS4ToolServiceTester, like i do on my home dev machine).

The only flaw is that DS4Tool is not receiving messages correctly, thus no controller show up.
The workaround for now is to launch DS4ToolServiceTester (tomorrow i will change name to Tester, the current name is too long Laugh ) AND DS4Tool with admin rights.

I've already some thought on what should be the cause and some possible workaround.

In the meantime i did some extra refactor, moved some stuff around, clean a little bit and so on. Ah, i also broke the Classic Window Style, sorry guys, only Metro until i fixed everything. Blush

I update another version with some minor fixes compared to the previous version, i hope this time it will work! (REMEMBER: admin rights for both Tester and client)

If someone is interested, it's worth to explain how everything is working at the moment: because it's important to discuss this service thingy before doing the hard work.

The first thing that i'm testing is sending message from DS4ToolService to DS4Tool and to accomplish this the best way is to use a NamedPipe through WCF. The problem is that in our case we want to receive message on DS4Tool asynchronously and as far as i know the only way is to have his Pipe set as a server, where the Pipe of DS4ToolService is set as a client.
This complicates things, because we can't have a PipeClient asking for connection before the PipeServer exists (and considering that in our case the PipeClient is a service it exists way before his PipeServer).
The actual workaround (and probably it's this that force DS4Tool to work with admin rights) is using another communication protocol to handle command from DS4Tool to DS4ToolService that is called ServiceController: it's a lot simpler, it's oneway only and it accept only integer value where every int is a different action that the service should execute.
I'm using it to inform DS4ToolService that there is a PipeServer where it could connect to. (When this happens you see on the log a message that inform you of a client that is now connected to the service).

Any thoughts?

EDIT: As always remember that this is just a proof of concept of GUI behavior and not a functional application.
@Donbabbeo
Please when you upload this, clearly state that this is not functional version. (only meant to show how GUI could be working in 2.0)
I think some people might get confused thinking its actual release.
ScpServer.exe will be in a way turned into the service. So GUI will be gone, so the all the updates that go to GUI should be sent to the client through TCP.
Loving dat new avatar inhexster Smile

Looking forward to testing 1.2.2 tonight!
(02-26-2014, 11:11 PM)InhexSTER Wrote: [ -> ]@Donbabbeo
Please when you upload this, clearly state that this is not functional version. (only meant to show how GUI could be working in 2.0)
I think some people might get confused thinking its actual release.

Ops, my bad. I always state it clearly but i forget to do it this time, i will edit immediately.

(02-26-2014, 11:11 PM)InhexSTER Wrote: [ -> ]ScpServer.exe will be in a way turned into the service. So GUI will be gone, so the all the updates that go to GUI should be sent to the client through TCP.

Mmm, why TCP? Huh
Honestly i don't see the point. Technically i'm using WCF to instantiate the communication client-service, so switching from NamedPipe (that i'm using) to HTTP or whatever is a matter of couple rows but why TCP?
(02-26-2014, 11:51 PM)Donbabbeo Wrote: [ -> ]Honestly i don't see the point. Technically i'm using WCF to instantiate the communication client-service, so switching from NamedPipe (that i'm using) to HTTP or whatever is a matter of couple rows but why TCP?

TCP with lets say simple socket connection (messages passing) doesn't need any admin rights, very simple to program too. Can be used practically by any language
You're talking about control communications, not data. Configuration changes do not need to be communicated with low overhead or latency; they need to be ACCESSED with low overhead and latency, which is why we should look into snapshotting the Global structure (i.e. just a simple clone or dup or whatever C# calls it). We will need to switch to requiring privilege for configuration if we ever introduce something like vmulti that can allow us to participate in the Windows Secure Acknowledgement Key/whatever they call it these days. That's just a simple matter of switching a few lines and suddenly we're talking named pipes instead of TCP sockets.
Hey InhexSTER !

I am loving the ds4 tool it runs perfectly for me with a Asus BT211.

I was wondering if you can add an option to turn off the controller from the ds4 tool ? I know you can do that by holding the ps button 10 seconds but that starts my steam bigpicture and is rather anoying.
I imagine there there will be a TrayMonitor app that will need to communicate with the service. The service will be sending data if something is changed, TrayMonitor will receive data and react to it. All through Publish–subscribe pattern this will help minimize any operations needed for trayMonitor and service
Example through socket you can send message "controller connected" with its values. And all trayIcon has to do is update the list of controllers. And so on.