bwravencl / controllerbuddy Goto Github PK

Hi there,

I am working through the setup of ControllerBuddy and have downloaded and configured vjoy per the "getting started" Youtube video. I am trying to use an Xbox One controller, which my computer (Windows 10) recognizes and tests as expected with "Set up usb game controllers" in the control panel.

Also, I saw a previous issue thread with the same issue (they hadn't read carefully and didn't have a controller connected) where you requested the temp ControllerBuddy.log file. From my directory C:\Users\username\AppData\Local\Temp here is the ControllerBuddy log file: ControllerBuddy.log

Please advise if you have any suggestions as to what the source of the issue could be.

Thanks!

KP

I restarted, delteted contents in appdata/local/temp, and re unpacked the rogram files form the 7z

Curiously it also somehow remembers the dark mode setting?
Is there a config file somewhere im missing that I should try deleting?

The corresponding Windows API function to implement this is SetThreadExecutionState

For automation and scripting purposes three additional command line parameters would be useful:

• -save to save the current profile to the specified path
• -export to export a visualization of the current profile to the specified path
• skipMessageDialogs to skip all message dialogs
• -quit to quite the application

On Windows support for haptic feedback (and battery state retrieval) is performed via XInput.

Since XInput is not available on Linux and general haptic feedback support via glfw is not yet there - see glfw/glfw#57 a HID driver for Xbox 630 and Xbox One / Series X|S controllers should be implemented for Linux.

SDL should be a good reference for this (they support Xbox controllers, via Raw Input, XInput and HID).

• https://github.com/libsdl-org/SDL/blob/main/src/joystick/hidapi/SDL_hidapi_xbox360.c
• https://github.com/libsdl-org/SDL/blob/main/src/joystick/hidapi/SDL_hidapi_xboxone.c

On the long term running ControllerBuddy as a GraalVM Native Image would be nice.

Link Collection:

• oracle/graal#1701
• oracle/graal#2261
• java-native-access/jna#1172
• https://blogs.oracle.com/developers/building-cross-platform-native-images-with-graalvm
• https://github.com/amahfouz1/jna-graalvm
• https://github.com/classgraph/classgraph/wiki/Build-Time-Scanning#build-time-scanning-in-gradle-for-android

There seems to be some strange difference between the keyboard events generated by ControllerBuddy and the Windows OSK concerning the Pause key.

Generally the Pause key seems to work just fine, however e.g. in DCS a combination of Right CTRL + Pause is not handled correctly, although seems to get detected correctly by the DCS internal input mapper.

It seems this issue can be replicated with the following tool: https://w3c.github.io/uievents/tools/key-event-viewer.html

When pressing the Pause key via ControllerBuddy the tool detects an "unrecognized key".
Pressing the key via the Windows OSK the site shows "Pause".
The behaviour does not "improve" when the KEYEVENTF_EXTENDEDKEY flag is not set.

In the Linux DualShock 4 driver there have been some recent improvements to make power status reporting more accurate.

The following changes should be adapted for ControllerBuddy: torvalds/linux@a76a6c1#diff-7b3b27af128e730c0b4fa4cc2d7413f04a314406b79de0593238681528b88ff4R1061-R1091

A long term goal is to use the Java Platform Module System (JPMS) and move ControllerBuddy itself and all its dependencies onto the module path in order to let jlink produce a minimal runtime automatically.

Unfortunately as of right now the JPMS is still not at all or badly supported by some of ControllerBuddy's dependencies and the toolchain:

• Eclipse still has major issues parsing the module-info.java of multi-release JARs (bug)
• Two JARs on which batik-swing depends on (batik-script and xalan) cannot be placed on the module path (bug)

The jpms branch contains the necessary modifications and workarounds to use JPMS.
However until at least the Eclipse issue is fixed using JPMS is out of the question.

Since jlink requires us to move ALL dependencies onto the module path in order to take advantage of the JPMS there are currently no benefits in doing the switch. Also we currently already configure jlink manually to produce a minimal runtime.

JNA has extra packages with a module.info: https://github.com/java-native-access/jna/blob/master/www/FrequentlyAskedQuestions.md#does-jna-publish-a-module-descriptor-module-infojava-to-support-the-java-module-system-jpms

