Controlling DS4 input programmatically (PC)



  • That's perfection, amazing.
    What's the best way to clear a set button? send an empty/null report? set to null first and then send a report?

    Cheers



  • That's where the .NET implementation is currently a bit dumb; you can only submit a full report with all state changes, meaning if you want to unset only one button, you need the previous report object, unset it there and submit it again. The new API/branch has this solved more elegantly.



  • I see, looking forward to the new implementation! Is there some alpha/beta code out already?

    By the way, my understanding is that the default (no button set) state is this:

    Buttons &= unchecked((ushort)~0xF);
    Buttons |= 0x08;

    So basically I need to set the buttons value back to that value, or create a new report (which has the default) and pass that.



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

    I see, looking forward to the new implementation! Is there some alpha/beta code out already?

    There is but I'd rather not publish it. I have learned my lesson; people somehow don't understand what "unfinished" means and latch onto it and then waste my time reporting bugs that are none because the design isn't even finished. No offense to you but I've had too many negative examples. Once I start working on it again I'll report progress on the forums.

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

    Buttons &= unchecked((ushort)~0xF);
    Buttons |= 0x08;
    So basically I need to set the buttons value back to that value, or create a new report (which has the default) and pass that.

    You got it.

    Cheers



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

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

    I see, looking forward to the new implementation! Is there some alpha/beta code out already?

    There is but I'd rather not publish it. I have learned my lesson; people somehow don't understand what "unfinished" means and latch onto it and then waste my time reporting bugs that are none because the design isn't even finished. No offense to you but I've had too many negative examples. Once I start working on it again I'll report progress on the forums.

    Of course, I totally understand. I guess people underestimate the meaning of alpha and/or beta.
    When it's ready I'd be happy to try/experiment with the very first version πŸ™‚



  • Be my guest, we've done "private" alpha/beta group testing with various components before, I myself use the new library already in a project so it will definitely gain more traction once my mind is free from Bluetooth and... other things πŸ™‚



  • Best of luck with that. I cannot even start to imagine how complicated/tedious that sort of thing can be. Luckily, it seems we've got one of the best minds working on that!

    By the way, I was thinking of attempting to create some bindings for Java, for the old client (feeder), through JNI/JNA (I'll experiment). I know it'd be throw away work mostly, but that's the only thing published right now that I can work with.

    Have you by any chance experimented with ViGEm running on a VM with a remote play instance running in it? Would such setup work?



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

    Best of luck with that. I cannot even start to imagine how complicated/tedious that sort of thing can be. Luckily, it seems we've got one of the best minds working on that!

    I didn't know either what would hit me three to four years ago πŸ˜†

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

    By the way, I was thinking of attempting to create some bindings for Java, for the old client (feeder), through JNI/JNA (I'll experiment). I know it'd be throw away work mostly, but that's the only thing published right now that I can work with.

    Be my guest, you won't see any Java wrappers from me πŸ™‚ And one thing I learned: no code is complete throw-away, sooner or later I come back and recycle 😜

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

    Have you by any chance experimented with ViGEm running on a VM with a remote play instance running in it? Would such setup work?

    Sure, I developed ViGEm in a VM and it runs without issues. I have never worked with RemotePlay though as I do not own a PS4. I have a PS3 I only bought so I could reverse engineer the Bluetooth stack (my life is strange, I know) which is now done so I should probably sell it sometime soon...



  • Cool. I'll give it a try (running in VM and to create Java bindings, perhaps using javacpp).

    By the way, is there some installer for the driver or the only way currently is the PowerCLI way?



  • @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 πŸ˜ͺ )



  • 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.

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



  • @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 πŸ˜‰



  • @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" πŸ˜‰



  • I've put together a very (very) simple solution to invoke the client API from Java, using JNA. I should mention it only supports DS* calls for now.

    All calls but one seem to be working fine. Specifically, VIGEM_API BOOL vigem_target_is_attached(PVIGEM_TARGET target); never returns true, even when the target is actually attached and I can send reports to it. Perhaps I got the API wrong?

    Isn't that API call supposed to be used right after a vigem_target_add call (with polling for instance) to ensure that the device is attached before starting to send reports?

    Cheers



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

    All calls but one seem to be working fine. Specifically, VIGEM_API BOOL vigem_target_is_attached(PVIGEM_TARGET target); never returns true, even when the target is actually attached and I can send reports to it. Perhaps I got the API wrong?

    Oh? That's odd, it's expected to return TRUE when the bus has brought it to working stage. This application uses the API so I suspect it to function properly πŸ€”

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

    Isn't that API call supposed to be used right after a vigem_target_add call (with polling for instance) to ensure that the device is attached before starting to send reports?

    vigem_target_add is blocking until the device is truly operational and calling vigem_target_is_attached afterwards is expected to return TRUE.

    Cheers





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

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

    All calls but one seem to be working fine. Specifically, VIGEM_API BOOL vigem_target_is_attached(PVIGEM_TARGET target); never returns true, even when the target is actually attached and I can send reports to it. Perhaps I got the API wrong?

    Oh? That's odd, it's expected to return TRUE when the bus has brought it to working stage. This application uses the API so I suspect it to function properly πŸ€”

    In fact, I used that code as a reference and I was expecting it to work like you described, but it didn't. Everything else is working fine. I've actually integrated it with some tools that I have and it works like a charm.

    Hats off to you sir! You've done an excellent job πŸ™‚

    I'll try that specific API again, see if I did something wrong in the first place.



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

    Hats off to you sir! You've done an excellent job

    Years of stealing studying other peoples C/C++ code got me there, and for my first real public API it's surprisingly solid and even considers backwards compatibility, the wet dream of every Windows developer πŸ˜›

    But thanks, appreciate it.

    If it still bombs for whatever reason maybe we can spin up a quick debugging session; I'm always on the bug-hunt πŸ”«



  • This post is deleted!


  • Had to signup to thank you for this...

    within 20 minutes, I had it installed and sending buttons to remote play.

    then...
    Used a real xbox one controller with xinput, and mapped all the controls.

    now have a nice little app to let you use remote play with an xbox controller, without having a real PS4 controller plugged in.


Log in to reply