#2185 Aircraft controls initialize with full left deflection after the first fgfs launch

[Bjoern K]

Issue:
After starting fgfs for the first time after OS start with a connected joystick, aircraft controls are initialized with full left deflection. Observed with C172p and the UFO.
In the UFO, this produces a spinning model.
Moving the controller a bit and letting go recenters the aileron axis, fixing the spinning.
Problem does not reoccur if FGFS is closed and relaunched.

Reproduction:
Boot the OS, start fgfs. Do not move the joystick in between. Problem will occur. Move the controller once, aircraft aileron axis will recenter.

Further information:
Observed on Arch Linux with FG 2019.2.0 (Git/Next, built on 2020/01/18) and a Thrustmaster T16000M.

Discussed in this thread in the forum: https://forum.flightgear.org/viewtopic.php?f=17&t=36797&p=360398

Issue is already known to core devs, so this ticket is for sake of completeness and reference to non-members of the respective mailing list.

Proposed workaround:
Implement an axis lock that locks the aileron, elevator and rudder axis at value zero until a first hardware input in any axis from the associated controller is detected.

[Slawek Mikula]

Sorry, I do not confirm. Testing with latest Git/Next, ubuntu 18.04, logitech extreme 3dpro, dell E5450. Nothing as you reported arises. Tested with Keflavik and C172 and UFO. Maybe i'm doing something differently:
start OS
connect joystick to USB port
* start FG (launcher, select ufo/c172, start FG simulation)

No erronous deflection.

I'm using HeliHud (http://wiki.beggabaur.rocks/ya/HeliHUD) for displaying control deflection and nothing happened. Maybe this is something connected with your hardware, OS, driver ? can you check with different joystick, OS, computer ?

PS. I'm also reading all of the mentioned sources ;)

[Slawek Mikula]

I've checked also with full system reboot. Steps:

• connect joystick to the computer
• shutdown computer
• turn it on, do not touch joystick
• start OS, select FG, select UFO, start FG simulation
• still OK (UFO does not spin, HeliHud shows no controls deflection)

[Bjoern K]

Tested with an XBox 360 pad on my laptop running Arch Linux. Controls initialize just fine after a cold boot.

Might be an issue specific to a controller or driver. Will retest on my desktop PC once I get home again.

[Slawek Mikula]

I would bet on joystick controller (firmware?). Dunno. The driver in the kernel I assume is generic so with my Logitech the error would be the same ? Btw my kernel: 4.15.0-74-generic #84-Ubuntu SMP

[Huntley Palmer]

Confirmed on one ( only ) of three PC's running Fedora:

Desktop Ryzen/SSD GTi750 FC29.x64 Fluxbox Saitek AV8R : OK
Desktop Athlon/HDD GTi750 FC31.x64 Fluxbox Saitek AV8R : OK
Laptop i7/HDD NV 640m FC29.x64 Fluxbox Saitek AV8R : Fails

The same AV8R joystick was moved between boxes, for the failing laptop it
isn't necessary to disconnect the USB joystick, simply "Turning the power
off and switching it back on again" (tm )

There's no need to start fgfs; execute js_demo and the analog axes show -1.00 .. after twiddling the joystick they read 0.00.

This may well have been happening for a while here, the laptop is an 'away from' fgfs box and I don't usually run tail draggers; the BeechBox veering off may have been passed off as crosswind, quickly corrected.

[Slawek Mikula]

Guys, can you check also native linux joystick application to test it ? Under ubuntu its 'joystick' deb package. Then use e.g. jstest /dev/input/js0 to check axis deflection. js_demo is build from FG source code, so let's make clear this behaviour comes from OS or FG.

[Huntley Palmer]

Correction, all my machines , four total including another ancient laptop show this problem.

Modify flightgear/src/Input/js_demo.cxx ~~ #93 ff to read:

//  for ( ; j < 8 ; j++ )
//    printf ( "  .  " ) ;
      }
     }

    // printf ( "|\r" ) ;
    printf ( "|\r\n" ) ;
    fflush ( stdout ) ;

