Logitech F710 Kernel Module Issues - JetPack 6

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

Using JetPack 6 I have been unable to correctly build the Logitech F710 Game Controller module. In previous versions of JetPack, we set CONFIG_LOGITECH_FF=Y (which is a flag to tell HID-LOGITECH module to build in support for the F710).

In the 5.15 kernel, HID-LOGITECH is built in. However, it does not have support for the F710, so it needs to be rebuilt. Setting CONFIG_HID_LOGITECH=m should allow us to build it as an external module. This assumes that the built-in can be blacklisted when the new module is installed.

Everything compiles following the instructions in the Jetson Developer Guide. hid-logitech.ko appears in the drivers/hid directory. However when modinfo is run on the module when it’s on the Jetson:

$ modinfo hid-logitech.ko

I get:

filename: /lib/modules/5.15.136-tegra/kernel/drivers/hid/hid-logitech.ko
license: GPL
file: drivers/hid/hid-logitech

The other information about the module, like vermagic, does not display. I know that the vermagic string is in the module:

$ strings hid-logitech.ko | grep vermagic
vermagic=5.15.136-tegra SMP preempt mod_unload modversions aarch64
__UNIQUE_ID_vermagic300
__UNIQUE_ID_vermagic300

Not surprisingly, after blacklisting the built in module and trying to insert the new one, the system denies the insertion saying that it taints the kernel. I’ve tried all the tricks I know, built it on a host, built it on the Jetson, udev rules, rebuild everything but I have to claim defeat. The first question is why does this not appear to be in the correct format as the rest of the modules? The other modules that are built in the same directory have the correct format. The build for this particular module does have some flags, but it should build. The Makefile entry is simple:

hid-logitech-y := hid-lg.o
hid-logitech-$(CONFIG_LOGITECH_FF) += hid-lgff.o

Nothing shows in the log files or console to indicate any build or link issues. This feels like some linker or format issue. BTW, I’m jetsonhacks so I knew how to do this at some point. Can someone actually build this and have it in the correct format? It’s:

CONFIG_HID_LOGITECH=m
CONFIG_LOGITECH_FF=Y

and the result should be a viable hid-logitech.ko when examined by modinfo. I know there’s been other forum entries about this, but no one has seemed to actually solve it.

4

Hi,
Many thanks for your help to community. We will set up and try to replicate the issue.

1 Like
5

Can I confirm if the old kernel =y feature is still there? Even with blacklist this might be a problem if it is. Either way, you might want to get an strace of the manual insmod. Create a log file of that, perhaps the system calls will say something related to a system call that already exists (or similar).

6

Here’s the log. What do you mean by ‘kernel=y’ feature, I’m a little confused.

You’re certainly correct about the blacklist. I’ve tried several ways today and get this when I try insmod:

[ 186.291672] hid_logitech: module verification failed: signature and/or required key missing - tainting kernel
[ 186.292208] Error: Driver ‘logitech’ is already registered, aborting…

When I try a -f insmod I get:

insmod: ERROR: could not insert module hid-logitech.ko: Invalid module format

The log for that is in insmod_log_force.txt. A couple of issues, but the first is that even if I could load the module over the builtin, it is most likely in the wrong format to actually work.
I appreciate you looking at this.
insmod_log.txt (6.4 KB)
insmod_log_force.txt (6.4 KB)

7

I just mean that some features are not a module. Features that are built in or integrated are selected with the “y” key in editors like menuconfig or nconfig. Blacklisting a non-module is something I’ve not experimented with. I’m thinking blacklist could work either on a “symbol” basis, or at load time; if symbol basis, then you could blacklist a symbol (but it would blacklist the module too); if based on load time, then you couldn’t stop an integrated feature…those features are always loaded by reading the kernel itself into memory.

Hopefully @DaneLLL can replicate this, but meanwhile (this beats guessing), if using the mainline kernel, then the “tainting” mechanism (lack of proper GNU license for the Logitech software) would kick in. This isn’t what bothers me though, you can work with “tainted” third party software. The exec format error normally means the architecture is wrong, and although I don’t remember what the actual cause was on some previous case of this, exec format error can occur for some other obscure reason. Maybe having both “=y” and “=m” causes this.

Is this cross compiled? If so, do you have the same issue when natively compiled?

Lastly, if you have your kernel configured to match the original kernel, and then you go into an editor such as menuconfig or nconfig, and set that feature off (“=n”), and then set the feature as a module (“=m”), are there other dependencies shown to enable the module? I want to see dependencies. I’m thinking that the symbol for that one feature may not be the only symbol being enabled; in that case it might require doing the same thing to all of the dependencies

8

