Question about DualSense features

[grill2010]

I saw that there was a pull request 2 years ago

#1

I know that SDL2 can access the motion data and touchpad data but I guess these APIs are not (yet) accessible via Jamepad? Is this correct? For my application it's necassary to support this.

[MrStahlfelge]

Yes it is not accessible via jamepad - yet. Happy to review any PRs

[grill2010]

Okay will check it out. Which class is a good starting point to implement that feature? Did not yet check out the source code to be honest.

[Yontipon]

I'm not really an expert on this, but I think I have some information that will be useful to you, so I'll share what I know.

It sounds like you'll need to implement new native methods that interface with SDL. Assuming the device you're using registers as a "GameController", you'll probably be adding new methods to ControllerIndex.

https://github.com/libgdx/Jamepad/blob/master/src/main/java/com/studiohartman/jamepad/ControllerIndex.java

It uses gdx-jnigen, so the comments after the native methods are the actual code that gets compiled (I think it's either C or C++).

As far as what to put in the methods, you can find a reference of SDL functions here:

https://wiki.libsdl.org/SDL2/CategoryAPI

You'll probably want the functions that start with "GameController". Touch functions have "Touch" or "Touchpad" in the name. Motion seems to be handled with functions containing "Sensor". Sensors have 2 types: Accelerometer and Gyroscope.

https://wiki.libsdl.org/SDL2/SDL_SensorType

[MrStahlfelge]

In addition to what Yontipon wrote, I usually dig through the SDL sources. When you clone Jamepad locally, the sources are available.

[grill2010]

Okay thanks for the information, I will check it out when I have time. I found some examples in other repos which are already supporting some of that features, so I have some kind of reference here. I'm on Windows mainly what's the easiest way at the moment to compile Jamepad on my machine to test my changes?

[grill2010]

@MrStahlfelge saw the build instructions so I guess building takes place on Linux? Are these instructions up to date? I have of course some dev Linux machines as well, just my main dev PC runs on Windows. So if I start to play around with some features I will build them on Linux and will check if the features are working for my DualSense and DualShock controller and if they do I will make a pull request, would that work for you?

[MrStahlfelge]

Best is to take a look at the GitHub workflow file. It builds the snapshot and releases, so yes, it is up to date by definition. :)

Yes, that would work for me. Best is if you test on Linux and Windows at least. I don't own a controller with these special features myself to test. By the way, are you using libgdx/gdx-controllers?

[grill2010]

Okay will try to do that, features should be platform independent as far as I know though (and as far as I have seen on other repos which are using SDL2 for these features). No I'm not using libgdx for my project.

[MrStahlfelge]

Usually the features are platform-independant, yes. But it is always good to test :)

[grill2010]

I will test them of course as my application will be published for Windows and Linux

[Yontipon]

To clarify about the workflows and compiling: if you enable Actions in your Github fork, then push to the main branch, the workflow will automatically run and compile the natives. You can check the Actions tab to find the workflow run, and at the bottom it will have a file called "output-libs", which contains the jar with the natives in it.

The workflow run will always report that it fails, since it can't publish without the original credentials, but it gets far enough to compile the natives. If you want to work on a branch other than "main", you can edit the top of the workflow file to add the name of your branch to the list of branches it runs on.

[grill2010]

@Yontipon thanks, that would be a lot easier I guess. I think it's wort to get familiar with the GitHub actions then. All I want for now is to have a possibility to build and test the lib as fast as possible and this definitely sounds easier then doing it the manual way on my dev machines. Main branch is fine I guess for what I'm doing. So, as far as I have understood you correctly the GitHub actions will be able to build the lib which I can then use for testing but the overall job will fail as it can't publish the libs (as expected of course)?

[Yontipon]

Your understanding seems correct, except that the file produced by the workflow is only the native (C++) code. I believe that a complete jar, including the java code, would be uploaded if the publish script succeeded. There may be a way to get the full jar, but that's not what I did.

I was editing the project as part of an update to gdx-controllers. gdx-controllers uses Gradle to depend on the project, so to test changes, I depended on my local version of Jamepad's source code, and my downloaded copy of the compiled natives. The setup was a bit finicky, but I got by.

I can show you an example of a workflow run from my repository:

https://github.com/Yontipon/Jamepad/actions/runs/4865185521
(Note for the future: this link will break at some point.)

At the bottom, you can see that "output-libs" was produced. It's a zip that contains "Jamepad-2.26.5.0-SNAPSHOT-natives-desktop.jar", which is the natives I provided to make it work.

I was editing an existing Gradle project, so I never learned to set one up, but if you want, I can show you the changes I made to use my code locally.

[grill2010]

If you could show me of how you got it to work it will probably save me some time :)
I will start playing around with it soon so and like I said if I get quickly a test jar which I can test new features easily that would be great.

[Yontipon]

First, I put the two project folders in the same folder. In gdx-controllers (the project using Jamepad) created the "libs" folder, and I put the jar with the natives inside it.

In the file "settings.gradle" of gdx-controllers, I added:

include ':Jamepad'
project(':Jamepad').projectDir = new File('../Jamepad')

In the file "build.gradle" of the Desktop project of gdx-controllers (not the outer project), in the "dependencies" section, I replaced

api("com.badlogicgames.jamepad:jamepad:$jamepadVersion") {
exclude group: 'com.badlogicgames.gdx', module: 'gdx-jnigen-loader'
}

with

implementation files('libs/Jamepad-2.26.5.0-SNAPSHOT-natives-desktop.jar')
api project(":Jamepad")