Rebuil flightgear
Power the PC off, on again with joystick plugged
In a terminal window type:
js_demo > js_demo_out.txt
and let it run for a few seconds, the file gets big quickly.
Here's what I see in the middle of the output file: ( line 2234 so about 2220 sample in )

| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 -1.0 -1.0 -1.0 -1.0 -1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |
| 0000 +0.0 +0.0 +0.0 +0.0 +1.0 +0.0 +0.0 | 0000 +0.0 +0.0 |

[Huntley Palmer]

As far as I can tell the anaolg for Fedora is evtest. I have not seen evtest report full deflection on two machines tested but on one machine: evtest continually reports readings in the proper mid range and on the other machine it reports no reading until the stick is perturbed.

Too, it's necessary to determine the actual device numvber in /dev/input/eventxx so it's necessary to execute evtest once, to find the event number, before piping the output to file.

The same joystick hardware acts differently on two machines, on one it's noisy enough to create continuous events and on the other no event reporting is triggered until the stick is moved.

Maybe it's not so easy to blame OS over fgfs if evtest properly initialises itself before waiting for an event and, in fgfs, plib doesn't. Trouble with dhc2 was reported for both Windows10 and Ubuntu.

[Slawek Mikula]

I think evtest is different. It connects directly to the events not joystick interface. In fedora its the same package name e.g. http://rpm.pbone.net/index.php3/stat/4/idpl/47345727/dir/fedora_19/com/joystick-1.2.15-29.fc19.x86_64.rpm.html

But on the mailing list people keeps posting about this error ("been there, seen that"). I think right now it is important to know if the problem is IN or OUTSIDE FG. I'll try to check my logitech joystick for this behaviour again.

[jean pellotier]

i see it too here, be it on a saitek pedal or a t16000 stick and gaz, using jstest on linux show me the values are full for some axes, wich are resetted to 0 once moving a bit the joysticks, nothing to do with FG, but to the state the joystick come in at startup, before moving it (these joysticks transmit a new state only if they have mouvements and there's no noise to make them verbose with no action)

[Slawek Mikula]

guys, so based on info from jean it can be something on the driver side. Can you all check what kernel module/s (lsmod) you have loaded when joystick is loaded. I have only joydev kernel module loaded. if you can also put some info after plugging your joysticks (dmesg) it could be helpful. I'll try to look into it and dig a bit on kernel lists.

[jean pellotier]

got the joydev,

and (if related)

hid_generic 16384 0
usbhid 65536 0
hid 143360 2 usbhid,hid_generic

the joysticks are allways connected, a dmesg from a cold start:

[    3.576312] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.576313] usb 2-1: Product: Saitek Pro Flight Rudder Pedals
[    3.576315] usb 2-1: Manufacturer: Saitek
[    3.585853] hidraw: raw HID events driver (C) Jiri Kosina
[    3.594637] usbcore: registered new interface driver usbhid
[    3.594639] usbhid: USB HID core driver
[    3.597624] input: Saitek Saitek Pro Flight Rudder Pedals as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.0/0003:06A3:0763.0001/input/input5
[    3.597694] hid-generic 0003:06A3:0763.0001: input,hidraw0: USB HID v1.11 Joystick [Saitek Saitek Pro Flight Rudder Pedals] on usb-0000:00:02.0-1/input0

[    4.170301] usb 2-2: new full-speed USB device number 3 using ohci-pci
[    4.403329] usb 2-2: New USB device found, idVendor=044f, idProduct=b10a, bcdDevice= 5.00
[    4.403332] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.403334] usb 2-2: Product: T.16000M
[    4.403335] usb 2-2: Manufacturer: Thrustmaster
[    4.413054] input: Thrustmaster T.16000M as /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/0003:044F:B10A.0002/input/input6
[    4.413126] hid-generic 0003:044F:B10A.0002: input,hidraw1: USB HID v1.00 Joystick [Thrustmaster T.16000M] on usb-0000:00:02.0-2/input0

could it simply the joystick not sending new state before moving them ? the t16000 got a light below the stick, only on if i start using the stick ...

[Slawek Mikula]

