Add touchscreen support for the Dualshock 4 touchpad

[NeoTechni]

I use ViGEm for using a tablet with game controls for remote play, which is better than Vita except clicking the touchscreen doesn't send touchpad events to the PS4. Could you please add this?

[saidsay-so]

Hi!
Is there any news for this feature ? I need it for a project and I made some changes in my branch which can maybe help you.

[nefarius]

No news. Driver needs to be modified as well for this, probably API-breaking changes for existing users, a new round of testing, WHQL etc. this isn't trivial to implement and currently not promising with my available resources.

[fortheart23]

Hi!
Is there any news for this feature ? I need it for a project and I made some changes in my branch which can maybe help you.

Hi) Can you please add the ability to emulate the full touch pad and gyro, for playstation now?

[saidsay-so]

Oh crap, I thought that only the report needed changes. I understand now if you can't implement it.

[Blackbird88]

I thought I was going crazy when RPCS3 didn't detect any gyro movement from the Virtual DS4 so yeah this would be really useful!

[nefarius]

See my previous comments. I'm aware this is a useful request but I don't have the capacity nor the motivation to touch this in the near future.

[NyaomiDEV]

R I P
This would be quite useful indeed

[Davidobot]

@musikid @nefarius
I managed to implement (and test) gyro + accel passthrough. It required just changing the structure of the DS4Report. I just recompiled the Bus with the new Common.h and it worked perfectly.

There is meant to be another byte (//BYTE bBatteryLvl;) according to the HID report but it seems ViGEm was either inserting something there already (or some other magic). So I found that that specific HID structure worked.

To test this, I implemented two new methods - SetIMUValue and SetTimestampValue into ViGEm.NET and then used them in my project BetterJoy. I ran tests using a modified version of DS4Windows that allowed emulated controllers to be picked up, and then visualised the gyro/accel in PadTest.

The test setup works quite well, so it would be viable to test and implement the touch API through this as well. DS4Windows has the full DS4 report break-down.

[nefarius]

@Davidobot nice work! Now I just need a way to not completely nuke backwards compatibility... 🤔

[Davidobot]

@nefarius I was toying around with the idea of having a separate 'special' DS4Report structure that gets appended onto the main DS4Report. There are quite a few references to DS4Report in the code though, so I'll have to carefully comb through that.

I was wondering - do you know why there is no need for the bBatteryLvl offset? According to all HID report documentation I read, there must be a single byte to indicate battery level there. Does the Bus splice the byte in? If so, do you know where in the code it happens?

[nefarius]

@Davidobot actually despite the report structure coming in from the API being shorter, I actually initialize the full size report with default values so it matches the size in the HID Report Descriptor.

If we compare your modification to this documentation of the report structure, there should be a 3 byte padding required separating the Right Trigger byte and the Gyro X byte.

If we ignore the remaining data, the report structure of yours with the battery commented out has a size of 23 bytes (ignoring the one always reserved for Report ID), which according to the docs would be one missing.

Are you sure you're testing with the version that has the battery commented out? Happened to me a lot debugging outdated binaries and wondering WTF was going on 😆

[nefarius]

I looked into the unspeakable horrors of the past and it appears that battery level info sits at byte 30 (like with the DS3).