@linuxdev I see. I’ve attached a modinfo for the 5.0 kernel (JetPack 5/Ubuntu 20.04) which doesn’t list any dependencies. My understanding is that hid-logitech is a module, the flag LOGITECH_FF doesn’t actually generate a module, it’s a build flag for the hid-logitech module.
For Kernel 5.0 the .config is:
CONFIG_HID_LOGITECH=m
CONFIG_HID_LOGITECH_DJ=m
CONFIG_HID_LOGITECH_HIDPP=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set

Then for Kernel 5.15:
CONFIG_HID_LOGITECH=y
# CONFIG_HID_LOGITECH_DJ is not set
# CONFIG_HID_LOGITECH_HIDPP is not set
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set

I’ve tried as many permutations of feature selection as I could stomach, no joy.

This has the same behavior whether it’s compiled on the Jetson or cross compiled on a host. It’s unlikely it’s an architecture issue, it feels more like a linker/dependency one. I’ll try the off/on in menuconfig to see what I can see. I’m sure it’s something terribly simple, but I just don’t know what it is.

9

@linuxdev I don’t see anything out of the ordinary after switching from =y to =n to =m. It looks like the only thing changed is the HID_LOGITECH module from =y to =m. The GCC version is different, this is on the Jetson so it’s natively compiling.

Looking at menuconfig for HID_LOGITECH before starting:

Symbol: HID_LOGITECH [=y] │
│ Type : tristate │
│ Defined at drivers/hid/Kconfig:554 │
│ Prompt: Logitech devices │
│ Depends on: INPUT [=y] && HID [=y] && USB_HID [=y] && LEDS_CLASS [=y] │
│ Location: │
│ → Device Drivers │
│ → HID support │
│ → HID bus support (HID [=y]) │
│ (1) → Special HID drivers │
│

Symbol: LOGITECH_FF [=n] │
│ Type : bool │
│ Defined at drivers/hid/Kconfig:587 │
│ Prompt: Logitech force feedback support │
│ Depends on: INPUT [=y] && HID [=y] && HID_LOGITECH [=y] │
│ Location: │
│ → Device Drivers │
│ → HID support │
│ → HID bus support (HID [=y]) │
│ → Special HID drivers │
│ (4) → Logitech devices (HID_LOGITECH [=y]) │
│ Selects: INPUT_FF_MEMLESS [=y]

Then the diff:

diff .config .config.alt.reset
5c5
< CONFIG_CC_VERSION_TEXT=“aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.08) 11.3.0”

CONFIG_CC_VERSION_TEXT=“gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0”
7c7
< CONFIG_GCC_VERSION=110300

CONFIG_GCC_VERSION=110400
791,793d790
< CONFIG_GCC_PLUGINS=y
< # CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
< # CONFIG_GCC_PLUGIN_RANDSTRUCT is not set
6060c6057
< CONFIG_HID_LOGITECH=y

CONFIG_HID_LOGITECH=m
6063c6060
< # CONFIG_LOGITECH_FF is not set

CONFIG_LOGITECH_FF=y
8976,8979d8972
< # CONFIG_GCC_PLUGIN_STRUCTLEAK_USER is not set
< # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set
< # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set
< # CONFIG_GCC_PLUGIN_STACKLEAK is not set
jim@jetsonhacks:/usr/src/kernel/kernel-jammy-src$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

10

I don’t see a reason why this would occur. I’m hoping that @DaneLLL can replicate this.

On some occasions there might be assembler added directly in to code and cause the code to be non-portable across architectures, but there is no reason that force feedback (or anything HID) would include such code.

Was there any issue with running “sudo depmod -a”? Can you attach your “/lib/modules/$(uname -r)/” files modules.alias, modules.dep, modules.order, modules.softdep, and output of “lsmod”? If the forum doesn’t allow it, just append a .txt to the file names. Make sure you’ve attempted to load the module once.

Also, what is the output of the “file” command when naming the specific .ko module file as the argument?

11

The sudo depmod -a gives:

depmod: ERROR: Bad version passed hid-logitech.ko

That’s not surprising. I’m sure it’s something simple, a magic incantation I’m missing. However, the procedure has been pretty much the same for the last 7 or so years, so something must have changed or maybe I just bungled things.

Here’s the rest of the requested info:

modules.softdep.txt (674 Bytes)
modules.order.txt (37.8 KB)
modules.dep.txt (102.1 KB)
modules.alias.txt (384.8 KB)
lsmod.txt (6.2 KB)

12

I forgot to ask for one other file: “/proc/config.gz”. The reason to ask is because this also gives symbols, but it gives built-in symbols. It is the combination of built-in and modular that defines the kernel as a whole. If config.gz still has the symbol as non-modular, then perhaps it is just a conflict of thinking the built-in is still there. I don’t think blacklist would be enough.