Thanks. If we're digging in the right direction :) it might be that this is a behaviour of the driver/hid layer/anything outside FG. Sorry, don't know right now. If most of the people in this ticket agrees that code/drivers ouside FG seems to have this issue, then I can dig into kernel driver to see how this can be solved or from what cause the values are not in neutral positions. And leave FG in this area as is ;)

This could stop many not needed posts on the forum/mailing list and connecting it with other issues as well.

[Huntley Palmer]

Depends where you put PLIB in that logic. Is it 'in' fgfs or not ?
I would have expected the interface between PLIB and the stick would be of interest.

The dhc2 problem, reported on both WIN10 and Ubuntu, is looking like a JSBSim problem with the supposed castering tailwheel steering the plane and asymmetrically resetting the joystick rudder inputs. Then, has the 'pure joystick' issue been seen on Windows ?

[Slawek Mikula]

user@computer:/usr/bin$ ldd jstest
    linux-vdso.so.1 (0x00007ffc7ef29000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f38d2b96000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f38d318c000)

user@computer:/usr/bin$ ldd evtest
    linux-vdso.so.1 (0x00007ffc02908000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fab5b175000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fab5b773000)

i don't think so. PLIB does not have anything to do with your test using jstest or evtest. If the issue is there when using this software, then PLIB is rather not involved in this :)

Edited; Sorry i mean reports from jean. Huntley - please test it also with jstest/evtest and report.

[Huntley Palmer]

Read again, please. The problem is not visible on evtest; last night I posted js_demo patch and output shoing how the samples change from bad to good with no user input. js_demo uses PLIB.

I've already reported on evtest: One machine: contunual output lines with analogue axes noisy around midpoint, I read that as correct, Fe29. The other machine starts evtest and then outputs no report lines. Since you say evtest is an events reporter, not a true joystick reader, then that PC with the same joystick controller is reporting no joystick events until the stick is actually moved. That's a Fedora31 box, I suppose fingering the different OS is more credible than claiming a noisy USB interface.

jstest is not available either in Fedora or in rpm fusion, those two repos are about as daring as I wish to be for package management.

Ah, I see jean has experienced this outside of fgfs/plib. OK, well, X-Plane, Torcs etc; searching for anybody else seeing 'joystick stuck at full deflection' yields nothing; we see it on at least four Linux distros using flightgear. 'Baffling'

[Slawek Mikula]

Thanks. Sorry - i haven't read your post careful enough. There is Linux Joystick API which uses jstest and js_demo (I suppose also FG). If evtest does not show this and other shows then is can be something with joystick API. https://www.kernel.org/doc/html/v4.18/input/joydev/index.html Look there in programming API about JS_EVENT_INIT events. It might be this. we have to check FG source for handling this events.

[Slawek Mikula]

Some links:

• jstest for fc29 is in this package: https://fedora.pkgs.org/29/fedora-x86_64/linuxconsoletools-1.6.0-2.fc29.x86_64.rpm.html ages when I use FC/RedHat
• kernel joystick API - https://www.kernel.org/doc/html/v4.18/input/joydev/joystick-api.html
• https://www.kernel.org/doc/Documentation/input/joystick-api.txt
• linux kernel source for joydev module with JS_EVENT_INIT code: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/input/joydev.c?h=v5.4.14#n288
• plib joystick code with handling of events: https://sourceforge.net/p/plib/code/HEAD/tree/trunk/src/js/jsLinux.cxx#l164
• js_demo source: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Input/js_demo.cxx

If someone is brave enough to look at it and find the cause, it would be great :) I've limited time for FG, so i do not make a promise.

For me:

• joystick kernel API indeed have info about handling data when joystick does not send data and it mark this packages wit JS_EVENT_INIT flag
• PLIB clears this flag and looks at the event code and value
• I don't know how the test you all mentioned (cold start and init joydev kernel + app) makes that on someone computer value is 0 and on other +/- MAX. I suppose the answer is "it depends" and MAYBE (just maybe) there should not be clearing the JS_EVENT_INIT flag and in this case the code should return 0 because the packages are only for initialization purpose and the real value is not reliable
• if evtest is OK, jstest have error and js_demo have error -> there is my assumption that kernel is behaving weird. If only js_demo -> something is wrong on path Kernel Joy API -> PLIB -> FG

