Menu
▾
▴
#2552 ThrustMaster USB Joystick not working
Hello,
I just buy a new Macbook Air M1 (mac os BigSur 11.2.1 / 8Go / 256 Go) and try to run flightgear 2020 3.5 and it fly very well with mousse and keyboard (F-16, F-15, Cessna).
I have a TrustMaster USB Joystick (Only certified on Windows 8 &10) and I am not able to use it. I upgraded to FGFS 2020 3.6 and same problems.
I played a lot on FGFS many years before (v2.5...?) with a ThrustMaster 4 axis Flight-X on a Imac 2008 (again not certified on macos) and it works without any problems and i did the joystick mappings my self at this time.
I tried my new Joystick on gamepad tester, it's recognized, and it's work perfectly on the trial of X-Plane 11.
My F**** new Macbook Air has only 2 USB-C ports, so I plugged the joystick in a hub (2 USB-C converted to 1 Ethernet + 2 USB + 1 DVI + memory card reader), tried to change the usb port, etc...
Today I bought an Apple converter 1USB-C to 1USB and tried both ports (and upside/down)... and still not work.
The joystick appear in the Fgfs joystick config panel, 3 axis and sometimes the buttons when I unplug it are visibles and match the default joystick configuration.
I tried to configure a custom mapping, the mapping it matched by name by FGFS but no axis nor buttons works. :-/
The only this that could change, is when i do a refresh of the jostick with changing any axis position, it's applied on the panel values and active in the game. ex if i put full Throttle and refresh the joystick the engine is at full power.
The only thing strange I could notice on this joystick, both gamepad and X-Plane shows the axis 2 and 3 changing at the same time when using the throttle...
Exemple :
Engine idle : axis 2 : 1.00000, axis 3 : 0.00392
Engine half : axis 2 : 0.15294, axis 3 : -0.60000
Engine full : axis 2 : -1.00000, axis 3 : -1.00000
The 4 way button for change view direction is mapped on axis 9.
Left : 0.71429
Right : -0.42857
Middle : -1.28571
Forward : -1.00000
Backward : 0.14286
B0 : Front middle (index finger, gachette, or brakes)
B1: Top middle button
B2 : Right front button (index)
B3 : Right top button (thumb)
I catched a fragment of the logfile when I refreshed the joystick (see bellow).
http://www.thrustmaster.com/products/usb-joystick
Log trace when doing a refresh of the joystick
577.14 [WARN]:input /Users/Shared/Hudson/MacRelease/flightgear/3rdparty/joystick/jsMacOSX.cxx:359: input type element has weird usage:187
577.14 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGJoystickInput.cxx:137: Looking for bindings for joystick "USB Game Controllers"
577.14 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGJoystickInput.cxx:153: No config found for joystick "USB Game Controllers"
Using default: "/Applications/FlightGear.app/Contents/Resources/data/Input/Joysticks/Default/joystick.xml"
577.14 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGHIDEventInput.cxx:921: Re-Initializing HID input bindings
577.14 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGHIDEventInput.cxx:944: HID event input shutting down
577.14 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGHIDEventInput.cxx:929: HID event input starting up
Macos system reporter :
USB Game Controllers :
Identifiant du produit : 0x0316
Identifiant du fournisseur : 0x07b5 (Mega World International Ltd.)
Version : 1.01
Vitesse : Jusqu’à 1,5 Mb/s
Fabricant : Thrustmaster, Inc.
Identifiant de l’emplacement : 0x00100000 / 1
Courant disponible (mA) : 500
Courant requis (mA) : 350
Exploitation supplémentaire actuelle (mA) : 0
If you have any idea if it could work one day or not :)
Thanks,
Edo
Hi Edo, Thurstmaster joysticks do work correctly for most people on macOS: I use one myself and it's got no problems. (A T.1600) USB-C also shouldn't matter. It's possible the fact you have an M1 mac is the issue, but unlikely. (Since the joystick shows up, the OS is detecting it ok)
The title 'USB Game Controllers' is strange : that is not how I'd expect a ThrustMaster joystick to appear, and the reference to 'Mega World International Ltd' is also strange. (Suggests some weird hardware not actually made by Thrustmaster). But if it works in XPlane it should work in FlightGear more or less the same.
Sorry, I guess this doesn't help so much.
Hi James,
I think I understand part of the problem.
In X-Plane the Rudder and Throttle axis are coupled to the Throttle handle and I have the possibility to choose witch one I want to use or both together at the same time, it might be fun to fly... :)
577.14 [WARN]:input /Users/Shared/Hudson/MacRelease/flightgear/3rdparty/joystick/jsMacOSX.cxx:359: input type element has weird usage:187
The HID usage 187 is refered to Throttle as stated in the table page 54 : https://usb.org/sites/default/files/hut1_21_0.pdf
After watching the source code of fgfs the line 359 at (FGFS 2020 3.5 ?) https://github.com/FlightGear/flightgear/blob/fe17cfc84dd6f101928827a17fd8086d12fe88f2/3rdparty/joystick/jsMacOSX.cxx
It appear that the usage code "187" is not handled by Fgfs in the section kHIDPage_GenericDesktop. The throttle (hid code 187) is checked in the next section kHIDPage_Simulation
else if (page == kHIDPage_Simulation) {
switch (usage) / look at usage to determine function /
{
case kHIDUsage_Sim_Rudder:
case kHIDUsage_Sim_Throttle:
//printf(" axis\n");
/joy->os->/addAxisElement(joy, (CFDictionaryRef) element);
break;
default:
SG_LOG(SG_INPUT, SG_WARN, "Simulation page input type element has weird usage:" << usage);
}
}
So I understand the error message in the log file, but I don't undestand why others axis and buttons don't works.
Edo
Interesting that you found a device which uses the HID Sim page, this is very unusual. Fixing that is actually easy, but as you say, the other axes should work.
For the 'desktop' page, codes above a certain value are 'reserved', but it is common to find data bugs in HID descriptors, unfortunately I found a few in other devices already. So this might be a case where the element has the wrong page set.
Hi James,
Yes it's very strange.
I did not found the procedure du build fgfs on the last macos, I suppose I need XCode, but I found nothing to build it on that os, only old versions.
Is it possible to build/debug it from netbeans on Mac..?
I will test it on Windows 10 to check if the joystick works on fgfs.
Thanks,
Edo
We use CMake to build, it can produce Xode project of course but also works fine with anything else: netBeans should work. You need to build SimGear as well, and probably OpenSceneGraph. Build instructions should be on the wiki, although maybe the macOS ones are out of date.
I just tested it on Lenovo ThinkPad X390 / Windows 10 with fgfs and it works fine.
So the problem is limited to Macos.
Here the logs for the joystick :
34.73 [INFO]:input C:\Jenkins\workspace\Windows-release\flightgear\src\Input\FGJoystickInput.cxx:137: Looking for bindings for joystick "USB Game Controllers"
34.73 [INFO]:input C:\Jenkins\workspace\Windows-release\flightgear\src\Input\FGJoystickInput.cxx:153: No config found for joystick "USB Game Controllers"
Using default: "C:/Program Files/FlightGear 2020.3.6/data/Input/Joysticks/Default/joystick.xml"
Does it work if you add a custom config? Eg copy the T.1600 one and modify it?
Custom config on mac doesn't work but fgfs match a custom mapping from Flight-T.xml if I name it "USB Game Controllers".
Did not try on windows
It's really strange, everything is working, but it doesn't work!
The missing sim_throttle element should be ignored, but other elements should work exactly as normal. Can you try the 'fgjs' utility which is hidden inside the .app bundle (at Contents/MacOS), and see if it works any better? But, it uses exactly the same code, so I don't have much hope.
Just tried.
5.31 [WARN]:input /Users/Shared/Hudson/MacRelease/flightgear/3rdparty/joystick/jsMacOSX.cxx:359: input type element has weird usage:187
5.31 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGJoystickInput.cxx:137: Looking for bindings for joystick "USB Game Controllers"
5.31 [INFO]:input /Users/Shared/Hudson/MacRelease/flightgear/src/Input/FGJoystickInput.cxx:149: ... found joystick: /Users/edo/Library/Application Support/FlightGear/Input/Joysticks/USB-Game-Controllers.xml
Tried with only aileron and elevator, but nothing works.
I stuck after the first step. The buttons don't works.
macbook-air-edo:FlightGear.app edo$ ./Contents/MacOS/fgjs
Found 1 joystick(s)
Now measuring the dead band of your joystick. The dead band is the area
where the joystick is centered and should not generate any input. Move all
axes around in this dead zone during the ten seconds this test will take.
Press enter to continue.
10 - 9 - 8 - 7 - 6 - 5 - 4 - 3 - 2 - 1 - 0
Joystick 0, axis 0: 0.000000
Joystick 0, axis 1: 0.000000
Joystick 0, axis 2: 0.000000
Joystick 0, axis 3: 0.000000
Joystick 0, axis 4: 0.000000
Dead band calibration finished. Press enter to start control assignment.
Joystick #0 "USB Game Controllers" has 5 axes
Move the control you wish to use for Aileron right
Pressing a button skips this axis
I think the real pb is that fgfs won't get the values from the joystick, such a refresh loop or values are not in required bounds..?
That is a good hint, but strange. To explain, fgjs does a loop whic basically says:
forever()
{
readJoystick(buttons, axes)
if (buttons != 0 { ... }
}
Buttons is a 32-bit int, each bit corresponds to a button. So this means just reading the buttons is failing for you device, which is pretty fundamental.
I'm trying to work out if I can get hold of such a device to test (eg find one on eBay): other option is you build fgjs yourself (should be trivial) - then you could step through the calls and see where/why the read is failing.
I found one on eBay for not so much money, let's see if I win :) I can donate it to some FG user afterwards, if I win.
Hi James,
I can spend one day or two to try but not so much (I am very busy at this moment), and I hope I will have enougth disk space to hold the dev env, I have only 30Go free, if I knew I should buy the 512Go and not the 256....
If you buy one, tel me how much you paid for it I will donate some money to you or fgfs.
Last edit: Edo Pel 2021-02-18
Let's see what eBay throws up - don't worry about the money though, there's nowhere open to drink beer :) I'm also checking if any of my friends have the same joystick I could borrow for a day.
I installed XCode, NetBeans, CMake, Boost
Checkout Flightgear, SimGear (tried to build them)
Built, install Open Scene Graph,
I do not install QT deps.
But I'm unable to install/compile plib 1.8.5 (both from mac ports or from sources).
I have such kind of compiles errors :
:info:build slDSP.cxx:833:51: error: unknown type name 'SndCommand'
:info:build pascal void sndCallbackProc ( SndChannelPtr chan, SndCommand *cmd )
...
:info:build ^
:info:build slDSP.cxx:1008:23: error: use of undeclared identifier 'flushCmd'
:info:build currentCmd.cmd = flushCmd;
:info:build ^
:info:build slDSP.cxx:1025:20: error: use of undeclared identifier 'quietCmd'
:info:build currentCmd.cmd = quietCmd;
If you have an idea..?
Ah, we don't build a lot of PLIB (it will be removed soon). Normally I grab pre-built versions of the dependencies from our build server, saves some problems. (Actually I thought the wiki even mentioned this)
We build PLIB with './configure --prefix=$WORKSPACE/dist --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux' on the build server.
I built plib ! thanks...
Now, I have a pb with boost during test on simgear.
ld: warning: ignoring file /opt/local/lib/libboost_unit_test_framework-mt.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture x86_64:
"boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const="">, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...)", referenced from:
bool boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd, std::__1::basic_string\<char,="" std::__1::char_traits\<char="">, std::__1::allocator\<char> >, std::__1::basic_string\<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > >(boost::test_tools::tt_detail::equal_impl_frwd, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const="">, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, char const, std::__1::basic_string<char, std::__1::char_traits\<char="">, std::__1::allocator\<char> > const&, char const</char></char,>) in SimpleMarkdown_test.cxx.o
"boost::unit_test::lazy_ostream::inst", referenced from:
basic_markdown::test_method() in SimpleMarkdown_test.cxx.o</char></char,></char></char></char,></char></boost::test_tools::tt_detail::equal_impl_frwd,></char>
Cmake is trying to kinking a arm version... :-/
For fgfs how can I set the plib include and lib path in netbeans..?
I think the problem is that the boost version installed from mac ports is an arm build, so I do not have boost in x86_64...
I tried to re installed boost like this : sudo port install boost +universal +python39
But it failed to compile. mac port try to compile for both arch : -arch x86_64 -arch arm64
I have many compilation errors :
In file included from /Users/edo/dev/simgear/simgear/nasal/cppbind/from_nasal.hxx:23:
/Users/edo/dev/simgear/simgear/nasal/cppbind/detail/from_nasal_helper.hxx:210:8: error: reference to 'enable_if_t' is ambiguous
std::enable_if_t<is_vec4\<vec4>::value, Vec4></is_vec4\<vec4>
It's maybe a missing compiler option or non compatible C++ compiler on macos11 arm ?
Actually more likely it's some code we have to detect older compilers. If you read the erros your will see there is probably a version of enable_if coming from a Simgear header. For some reason, sometimes the auto-detection of the compiler version doesn't work, and it includes the backwards-comaptible headers with a newer compiler. Then you get the error you see, because it has an ambiguity between them.
What I don't know, is why the compiler detection failed. If you look at simgear_config.h in your simgear build directory (eg 'sgbuild' or whatever name you used), check if 'HAVE_STD_ENABLE_IF_T' is set or commented out.
Here is my simgear_config.h