I imported both projects in Eclipse (though it sound like people don't recommend Eclipse anymore). I know I also played around with adding the native jar as an external library to the Eclipse project, but I forget if that ended up being necessary.

After that, I was able to compile and run with my changes reflected. Note that you need to push to Github and download the natives again if you change any native code. You can check the files I mentioned in libgdx/gdx-controllers if you want to see more of what's in them.

[Yontipon]

A few more things I thought of: You'll need your IDE's Gradle plugin (I think my Eclipse came with it). You'll want to import the projects as Gradle projects. If changes aren't being reflected, you might need to highlight your projects, right click, and pick Gradle -> Refresh Gradle Project. Jamepad uses a pretty old version of Gradle, so if you make a new project with a new version of Gradle, you might have problems compiling them together like this.

I imagine there's probably some easier way to do this, but I didn't find it.

[MrStahlfelge]

I used GHA for compiling the natives before, too, but all my changes were of smaller type. For more complex changes it might pay off to set up a local compiling environment to test with, as GHA are rather slow.

[grill2010]

I got it working already so I started to play around with some things.
Currently struggeling to get touchpad finger coordinates. I was expecting that it is trivial (as it should) but no mather what

SDL_GameControllerGetTouchpadFinger

is always returning Parameter 'touchpad' is invalid which seems to the fact that the touchpad was not properly initialized in the SDL_hidapi_ps5/ SDL_hidapi_ps4. I have already set all the correct SDL_SetHint values in my opinion. The reference project I found and which has implemented touchpad support can be found here. I can confirm it works there so it must be something stupid on my side.

[grill2010]

@MrStahlfelge found the issue. Touchpad works and it was just a stupid mistake on my side and took me some time to figure out what was the problem. Is there any reason why the hidapi is disabled on Windows and on all other platforms it's enabled? I changed the --disable-hidapi to --enable-hidapi and everything works as expected

Jamepad/.github/workflows/releaseaction.yml

Line 137 in bb3661b

- run: ../configure --host=x86_64-w64-mingw32 --disable-audio --disable-render --disable-power --disable-filesystem --disable-hidapi

[MrStahlfelge]

We disabled it due to compile errors back in the time (see #12 )

[grill2010]

@MrStahlfelge well this feature is absolutely necessary to make the DualSense/ DualShock features work. For building the natives I didn't get any compiler errors btw in my fork on the GitHub actions? So I assume it's safe to re-enable that feature?

[MrStahlfelge]

Perfect, looks like the compile was fixed in the meantime.

[grill2010]

@MrStahlfelge Touchpad and sensor data are already working I just have a general question. In my program I only use the ControllerIndex directly to access controller data. I have introduced new POJOs for sensor data and touch touch state. My idea is that ControllerState will have an own reference to these POJOs which are by default null. Only if the user has activated the "useSonyControllerFeatures" via the Configuration the ControllerState will generate and populate these POJOs via the ControllerIndex. This will avoid unecessary overhead for users who are not interested in these new things. ControllerIndex is reusing already created objects.

https://github.com/grill2010/Jamepad/blob/f10ec0abe896747ae5fe11f46167895fd5785770/src/main/java/com/studiohartman/jamepad/ControllerState.java#L381

Would this be okay so or are there any other preferences?

[MrStahlfelge]

Yes, looks good!

[grill2010]

@MrStahlfelge touchpad, gyro/ accel sensor data and adaptive triggers are working. Still need to test it a bit more but everything seems to be fine. I will make a pull request in the next two weeks or so I guess. Just one other question, I saw that the default fallback gamecontrollerdb file in the resources is actually very old. Maybe it's worth to update that too in my pull request? As written in the README I would use this one. Or is it preferred to keep it as it is as the user can anyway update it during runtime?

FYI DualSense haptic feedback is currently not implemented in my PR. Haptic feedback which is sent to the DualSense controller is basically raw PCM audio data. It would probably require to enable the audio module from SDL. This is maybe out of scope for this lib but I will try to implement it then in my fork later.

[MrStahlfelge]

Feel free to update the db, but it is not really necessary. The lib is mainly used for gdx-controllers which automatically updates the db on every release.

[grill2010]

Okay I see, if you don't mind I will update it as it's not really much effort and only has benefits :)

[grill2010]

@MrStahlfelge @Yontipon tried to further work on my DualSense feature fork but all of a sudden the Github actions are failing with

Unable to locate package linux-libc-dev:i386

for the Install Linux x86 compilers/libraries step

https://github.com/grill2010/Jamepad/actions/runs/6620228136/job/17982361325

Seems to be a general (temporary) problem but not sure. Did you encounter a similar problem with the github actions before?

[grill2010]

FYI I'm not sure what changed with the github actions but after literally 100 of test builds I found a fix for the problem and this was the commit what fixed the problem for me

grill2010@44349fa

This is not related to my fork but this information might be helpful if you need to update this project in the near future to make the github actions work again.

[MrStahlfelge]

I am not sure if this will remove support for raspi64?

[grill2010]

@MrStahlfelge why should it remove support from anything? You mean because of the commented out code of the

# - run: sudo sed -i

if yes then sorry for the confusion. This was no part of the solution, I already reverted that back. The solution I referred to was only what is highlighted in the commit I posted before. The solution was just to split up sudo dpkg --add-architecture commands and make a sudo apt-get update || true after the i386 architecture command. Strangely enough, this works and solves the problem with the Unable to locate package linux-libc-dev:i386. Other than that nothing was removed from the original GitHub action script :)

Here is the complete file

https://github.com/grill2010/Jamepad/blob/master/.github/workflows/pushaction.yml

[MrStahlfelge]

Feel free to open a PR for the change!