Ok, if Huntley could you check the jstest app and try to find some pattern with this, then maybe there would be enough knowledge what is really happening :)

[Bjoern K]

As promised, some more testing with the T16000M and the XBox 360 Pad on both my desktop PC and laptop. Both have different hardware (AMD and Intel), but almost the exact same Arch Linux configuration.

Conditions:
Plugged in controller with the computer off
Booted into Arch Linux
* Ran "jstest /dev/input/js0" and monitored output

Desktop PC (Ryzen 3700X on X570 UD) - T16000M

Shows the symptom already reported (rolling to the left after fgfs start)

jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (Thrustmaster T.16000M) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y)
and 16 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, ?, ?, ?, BtnDead).
Testing ... (interrupt to exit)
...
Axes:  0:-32767  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off 13:off 14:off 15:off 

Desktop PC (Ryzen 3700X on X570 UD) - XBox 360 pad

Don't mind the initial offset for axis 0,1 and 3. The pad's potentiometers are a bit worn
An interesting side effect with the standard FG control mapping for the XB360 pad is that the left trigger (axis 2) is assigned as the throttle axis, which means that the aircraft will exhibit a 100% throttle setting after the left trigger is pressed for the first time (because the axis reports an initial value of -32767). Holding left trigger resets the throttle to zero. I guess this is due to the mapping being written for Windows, whose driver does report different axis numbers.

jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (Microsoft X-Box 360 pad) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes:  0:  3043  1:    78  2:     0  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3: -1803  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3: -1803  4:  3028  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3: -1803  4:  3028  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3: -1803  4:  3028  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  3043  1:    78  2:-32767  3: -1803  4:  3028  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off

Laptop (i7 6700HQ on some generic mainboard) - T16000M

Jstest output is the exact same as for the T16000M on my desktop PC. Exhibits aileron roll issue when starting fgfs until moving the stick.
(Note: Js0 is reserved for the laptop's acelerometer or the touchpad)

jstest /dev/input/js1
Driver version is 2.1.0.
Joystick (Thrustmaster T.16000M) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y)
and 16 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, ?, ?, ?, BtnDead).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 1
Axes:  0:-32767  1:-32767  2:-32767  3:-32767  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off 13:off 14:off 15:off

Laptop (i7 6700HQ on some generic mainboard) - XBox 360 pad

No issue, but unlike the desktop PC, it uses a custom controller mapping with a correct axis assignment for Linux and therefor does not exhibit the throttle issue stated above.

jstest /dev/input/js1
Driver version is 2.1.0.
Joystick (Microsoft X-Box 360 pad) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:     0  2:     0  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:     0  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:     0  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:  2814  5:     0  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:  2814  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:  2814  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9
Axes:  0:  2523  1:    78  2:-32767  3:     0  4:  2814  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off

Kernel modules

On both computers, lsmod lists
evdev
joydev
as common, relevant kernel modules.

Summary

• The deflection issue can be reproduced on different computers (AMD/Intel)
• The common denominators are the T16000M, evdev and joydev
• The T16000M has a powersaving/auto-off feature while the Xbox 360 pad is constantly powered on

Moving the T16000M just a little powers it on. A slight flick with the finger resets the jstest output value to zero.

I support the notion that the issue is rooted somewhere in joydev (or evdev). However, the question is what should be done about it.
Joydev/evdev fix with the risk of waiting a long time before the fix goes mainline or making FG more robust, i.e. making it wait for hardware input before deflecting controls from neutral?

Edit: further info

Tried another thing with the T16000M on the desktop.

• Ran jstest. Output: -32767. Terminated jstest.
• Unplugged and replugged T16000M using the same USB port
• Ran jstest. Output: -32767. Terminated jstest.
• Unplugged and plugged T16000M into another USB port
• Ran jstest. Output: -32767.
• Flicked T16000M
• Jstest output: 0.
• Waited till the base light of the T16000M turned off.
• Terminated jstest.
• Unplugged T16000M and replugged T16000M into original USB port.
• Ran jstest. Output: -32767. Terminated jstest.