13

Here you go!

config.gz.txt (55.4 KB)

14

I don’t know enough about having a symbol as both module and integrated to say for sure, but I noticed that the alias for “hid” occurs for each of these:

  • hid_multitouch
  • hid_logitech_dj
  • hid_logitech_hidpp

Although I don’t know if this has any actual meaning, I’m thinking that perhaps some other HID symbol conflicts. I believe you showed earlier that HID_LOGITECH does not have any dependencies, but there is a tiny possibility that something else has a dependency which conflicts? Incidentally, there are no loaded “HID” modules, but two of those I listed above are only in the form of a module. Can any of those others (listed above) manually insmod, or do they also have issues?

15

Hi,
Below is the ko file we built:

Linux_for_Tegra/source/kernel$ ll kernel-jammy-src/drivers/hid/hid-logitech.ko
-rw-r--r-- 1 root root 225840  六  24 11:46 kernel-jammy-src/drivers/hid/hid-logitech.ko
Linux_for_Tegra/source/kernel$ md5sum kernel-jammy-src/drivers/hid/hid-logitech.ko
ef7839f8af586e8d78680988eab4e1ab  kernel-jammy-src/drivers/hid/hid-logitech.ko

Not sure if it is identical to yours(file size and md5sum). Please check and confirm. Thanks.

16

@DaneLLL They do not match.

ll hid-logitech.ko
-rw-rw-r-- 1 jim jim 225904 May 28 22:23 hid-logitech.ko
jim@jetsonhacks:~/From-Dell-Logitech$ md5sum hid-logitech.ko
0583408eeb9a6564612bf15f58d8416f hid-logitech.ko

I built this on an Ubuntu 20.04 Host. modinfo for this file works on the host, but not on the Jetson. Did you build on a 22.04 host?

17

Hi,
We built it on 20.04 host.

For information, on AGX Orin, do you see hid-logitech.ko being listed in

/lib/modules/5.15.136-tegra/modules.order
/lib/modules/5.15.136-tegra/modules.dep
/lib/modules/5.15.136-tegra/modules.alias
18

@DaneLLL

grep logitech modules.dep
kernel/drivers/hid/hid-logitech-dj.ko:
kernel/drivers/hid/hid-logitech.ko:
kernel/drivers/hid/hid-logitech-hidpp.ko:

It does not appear in .order or .alias

19

@DaneLLL Just so that I’m clear on this.
Under previous versions, I was able to build the hid-logitech.ko module with the LOGITECH_FF enabled and simply copy it over to the drivers/hid directory, depmod -a and it would work.

hid-logitech is now built in to the kernel. I had thought that I could blacklist the built in and use a newly built module by placing it into the
/lib/modules/5.15.136-tegra/kernel/drivers/hid directory, depmod -a or some other commands, and be good to go.

Where I am in the process: I built the new module on a 20.04 host, transferred it to a Jetson Orin Nano. Copied it over the the drivers/hid directory. In comparison to the one you built, it appears to be too large and does not modinfo or insmod correctly. That leads to the question, does the one you built do both those things?

20

Hi,
We can run $ sudo insmod hid-logitech.ko by executing the steps:

  1. Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation
  2. Enable the configs in defconfig and tegra_prod_defconfig
    CONFIG_LOGITECH_FF=Y
    CONFIG_HID_LOGITECH=m
  3. Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation
  4. Kernel Customization — NVIDIA Jetson Linux Developer Guide 1 documentation
  5. Re-flash the system
  6. Copy built hid-logitech.ko to the system and execute $ sudo insmod hid-logitech.ko

It does not report the error:

[ 2011.864119] hid_logitech: module verification failed: signature and/or required key missing - tainting kernel
[ 2011.865208] Error: Driver 'logitech' is already registered, aborting...

But we don’t have F710 to try. Could you help try the steps and see if the error is not shown. And help check if the driver works?

21

I don’t know if this applies, and differences might be from different compilers, but if both of you strip the modules it then match md5sum and size. See:
https://devtalk.nvidia.com/default/topic/1066506/jetson-tx2/why-the-built-modules-based-on-nvidia-official-kernel-source-/post/5401303/#5401303

The gist (assuming cross compile so it is from the tool chain):

<tool_chain_path>/aarch64-linux-gnu-strip -–strip-unneeded <path-of-kernel-module.ko>
23

I can use F710 in jetpack 6 by using the following command

sudo git clone https://github.com/paroj/xpad.git /usr/src/xpad-0.4
sudo dkms install -m xpad -v 0.4

Hope it helps anyone

3 Likes