When running on Wayland (via XWayland) changes to the state of lock keys (Caps-Lock, Num-Lock, Scroll-Lock) are not propagated as desired.
Reading and modifying a lock key state works only when ControllerBuddy itself has the focus - this behavior is expected on Wayland.
A better approach could be to modify the lock key state via uinput, however further investigation is needed to determine if e.g. reading the current state is even possible via uinput...

Output could be implemented using uinput.

Link collection:

• http://robocup.wtb.tue.nl/svn/techunited/trunk/dev/GeertJan/scrum_and_bump/vel_estim/mouse_input/documents/Getting%20started%20with%20uinput_%20the%20user%20level%20input%20subsystem.pdf
• https://stackoverflow.com/questions/11939255/writing-to-dev-uinput-on-ubuntu-12-04
• https://github.com/zvxryb/Linux-Virtual-Joystick/blob/master/vjoy.c
• https://github.com/bithatch/linuxio4j
• https://github.com/Cleric-K/vJoySerialFeeder/blob/master/vJoySerialFeeder/VirtualJoysticks/VJoyUinput.cs
• https://github.com/Cleric-K/vJoySerialFeeder/blob/master/Docs/Linux.md#uinput
• chrippa/ds4drv#93 (comment)
• https://stackoverflow.com/questions/39046144/x11-jna-bad-window-invalid-window-parameter-causes-jvm-exit
• arjav2002/Game_Of_Life#1
• https://stackoverflow.com/a/12918307

On macOS controllers which are already connected before ControllerBuddy is launched are not recognized.

This issue appeared with the switch to LWJGL 3.3.0.

The root cause of the issue is that (unlike on other platforms) glfwJoystickPresent() is not called from the main thread on macOS. This is deliberate, because GLFW and AWT are fundamentally incompatible on macOS (macOS internals require both of them to run on the first thread).

Before LWJGL 3.3.0 - even though out of spec - it was possible to call glfwJoystickPresent() from other threads than the main thread and still get a correct result. With 3.3.0 the call always returns ˋfalseˋ.

A potential solution is mentioned here: LWJGL/lwjgl3#697 (comment)

A workaround is to unplug the controller and plug it back in after launching ControllerBuddy, since the callback registered via glfwSetJoystickCallback() works correcty.

ToKeyActions with the "Pause" key code (DIK 0xC5) toggle the NumLock state.
This seems to be some qurik in how this particular key code is handled by SendInput(), as it is not triggered by VJoyOutputThread.setLockKeyState().

To support VR overlays in applications that use OpenXR (e.g. Microsoft Flight Simulator) an overlay implementation is required analogously to the current OpenVR implementation.

Link collection:

• https://steamcommunity.com/app/250820/discussions/8/3041607080046568983/
• https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XrSessionCreateInfoOverlayEXTX
• https://github.com/LunarG/OpenXR-OverlayLayer
• https://www.reddit.com/r/OpenXR/comments/rk0eg2/does_openxr_support_overlay_apps_the_way_steamvr/
• https://github.com/mbucchia/OpenXR-Toolkit
• https://github.com/fredemmott/OpenKneeboard/tree/master/docs/internals
• OpenKneeboard/OpenKneeboard#9
• https://javadoc.lwjgl.org/org/lwjgl/openxr/EXTXOverlay.html
• https://registry.khronos.org/OpenXR/specs/1.0/loader.html#api-layer-interaction
• https://fredemmott.com/blog/2022/05/31/in-game-overlays.html

Since Pure Java HID-API seems to be pretty much abandonned and requires a number of workarounds in order to work correctly, switching to an alternative HID library remains a medium term goal.

Fortunately hid4java which is based on hidapi got recently resurrected from the dead.

The hid4java branch contains all necessary changes required to do the switch and works fine on Windows.

Unfortunately hidapi currently does not allow opening a device in non-exclusive mode on macOS which blocks the switchover: libusb/hidapi#27

Once the issue is fixed and there is a build of hid4java based on an updated hidapi version, switching is possible.
An alternative would be to build custom versions hidapi and hid4java with the following patch: signal11/hidapi#297