For me, this is a definite issue with joydev/evdev now.

[Huntley Palmer]

I looked in jsLinux.cxx already, to my mind JS_EVENT_INIT is a mask literal ( kernel source include/uapi/linux/joystick.h: #define JS_EVENT_INIT 0x80

which is then used to mask and ignore the 'initial' bit in jsLinux.cxx:

 switch ( os->js.type & ~JS_EVENT_INIT )
{
  case JS_EVENT_BUTTON :
    if ( os->js.value == 0 ) /* clear the flag */
      os->tmp_buttons &= ~(1 << os->js.number) ;
    else
      os->tmp_buttons |=  (1 << os->js.number) ;
    break ;

  case JS_EVENT_AXIS:
    if ( os->js.number < num_axes )
    {
      os->tmp_axes [ os->js.number ] = (float) os->js.value ;

      if ( axes )
        memcpy ( axes, os->tmp_axes, sizeof(float) * num_axes ) ;
    }
    break ;

which, to me, suggests that jsLinux will happily pass whatever axis value it sees in the js structure regradless of the JS_EVENT_INIT bit being set in the js.type .

Replacing with:
if ( !( os->js.type & JS_EVENT_INIT)) {
switch ( os->js.type )
{
case JS_EVENT_BUTTON :
if ( os->js.value == 0 ) / clear the flag /
os->tmp_buttons &= ~(1 << os->js.number) ;
else
os->tmp_buttons |= (1 << os->js.number) ;
break ;

    case JS_EVENT_AXIS:
      if ( os->js.number < num_axes )
      {
        os->tmp_axes [ os->js.number ] = (float) os->js.value ;

        if ( axes )
          memcpy ( axes, os->tmp_axes, sizeof(float) * num_axes ) ;
      }
      break ;

    default:
      jsSetError ( SG_WARN, "PLIB_JS: Unrecognised /dev/js return!?!" ) ;

      /* use the old values */

      if ( buttons != NULL ) *buttons = os->tmp_buttons ;
      if ( axes    != NULL )
        memcpy ( axes, os->tmp_axes, sizeof(float) * num_axes ) ;

      return ;
  }
}

.. and rebuilding. I'm posting this untested in order to power down.

[Slawek Mikula]

guys, this is getting really interesting :) From my side. When I attach logitech joystick and run jstest with --event flag (see help for jstest for options) i have this:

zorba@Latitude-E5450:~$ jstest --event /dev/input/js0 
Driver version is 2.1.0.
Joystick (Logitech Logitech Extreme 3D) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y)
and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
Testing ... (interrupt to exit)
Event: type 129, time 73341912, number 0, value 0
Event: type 129, time 73341912, number 1, value 0
Event: type 129, time 73341912, number 2, value 0
Event: type 129, time 73341912, number 3, value 0
Event: type 129, time 73341912, number 4, value 0
Event: type 129, time 73341912, number 5, value 0
Event: type 129, time 73341912, number 6, value 0
Event: type 129, time 73341912, number 7, value 0
Event: type 129, time 73341912, number 8, value 0
Event: type 129, time 73341912, number 9, value 0
Event: type 129, time 73341912, number 10, value 0
Event: type 129, time 73341912, number 11, value 0
Event: type 130, time 73341912, number 0, value 0
Event: type 130, time 73341912, number 1, value 0
Event: type 130, time 73341912, number 2, value 0
Event: type 130, time 73341912, number 3, value 32767
Event: type 130, time 73341912, number 4, value 0
Event: type 130, time 73341912, number 5, value 0

and when i move something i get:

Event: type 2, time 73346796, number 3, value 32092
Event: type 2, time 73346812, number 3, value 31754
Event: type 2, time 73346932, number 3, value 31078
Event: type 2, time 73347020, number 3, value 32092

So, the 129 and 130 decimal is 0x81 and 0x82 with flag JS_EVENT_INIT set. In my case logitech or kernel driver somehow reports always 0. I think in your cases the events 130 will be with value -MAX/+MAX (in my case axis 3 = throttle and it is OK - 0 is in the middle).

