No data being updated from Joystick in o/p of $sudo jstest /dev/input/js0 (Solved)

Hello Everyone,
I’m trying to use Logitech GamePad F710 in Direct Input Mode connected to Xavier using 3.0 USB Hub and eSATA/USB port. I had installed Joystick drivers, jstest-gtk and Gamepad is detected by the system in DirectInput mode under /dev/input/js0.
$ sudo jstest /dev/input/js0
is also showing output, but " Not Registering any Input given by Joystick, keys/buttons".
I would have tried option of installing/enabling XPAD Kernel module, but I think that it’s mostly for “XInput” mode not for “DirectInput” mode.
Can someone help me in getting this thing to work?

Here’s some additional information. The F710 uses a wireless USB dongle. On a TX1/TX2, this is normally handled by usbhid. On the Xavier, this appears to load correctly:

T:  Bus=01 Lev=03 Prnt=03 Port=03 Cnt=03 Dev#= 11 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c219 Rev=03.05
S:  Manufacturer=Logitech
S:  Product=Logitech Cordless RumblePad 2
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=98mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

However, if you look through dmesg, you’ll see:

logitech: probe of 0003:046D:C219.000B failed with error -1

[  110.962170] usb 1-4.3.4: new full-speed USB device number 11 using tegra-xusb
[  110.989198] usb 1-4.3.4: New USB device found, idVendor=046d, idProduct=c219
[  110.989207] usb 1-4.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  110.989211] usb 1-4.3.4: Product: Logitech Cordless RumblePad 2
[  110.989215] usb 1-4.3.4: Manufacturer: Logitech
[  111.039721] input: Logitech Logitech Cordless RumblePad 2 as /devices/3610000.xhci/usb1/1-4/1-4.3/1-4.3.4/1-4.3.4:1.0/0003:046D:C219.0008/input/input9
[  111.040473] logitech 0003:046D:C219.0008: input,hidraw1: USB HID v1.11 Gamepad [Logitech Logitech Cordless RumblePad 2] on usb-3610000.xhci-4.3.4/input0
[  111.040516] logitech: probe of 0003:046D:C219.0008 failed with error -1

The probe error is not present on the TX1/TX2. Not sure on how to go about debugging this.

Hi adh327/Kangalow,
We are checking it. Probably certain config is not enabled by default. Will update.

PLease enable CONFIG_LOGITECH_FF and try.

Hello DaneLLL,
Thank you for suggesting solution, but I couldn’t find proper guide to enable CONFIG_LOGITECH_FF and test the device.
Is it possible for you to provide instructions or link to the same ?

The official documentation shows how to cross compile the kernel from the PC. The following is from a TX2 regarding native compile, but if you have the source code on your Xavier, then it should be very similar or the same:

Here is where you would find official “Documentation” (the driver package documentation is what you are looking for):
…beware that you may need to log in first to see the content, and that if you do, then it won’t redirect you automatically. You may need to click on the URL a second time after login is complete.

I was referred to here regarding a Logitech F710 issue on Jetson Nano Jetbot. Where and How is CONFIG_LOGITECH_FF edited on a Nano? Thanks

You’ll perhaps want to start a new topic (and put in the Nano forum,, but that is a configuration feature to edit prior to compiling a new kernel (or kernel module, which is easier). Generally speaking you’d start with an existing config from your running system: “/proc/config.gz” can be copied somewhere safe, a text editor can be used to change the line for CONFIG_LOCALVERSION to:


The combination of matching CONFIG_LOCALVERSION and the running system’s “/proc/config.gz” gives you a starting configuration which is an exact match to what is already running. This is a substitute (and superior) to what you might read referring to “make something_defconfig”. That file, renamed as “.config”, and placed at the top level directory of your kernel build output location is where it all starts.

Once you have that you’d follow procedures for adding your own change with the “make nconfig” (or similar…there are several options there, but “nconfig” allows searching for symbols/features/options you’re not familiar with) utility prior to actually building the kernel. I realize I skipped a lot there, but the previous thread reply #6 is a reference to all of that information.

The official documentation has a section on kernel customization, and that is what the above refers to. You can usually add new features as a module instead of rebuilding the entire kernel (though it is a sanity check to see if the whole kernel builds first). The advantage is that installing the module is just a file copy.

I am trying to use a Logitech Gamepad F710 on a jetson TX2 on xinput mode. I did follow the above thread. However my problem is slightly different.

The joystick isn’t recognized on startup. After I change the toggle from xinput to direct input on the joystick, the /dev/input/js0 file is created. If i change it back to xinput, the js0 file disappears.

The joystick works fine in direct input mode. Again, it is recognized only after I start up the jetson and toggle the button on the joystick to x and back to d.

On checking the /proc/config.gz file, CONFIG_LOGITECH_FF is set to y.

I require my joystick to work on xinput mode and has to be recognized on startup itself without me having to toggle it back to x and d again.

Would following the steps in the above link solve my problem as well? I would greatly appreciate any help on this.

Thank you!

Is there a joystick that works right out of the box that I don’t have to compile a new kernel or kernel module to use ?

I have the Logitech F310 and I don’t feel qualified to engage in a new kernel procedure. I’d feel safer just buying a new joystick

Hi spyder19,
We use defconfig of k4.9 as a base and add/enable NVIDIA configs. No more 3rdpary configs are enabled. You may check which joysticks is enabled in defconfig of k4.9 by default.

Just a comment on joysticks and drivers. Don’t know if this is related or not, but it is probably something you need to be aware of.

Joysticks are normally a standard “human interface device”, and because of that, a standard driver does the job. The joystick files in “/dev/” are not real files, but are instead part of a driver, and the files come into existence when the driver is told about a hot plug event on USB of a given type and a driver takes ownership of that device.

Some joysticks and mice and other hardware may try to do things the standard HID drivers are unable to do. In that case the HID driver cannot load. Instead those devices need custom drivers…they might do something that joysticks do, but they are not truly joysticks so far as drivers are concerned. If one mode of a joystick produces a “/dev/js0” (or other number) file, then it is likely a standard HID driver and device. If another mode does not produce this, then it means this mode is not really a joystick, at least so far as the standardized drivers are concerned (you would need that custom driver).

If sometimes a particular mode produces the “/dev/js0” file, but other times does not (in the same mode), then you probably have a USB issue and not a driver issue. USB reads a description from the USB device and broadcasts that description to drivers…if sometimes the driver responds and at other times the driver does not respond, then this is a bug.

Actually, I figured it out. Sort of. In the notebook, under teleop, step 4, I changed the index of my controller to “0”

Hi spyder19,

That’s great. Can you elaborate on which file you made the change to and what change that was? Thanks!

Go to the Jupyter Labs Notebook

Open the Teleoperations folder

Go down to step 4

Where it says…

controller = widgets.Controller(index=0) <—this WAS a 1, I changed it to 0, and then it worked

Can you please provide the step to enable CONFIG_LOGITECH_FF.


For me I connected the PS4 controller with my mac. Chrome didn’t work, but safari did.

For “CONFIG_LOGITECH_FF” you’d want to look at the kernel customization documentation. Basically you’d set the kernel source to the same configuration which is already running, and then mark that feature as enabled (preferably in module format). In the case of a module the install is a simple file copy to a subdirectory of “/lib/modules/$(uname -r)/”.


I faced the issue that the jstest program gave no output. It appeared to be a wireless reception issue. Try to place the wireless receiver very close to the controller. In my case, this worked!