Not detecting all axis of a Racing wheel

[Termanater13]

I have 2 VKBs connected, and everything is detected without problem. I have a Moza R5 base, and two axis are missing: the Z axis and the Z Rotation. Everything else is detected. Both are tied to the gas and brake, and Windows can detect the missing axis without a problem.

I see no issues in the logs other than the known UTF-8 issue that enabling the beta setting fixes and improperly configured vJoy.

[WhiteMagic]

Do you know if the device is being treated or makes itself appear to be an XInput device as opposed to a DirectInput one? The Xbox controller for example, has the trigger buttons that under XInput work as a combined axies, but under DirectInput only show up as buttons.

[Termanater13]

I'm not entirely sure about the process of checking this. From what I've observed, the axes seem to show as individual axes, not as a combined axis.

I did some digging and noticed some odd behavior. After seeing the axes in JoystickGremlin, I did some tests, and they worked just fine.

1. Powering on the wheel before opening JoystickGremlin, can't see Axes.
2. Powering on the wheel after opening JoystickGremlin, detects all Axes.
3. Powering on one VKB after establishing axes from 2, I can see the Axes in the menu but cannot read them. One try turning on one did not break the axes, but powering on the other broke it. I tried several times and only once did turning on one not break the axes of the wheel.
4. After powering off the wheel, restarting JoystickGremlin, and powering on the wheel after all other devices have been initialized, you can see all axes of all devices.
5. Power cycling either VKB after 4, can see axes in the menu but not read them.

It looks to me like any device being initialized after the wheel breaks the axes on the wheel.

[WhiteMagic]

Hmmm that's definitely odd, you could try to run the test program included in this https://github.com/WhiteMagic/dill/releases/download/v1.3/dill_1.3.zip to see what Gremlin is actually being told when turning devices on and off. Though it sounds like some really odd things are going on that would have to be solved in the input library as Gremlin just sees whatever it tells it.

[Termanater13]

so it had a bit of more odd behavior, I think caused by the program. When that program was running, Joystick Gremlin never lost those axes, no matter what I did. Without it running, it lost those axes. I did all the actions I mentioned above. I ended up deleting the debug.txt once before I realized what it was logging.

example2.exe did nothing other than display all devices Joystick gremlin could see. Adding and removing devices did nothing.

example.exe showed all devices and spammed the terminal with data from the axis. My wheel continuously spammed updates between 2 numbers until the wheel locked, then nothing since the number did not change. It displayed all axes and buttons as I pressed buttons or moved the axis. when I moved the wheel away from wheel lock it updated the axis.

debug.txt

[Termanater13]

Adding to note something. Played around and noticed that if example.exe was started before the joystick gremlin and I connected the wheel before the joystick gremlin started, it would not lose the axis. If both were started after connecting the wheel it would lose the wheel axis. Just noting as it seems to me as a dll is being injected to give Joystick gremlin the ability to read the joysticks, and the order of events may be the cause of the weirdness.

[WhiteMagic]

From the debug file it seems that there is something odd going on with that wheel. It always reports 8 axes but at times then only provides 7 axes when asked for the axes it has. Then there were also instances where access to it got lost which is also not normal.

Gremlin doesn't really inject anything, it just uses DILL to provide access to DirectInput data and that code happens to live in a C library. There exists an order how things are executed but that is fixed and can't change as Gremlin just does it the same way each time. If other programs get a hold of joysticks via DirectInput it shouldn't be a problem as DirectInput supports non-exclusive access to devices. Though if some program forced exclusive access then I'm not sure what would happen.

[Termanater13]

I would have to do some tests, but I feel that when the wheel is reporting 8 axes I didn't have any issues. I may have to do some more tests to figure out what is going on. May even contact moza to figure out what is going on. The issue may also be their software as I do have it running at the same time.

I'm not very technical with a few things, and figured that is how it worked as it seemed that there was an order to get it to always work. I'm know a lot more than most about computers, but in the end I really don't know much.

[WhiteMagic]

Yeah I would imagine that if the device actually has 8 axes but fails to properly report them things are going to be odd afterwards. And there may indeed be a sequence of actions that cause the issue to happen or prevent it. What I meant is that within Gremlin the order is fixed and doesn't really run into race conditions.

[Termanater13]

So, here are some tests I did today to see if it did anything:

1. Rolled back the firmware as that is a suggested step by Moza if a firmware update causes issues. This did nothing.
2. Looked at the debug.txt I submitted earlier and noticed Overriding reported number of axes, capabilities=8 enumerated=7 This can be seen every time it says it has 7 axes in the file.
3. I installed Universal Controls Remapper (UCR), which can see those axes even when the Joystick gremlin can not. UI is nice but gets complicated and unwieldy when getting into large configurations.
4. I found dill.dll used by example.exe and joystick gremlin and noticed a file size difference. I renamed Joystick gremlin to "dill.old.dll," which was enough for it to not be seen. I copied example.exe's dill.dll over. I tried methods to lose those axes, and when it did, it was only for a second and then back and usable as if it never went away.
5. I then switched back to the original dill.dll, and I tried those methods again, losing those axes again.

The size of Joystick Gremlin's dill.dll file on my system is 523 KB, and example.exe's dill.dll is 147 KB. I also want to note that it threw errors every time I switched DLLs, so I have no idea what caused that.

timestamps from system.log file to errors:

1. 2024-05-24 19:33:04 line 2768
2. 2024-05-24 19:35:53 line 2867
3. 2024-05-24 19:36:51 line 2957 Errors 1 and 3 are the same except for the number following KeyError. Error 2 is different from the others.

Joystick Gremlin log file system.log

If it helps, here is example.exe using the dill.dll from joystick gremlin. I deleted the debug.txt after backing it up so that it is from one dll and not mixed with the other. This one crashed when disconnecting and reconnecting devices. debug.txt

[WhiteMagic]

Dill v1.3 did fix some race conditions but never was distributed with Gremlin as there has not been a new Gremlin release since the release of v1.3. I would then assume that you ran into the same issue that prompted the fix in dill initially. But I'm correct to assume that with the newer version of DILL the problem doesn't exist fully anymore?

The errors I would assume are linked to the device at times reporting 7 instead of 8 axes while the profile contains 8 axes.

[Termanater13]

I looked into it, and if I'm not mistaken, Joystick Gremlin uses Dill v1.2, based on the file sizes. Manually updating it to Dill v1.3 seemed to have fixed the issue. There may be unseen issues, but my issue seems to be gone now.

[WhiteMagic]

Ok good, I'll close this then as technically the problem is just with dill and the new version already uses that version of dill so it won't come up as an issue again.