I first read about TMaster power-save mode from your post. Anyway. Huntley I think (don't read carefully your code) the thing to try is to ignore JS_EVENT_INIT values and replace them with "0". And when joystick moves it would provide real values. Normally joysticks are with springs that move they to neutral position so "0" is better.

Anyway I don't see anything better. Modyfing kernel code is a bit lenthy and involving.

[Bjoern K]

T16000M on desktop PC:

jstest --event /dev/input/js0
Driver version is 2.1.0.
Joystick (Thrustmaster T.16000M) has 6 axes (X, Y, Rz, Throttle, Hat0X, Hat0Y)
and 16 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6, ?, ?, ?, BtnDead).
Testing ... (interrupt to exit)
Event: type 129, time 1439342239, number 0, value 0
Event: type 129, time 1439342239, number 1, value 0
Event: type 129, time 1439342239, number 2, value 0
Event: type 129, time 1439342239, number 3, value 0
Event: type 129, time 1439342239, number 4, value 0
Event: type 129, time 1439342239, number 5, value 0
Event: type 129, time 1439342239, number 6, value 0
Event: type 129, time 1439342239, number 7, value 0
Event: type 129, time 1439342239, number 8, value 0
Event: type 129, time 1439342239, number 9, value 0
Event: type 129, time 1439342239, number 10, value 0
Event: type 129, time 1439342239, number 11, value 0
Event: type 129, time 1439342239, number 12, value 0
Event: type 129, time 1439342239, number 13, value 0
Event: type 129, time 1439342239, number 14, value 0
Event: type 129, time 1439342239, number 15, value 0
Event: type 130, time 1439342239, number 0, value -32767
Event: type 130, time 1439342239, number 1, value -32767
Event: type 130, time 1439342239, number 2, value -32767
Event: type 130, time 1439342239, number 3, value -32767
Event: type 130, time 1439342239, number 4, value 0
Event: type 130, time 1439342239, number 5, value 0
Event: type 2, time 1439347609, number 0, value 0
Event: type 2, time 1439347609, number 1, value 0
Event: type 2, time 1439347609, number 2, value 0
Event: type 2, time 1439347609, number 3, value 27362

"Type 2" was triggered by flicking the handle.
No updates after the stick switches off again.

Is fixing the kernel module the way to go?

[Huntley Palmer]

Analogue axes cannot be relied upon to be spring-loaded to zero, e.g Throttle, mixture, true pitch axis ( GA and Tabletop yoke), prop pitch etc. Potatoes tomatoes, don't send anything or send a false value other than the one read.
Two machines, both showing full rudder deflection on HUD after cold start with the original code, show properly centered flight controls after applying the fix to jsLinux.cxx shown above.
If that section above is, indeed, the source of the issue then by all means change the fix to send zeroes.

[Bjoern K]

Funnily enough, running FlightGear, fixing the initial deflection by moving and recentering the stick, then unplugging the controller and replugging it into the same USB port will produce a -32767 output in jstest, but will not affect /devices/status/joysticks/joystick/axis[n] (which duly stays at zero).

[Slawek Mikula]

Guys, great job IMHO. Huntley can I ask you to create patch file for the code, you have created and attach it to this ticket ?

Next I think it is a good time to return this ticket to the developer's mailing list for the review to core devs (btw. I'm not one of them ;)). You all have get this thing nailed and get working :) Of course they view can be different (and they have more knowledge in this area) but in this ticket is all, that is needed for good issue tracking.

PS. As a side note. If you really really want to get to the root of the cause it to dig deep into linux kernel (whole usb stack > joydev -> hid -> usb) and I think if you go this way, you'll end up in the joystick firmware and it's USB HID code. Maybe something is in the USB enumeration from the device side. Logitech 3d extreme does not show this issue. So I think there is something in the joystick code which obviously works in the windows but not on the linux (ages before I have something to done with very low level hardware USB enumeration from windows OS and linux, and I must say what on the Windows side was happening, could be filmed as a comedy-horror). Anyway I think it isn't worth looking at.