Since general haptic feedback support via glfw is not yet there - see glfw/glfw#57
As a stopgap solution it might make sense to implement rumble for Steam Controllers via the Steamworks-API.

Java bindings: https://github.com/code-disaster/steamworks4j

Some of the relevant API calls should be:

• https://partner.steamgames.com/doc/api/isteaminput#Init
• https://partner.steamgames.com/doc/api/isteaminput#GetConnectedControllers
• https://partner.steamgames.com/doc/api/isteaminput#GetInputTypeForHandle
• https://partner.steamgames.com/doc/api/isteaminput#TriggerVibration
• https://partner.steamgames.com/doc/api/isteaminput#Shutdown

Fullscreen overlays for Direct3D and OpenGL applications are implemented for Windows x64 in the mumble-overlay branch by hijacking the Mumble Overlay.
With more and more applications using Vulkan it would be nice to support fullscreen overlays for these applications as well.

Initial research shows that "validation layers" are the technology a fullscreen overlay for Vulkan should be based on.

Link collection:

• https://github.com/Andrey1994/game_overlay_sdk
• https://vulkan-tutorial.com/Drawing_a_triangle/Setup/Validation_layers
• https://github.com/jackun/vulkan-overlay-layer
• https://github.com/LunarG/VulkanTools/tree/main/layersvt

I need to send data over network from one instance of FreePIE (https://andersmalmgren.github.io/FreePIE/) to another. As FreePIE supports writing to vJoy, I have figured I will feed data to one vJoycontroller on one end, send it over with ControllerBuddy and then recover it from vJoy on the other end.

However, when I start ControllerBuddy on the 'sender' computer, it says that no controller is connected (i.e. it does not detect the vJoy controller)... Is it only for physical controllers? I realize that it might be done on purpose (to avoid endless loops), but there might be other ways around that...

Steps taken:

• Selected Left Bumper
• Added a "Cycle" Action
• Edit Actions
• Add vJoy Button Input
• Crash

Output:

java.lang.NullPointerException:``` Cannot invoke "de.bwravencl.controllerbuddy.input.Profile.getModes()" because "this.unsavedProfile" is null

Full exception output:
Crash.txt

The visualization view does not resize if the main window size changes.

Currently the overlay is limited to the bounds of the first display.

In an ideal world it should be freely moveable between all display.
Alternatively, the display on which it shall be displayed could be selected via a global setting.

Link collection:

• https://stackoverflow.com/questions/6322627/java-toolkit-getting-second-screen-size/6322689

Hello. I'm trying to run ControllerBuddy 0.12.34 on Windows 10 with vJoy v2.1.9 installed, but when I run it I get the "There is no controller connected. Without a controller ControllerBuddy can only be used in client-mode." message. There is one device in vJoy configuration and examples that come with it seem to work Ok (feeder/monitor programs). I've tried adding another device and resetting devices in configuration, but nothing changed. What could be the problem?

Instead of simply listing the different mappings below one another a drop-down menu on the top of the document could be used to select the mode that should be displayed for viewing (example).

Link collection:

• https://unix.stackexchange.com/questions/437735/prevent-system-from-going-to-sleep-suspend-how-xviewer-vlc-do-it
• https://github.com/hypfvieh/dbus-java
• https://github.com/videolan/vlc/blob/master/modules/misc/inhibit/dbus.c

Once available in a future gradle release the statement below should be used in build.gradle to detect aarch64 systems instead of comparing the architecture strings manually as it is currently done:

case 'aarch64':
case 'arm-v8':
case 'arm64':

-> Architectures.AARCH64.isAlias(it):

Commit in gradle master branch:
gradle/gradle@9059e16#diff-ebdc277bfff530abb5d120a6af8df9aaf71b04b3309673969a0e1496b946cecdR29

Link collection:

• https://github.com/albhm/macPPM
• https://github.com/unbit/foohid
• https://github.com/alxn1/wjoy
• pqrs-org/Karabiner-DriverKit-VirtualHIDDevice#22

Could be implemented via the OpenVR SDK.

Link collection:

• https://github.com/scudzey/UVROverlay
• https://forums.eagle.ru/showthread.php?t=182573
• https://github.com/kotlin-graphics/openvr
• https://github.com/BManx2000/VirtualButtonBox