Use of OpenTrack on linux with SteamPlay/Proton?

[cofilippo]

I've been able to compile OpenTrack for linux with wine support after a bit of trial and error.
I used these settings:

I do get an error:

[ 70%] Generating opentrack-wrapper-wine.exe.so
/usr/bin/ld: cannot find -ladvapi32: No such file or directory
/usr/bin/ld: cannot find -luser32: No such file or directory
/usr/bin/ld: cannot find -lwinecrt0: No such file or directory
/usr/bin/ld: cannot find -lkernel32: No such file or directory
/usr/bin/ld: cannot find -lntdll: No such file or directory
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/g++ failed
make[2]: *** [proto-wine/CMakeFiles/wine-wrapper.dir/build.make:75: proto-wine/opentrack-wrapper-wine.exe.so] Error 2
make[1]: *** [CMakeFiles/Makefile2:2275: proto-wine/CMakeFiles/wine-wrapper.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

but, as suggested in #1485

Once you remove the -m32 option it will compile and run.

But I can' t figure out how to make it work. What do I need to do to to be able to use it with Il-2 BoX or DCS when running those games under Proton? I don't get any response when setting the wine tracker up for proton using appid 223750 and the Proton Experimental settings when trying to configure it for DCS, for example. I get the error:

Error occurred while loading protocol Wine -- Windows layer for Unix

Couldn't find a Steam runtime.

My hunch is that removing -m32 from opentrack/proto-wine/CMakeLists.txt removed the ability to communicate with steam. But I'm unsure how to make it compile with -m32 enabled.

[digitaltrails]

I couldn't find any decent info on getting opentrack working on IL-2 BoX on Linux+Steam+Proton. In the end I wrote something that works for head turn/tilt and camera-zoom (hot off the press this week):

https://github.com/digitaltrails/opentrack-opal

The mouse is super easy to get working, but I think the stick-emulation works best (but requires a little effort to setup):

https://github.com/digitaltrails/opentrack-opal/blob/master/opentrack-stick.md

After head turn/tilt/camera-zoom, I haven't yet had any luck with head x,y,z.

[digitaltrails]

When yo

It's a nice effort. but I'm looking for a solution which wouldn't use mouse output or joystick output. Those are working already, albeit with major compromises. The joystick only sees 5 out of 6 axis and the mouse is really impractical. What I want is a solution which would enable me to get OpenTrack to work with the wine/proton solution, so I can get the TrackIR protocol working.

When you say a joystick is already working, do you mean you are already using opentrack with the opentrack-virtual-joystick? I could not get that to work, but it may be I needed to work more with the opentrack-curves. It was only by writing my own code, that any of this started to make sense (I'm not really a gamer, I only play IL-2 BoX and Zelda BOTW, nothing else is interesting).

[sthalik]

What can the Python script do that opentrack's proto/libevdev can't?

[digitaltrails]

What can the Python script do that opentrack's proto/libevdev can't?

Do you mean opentrack Output -> libevdev joystick receiver? I could not find/figure-out how to use that, but maybe I can now.

I think initially I had trouble with the game detecting the virtual controllers. But deleting devices.txt may be the answer to that. I almost gave up when IL-2 stopped working due to me altering the input defs - it seems quick a brittle config.

The main advantage I have with python, is I can debug it, and I can easily turn off axes, I can play around with the smoothing and smoothing algorithms. I can potentially try add other features, such as introducing a virtual-keyboard so I can inject key sequences.

Output -> libevdev joystick receiver is written in C++, doesn't use UDP. Potentially it might receive output faster. The UDP traffic seems to be delivering one reading every 4 ms, which seems to require smoothing. If C++ receives data faster, it might not need any smoothing. But not having got that to work, I do not know.

If someone could confirm Output -> libevdev joystick receiver can be made to work with IL-2 BoX, that would be good. A description of the process for setting it up, would be quite helpful. It may be I gave up too soon.

Update 10:38 am - I tried to get Output -> libevdev joystick receiver to work just now by flattening all mapping curves except for pitch. Pitch was mapped to send the entire output range. Although the game recognised the new stick, the game failed to react to my nodding when attempting to map to pilot head bow. So the advantage remains, for me at least, my python code is the only thing that works.

[cofilippo]

When yo

It's a nice effort. but I'm looking for a solution which wouldn't use mouse output or joystick output. Those are working already, albeit with major compromises. The joystick only sees 5 out of 6 axis and the mouse is really impractical. What I want is a solution which would enable me to get OpenTrack to work with the wine/proton solution, so I can get the TrackIR protocol working.

When you say a joystick is already working, do you mean you are already using opentrack with the opentrack-virtual-joystick? I could not get that to work, but it may be I needed to work more with the opentrack-curves. It was only by writing my own code, that any of this started to make sense (I'm not really a gamer, I only play IL-2 BoX and Zelda BOTW, nothing else is interesting).

Yes, I have a separate build without wine built in which works with the joystick input, but it has it's own problems. I can only use 5 axis in DCS and I can't remap them in OpenTrack. The movement is also really jittery. So there are reasons for me to want the wine enabled version to work for me.

[digitaltrails]

...

Yes, I have a separate build without wine built in which works with the joystick input, but it has it's own problems. I can only use 5 axis in DCS and I can't remap them in OpenTrack. The movement is also really jittery. So there are reasons for me to want the wine enabled version to work for me.

I was discussing what might work best elsewhere: @DanielKinsman mentioned he had used UDP bridge/forwarding between two opentracks. If I understand it correctly, the idea involves running a linux native opentrack with input from a head-tracker and output to udp, and then in wine/steam run a windows native opentrack with the input from udp and output as freetrack.