atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.92k stars 111 forks source link

Can't install xpadneo on OSMC Raspberry-Pi 4 version #296

Open SchwingMC opened 3 years ago

SchwingMC commented 3 years ago

Version of xpadneo

v0.9-63-gf17a4e2

Severity / Impact

Describe the bug

During installation the error message "Error! Bad return status for module build on kernel: 5.10.32-1-osmc (aarch64)" is given. lsmod | grep hid_xpadneo returns nothing. sudo modprobe hid_xpadneo gives error message "modprobe: FATAL: Module hid_xpadneo not found in directory /lib/modules/5.10.32-1-osmc"

Steps to Reproduce

I followed the installation instruction for osmc as outlined on the front page.

Expected behavior

Screenshots/Gifs

System information

# uname -a

Linux osmc 5.10.32-1-osmc #1 SMP PREEMPT Wed Apr 28 05:45:57 UTC 2021 aarch64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)

xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor: No such file or directory

Controller and Bluetooth information

Additional context

kakra commented 3 years ago

Do you have any more context, e.g. the build log?

SchwingMC commented 3 years ago

`osmc@osmc:~/xpadneo$ sudo ./install.sh

Creating symlink /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/source -> /usr/src/hid-xpadneo-v0.9-63-gf17a4e2

DKMS: add completed.

Kernel preparation unnecessary for this kernel. Skipping...

Building module: cleaning build area... make -j4 KERNELRELEASE=5.10.32-1-osmc -C /lib/modules/5.10.32-1-osmc/build M=/va r/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src VERSION=v0.9-63-gf17a4e2 modul es...(bad exit status: 2) Error! Bad return status for module build on kernel: 5.10.32-1-osmc (aarch64) Consult /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/make.log for more infor mation. `

SchwingMC commented 3 years ago

DKMS make.log for hid-xpadneo-v0.9-63-gf17a4e2 for kernel 5.10.32-1-osmc (aarch64) Wed Jun 2 23:05:26 CEST 2021 make: Entering directory '/usr/src/rbp2-headers-5.10.32-1-osmc' CC [M] /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/hid-xpadneo.o gcc: error: unrecognized command line option '-mgeneral-regs-only' make[1]: [scripts/Makefile.build:279: /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/hid-xpadneo.o] Error 1 make: [Makefile:1824: /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src] Error 2 make: Leaving directory '/usr/src/rbp2-headers-5.10.32-1-osmc'

kakra commented 3 years ago

gcc: error: unrecognized command line option '-mgeneral-regs-only'

As far as I know, this isn't an option that we do set. Which gcc version are you using?

SchwingMC commented 3 years ago

gcc --version outputs this: gcc (Debian 8.3.0-6) 8.3.0

kakra commented 3 years ago

Please try sudo ARCH=arm ./install.sh. Does it work then?

SchwingMC commented 3 years ago

Hi, this did something. Installation now gives no error message. But lsmod | grep hid_xpadneo still returns nothing and sudo modprobe hid_xpadneo returns modprobe: ERROR: could not insert 'hid_xpadneo': Exec format error. As far as I know this should not happen. Build log gives : DKMS make.log for hid-xpadneo-v0.9-63-gf17a4e2 for kernel 5.10.32-1-osmc (aarch64) Thu Jun 3 20:41:32 CEST 2021 make: Entering directory '/usr/src/rbp2-headers-5.10.32-1-osmc' CC [M] /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/hid-xpadneo.o MODPOST /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/Module.symvers CC [M] /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/hid-xpadneo.mod.o LD [M] /var/lib/dkms/hid-xpadneo/v0.9-63-gf17a4e2/build/src/hid-xpadneo.ko make: Leaving directory '/usr/src/rbp2-headers-5.10.32-1-osmc'

I should mention there is a second make.log in /var/lib/dkms/hid-xpadneo/kernel-5.10.32-1-osmc-aarch64/log It has the same content as the given log. I don't know if this is normal.

kakra commented 3 years ago

Maybe ARCH=aarch64 is needed instead? At least we are onto something. Actually, I found the hint about ARCH on a website about RPi3 while researching your problem. It looks like the aforementioned -mgeneral-regs-only is a compiler flag exclusively supported for ARM processors. This may indicate that some configuration is broken in the RPi OS, as apparently the kernel make files try to use that option but the GCC compiler does not feel like doing so - unless you specify the architecture.

Exec format error usually tells us that the executable code is not targeted for the current architecture, so we probably just need to find the right parameter for ARCH.

You're not trying to make the module from a cross-compilation environment, or are you? (that is, compiling on a different host than the target)

SchwingMC commented 3 years ago

sudo ARCH=aarch64 ./install.sh gives the same error as the normal installation process : Error! Bad return status for module build on kernel: 5.10.32-1-osmc (aarch64) The make.log content is: DKMS make.log for hid-xpadneo-v0.9-63-gf17a4e2 for kernel 5.10.32-1-osmc (aarch64) Thu Jun 3 22:16:42 CEST 2021 make: Entering directory '/usr/src/rbp2-headers-5.10.32-1-osmc' Makefile:682: arch/aarch64/Makefile: No such file or directory make: *** No rule to make target 'arch/aarch64/Makefile'. Stop. make: Leaving directory '/usr/src/rbp2-headers-5.10.32-1-osmc'

You're not trying to make the module from a cross-compilation environment, or are you?

I installed osmc with the official windows app as outlined here: https://discourse.osmc.tv/t/testing-kodi-v19-builds-for-raspberry-pi-2-3-4/89152

I just noticed that it is mentioned that buster-devel is the default repository for that build, is this maybe the source of error? The xpadneo installation is done via ssh.

kakra commented 3 years ago

Try with ARCH=arm64. It seems to expect a directory name from the linux/arch directory.

SchwingMC commented 3 years ago

Trying sudo ARCH=arm64 ./install.sh doesn't work. It results in the known error: "Error! Bad return status for module build on kernel: 5.10.32-1-osmc (aarch64)" , with the gcc error in the make.log.

kakra commented 3 years ago

I'd guess that this is a bug in OSMC then... We don't do anything special, we just use existing kernel build infrastructure, and that seems to be broken. We could maybe work around it from xpadneo somehow, but TBH, that approach doesn't look right. If the guys from OSMC suggest a way to properly work around that issue, I'm willing to put it into xpadneo, but without access to a real physical system, I don't think there's much I can help with currently, other than suggesting to upgrade to a newer gcc version, or trying CC=clang or CC=gcc-8.1 instead or something (if the system had multiple compiler versions).

SchwingMC commented 3 years ago

Ok, the people at OSMC mentioned that the problem seems to be building a 64-bit kernel module in a 32-bit userspace. To build it natively on a raspberry pi 4 aarch64-toolchain-osmc is needed. I have not managed to do that succesfully yet, I will tell you, if I do.

kakra commented 3 years ago

Okay, we can add that to the documentation then.

defanator commented 2 years ago

@SchwingMC any luck in building xpadneo under OSMC? I'm facing exactly the same issue, still trying to figure out how to proceed.

defanator commented 2 years ago

@SchwingMC I have created a makefile to cover all steps required in order to build kernel module in chrooted environment under OSMC (https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886), but unfortunately I'm still unable to get everything working as expected. Currently I'm stuck with the following:

root@rpi4-osmc:/home/osmc# ./Makefile.xpadneo-osmc-aarch64 
cd xpadneo/hid-xpadneo && make ../VERSION
make[1]: Entering directory '/home/osmc/xpadneo/hid-xpadneo'
make[1]: '../VERSION' is up to date.
make[1]: Leaving directory '/home/osmc/xpadneo/hid-xpadneo'
rm -rf /opt/osmc-tc/aarch64-toolchain-osmc/root/xpadneo && cp -r xpadneo /opt/osmc-tc/aarch64-toolchain-osmc/root/
chroot /opt/osmc-tc/aarch64-toolchain-osmc /bin/sh -c 'cd /root/xpadneo/hid-xpadneo && make modules'
make[1]: Entering directory '/root/xpadneo/hid-xpadneo'
make -C /usr/src/linux INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/root/xpadneo/hid-xpadneo/src VERSION="v0.9-93-gcf392a7" modules
make[2]: Entering directory '/usr/src/rbp464-source-5.10.78-2-osmc'
cp /root/xpadneo/hid-xpadneo/src/hid-xpadneo.c /root/xpadneo/hid-xpadneo/src/xpadneo.c
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo.o
In file included from ./include/linux/types.h:6,
                 from ./include/linux/limits.h:6,
                 from ./include/linux/kernel.h:7,
                 from ./include/linux/delay.h:22,
                 from /root/xpadneo/hid-xpadneo/src/xpadneo.c:11:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
 #include <asm/types.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.build:280: /root/xpadneo/hid-xpadneo/src/xpadneo.o] Error 1
make[2]: *** [Makefile:1825: /root/xpadneo/hid-xpadneo/src] Error 2
make[2]: Leaving directory '/usr/src/rbp464-source-5.10.78-2-osmc'
make[1]: *** [Makefile:12: modules] Error 2
make[1]: Leaving directory '/root/xpadneo/hid-xpadneo'
make: *** [Makefile.xpadneo-osmc-aarch64:38: hid-xpadneo.ko] Error 2

I'm seeing the following files matching to required pattern:

root@rpi4-osmc:/usr/src# find . -name types.h | grep -- 'asm/types.h' | fgrep arm
./rbp464-headers-5.10.78-2-osmc/arch/arm/include/uapi/asm/types.h
./rbp464-headers-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/types.h
./rbp464-source-5.10.78-2-osmc/arch/arm/include/uapi/asm/types.h

However, it doesn't work in a way I'm trying to run the build (I took the guidance for "generic distributions" as dkms does not work in OSMC).

Tagging @kakra and @samnazarko to collect their input (hopefully).

kakra commented 2 years ago

Does OSMC run a 64 bit kernel but only 32 bit user-space? That's certainly possible (and even recommended to use 2 GB+ RAM more effectively) but that's still a little strange if they don't provide a usable build environment for that... I'd probably get some RPi image with a 64-bit user-space, build the kernel there, then copy it over to the other system. Actually, you could USB-mount that image and use chroot to build from within the chroot

defanator commented 2 years ago

@kakra my understanding was that the aarch64-toolchain-osmc package is providing exactly that suitable build environment (https://discourse.osmc.tv/t/wireguard-fails-to-install-with-november-update/91569/19); I'm actually using it in my Makefile. For the reference, here's gcc -v output in default env and in chroot:

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/8/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

I think I'm missing something simple in order to get things finally work.

BTW, is there a kernel configuration file for xpadneo available? Maybe we would use that to run e.g. make modules SUBDIRS=drivers/hid/hid-xpadneo/ from the correct kernel sources location? (I'm not an expert in customizing linux kernels, so please accept my apologies if it's something obvious.)

kakra commented 2 years ago

Well, in the makefile, I see no obvious problems but the error indicates that the headers should probably be installed or mapped into the chroot - it looks like you install those outside of the chroot, and symlinks won't cross chroot, bind mounts do.

defanator commented 2 years ago

@kakra I do exactly bind mounts:

https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-makefile-xpadneo-osmc-aarch64-L21 https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-makefile-xpadneo-osmc-aarch64-L25

Here's what I see in chroot:

root@rpi4-osmc:~/hid-xpadneo# ls -l /usr/src/
total 8
lrwxrwxrwx  1 root root   28 Dec 19 10:40 linux -> rbp464-source-5.10.78-2-osmc
drwxr-xr-x 23 root root 4096 Dec 19 09:55 rbp464-headers-5.10.78-2-osmc
drwxr-xr-x 24 root root 4096 Dec 19 10:32 rbp464-source-5.10.78-2-osmc
root@rpi4-osmc:~/hid-xpadneo# uname -r
5.10.78-2-osmc

The https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-makefile-xpadneo-osmc-aarch64-L28 workaround is for xpadneo as it explicitly sets KERNEL_SOURCE_DIR to /usr/src/linux in https://github.com/atar-axis/xpadneo/blob/master/hid-xpadneo/Makefile#L1

defanator commented 2 years ago

FWIW, I copied kernel config from /boot/ to corresponding source directory and tried to run make modules our of kernel source tree. The process is still going though, but I'm already getting different error when I try to build xpadneo using the same sequence from my makefile:

root@rpi4-osmc:/home/osmc# ./Makefile.xpadneo-osmc-aarch64 
cd xpadneo/hid-xpadneo && make ../VERSION
make[1]: Entering directory '/home/osmc/xpadneo/hid-xpadneo'
make[1]: '../VERSION' is up to date.
make[1]: Leaving directory '/home/osmc/xpadneo/hid-xpadneo'
sudo rm -rf /opt/osmc-tc/aarch64-toolchain-osmc/root/xpadneo && sudo cp -r xpadneo /opt/osmc-tc/aarch64-toolchain-osmc/root/
sudo chroot /opt/osmc-tc/aarch64-toolchain-osmc /bin/sh -c 'cd /root/xpadneo/hid-xpadneo && make modules'
make -C /usr/src/linux INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/root/xpadneo/hid-xpadneo/src VERSION="v0.9-93-gcf392a7" modules
make[1]: Entering directory '/usr/src/rbp464-source-5.10.78-2-osmc'
cp /root/xpadneo/hid-xpadneo/src/hid-xpadneo.c /root/xpadneo/hid-xpadneo/src/xpadneo.c
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo.o
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo/core.o
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo/consumer.o
  LD [M]  /root/xpadneo/hid-xpadneo/src/hid-xpadneo.o
WARNING: Symbol version dump "Module.symvers" is missing.
         Modules may not have dependencies or modversions.
  MODPOST /root/xpadneo/hid-xpadneo/src/Module.symvers
WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol check will be entirely skipped.
  CC [M]  /root/xpadneo/hid-xpadneo/src/hid-xpadneo.mod.o
make[3]: *** No rule to make target 'scripts/module.lds', needed by '/root/xpadneo/hid-xpadneo/src/hid-xpadneo.ko'.  Stop.
make[2]: *** [scripts/Makefile.modpost:130: __modpost] Error 2
make[1]: *** [Makefile:1729: modules] Error 2
make[1]: Leaving directory '/usr/src/rbp464-source-5.10.78-2-osmc'
make: *** [Makefile:12: modules] Error 2
make: *** [Makefile.xpadneo-osmc-aarch64:38: hid-xpadneo.ko] Error 2

The only differences from https://github.com/atar-axis/xpadneo/issues/296#issuecomment-997370118 is that there appeared another asm/types.h under kernel sources tree:

root@rpi4-osmc:/usr/src# chroot /opt/osmc-tc/aarch64-toolchain-osmc/
root@rpi4-osmc:/# cd /usr/src/
root@rpi4-osmc:/usr/src# find . -name types.h | grep -- 'asm/types.h' | fgrep arm
./rbp464-headers-5.10.78-2-osmc/arch/arm/include/uapi/asm/types.h
./rbp464-headers-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/types.h
./rbp464-source-5.10.78-2-osmc/arch/arm/include/uapi/asm/types.h
./rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/types.h
SchwingMC commented 2 years ago

Hi @defanator, I'm sorry, I have not much to report. I'm that Cillit guy from the OSMC forums. As far as I understand you are going in the right direction. The OSMC guys told me that the OSMC toolchain is needed and it may be troublesome to make DKMS work with that, but you already figured that out. I don't know if that helps but I'm using a custum Libreelec-RR build from SupervisedThinking that can be found here: https://forum.libreelec.tv/thread/23644-libreelec-rr-10-x-brave-spotify-moonlight-emulationstation-retroarch-pegasus/?pageNo=1 In this build xpadneo works just fine, with the onboard Bluetooth device. USB-bluetooth devices won't work. Here is the makefile from that build: `# SPDX-License-Identifier: GPL-2.0

Copyright (C) 2021-present Frank Hartung (supervisedthinking (@) gmail.com)

PKG_NAME="xpadneo" PKG_VERSION="0.9.1" PKG_SHA256="1f3617b0689d93877a706a52037649d6cad011cf70491b5b43da015a02312058" PKG_LICENSE="GPL-3.0-or-later" PKG_SITE="https://atar-axis.github.io/xpadneo/" PKG_URL="https://github.com/atar-axis/xpadneo/archive/refs/tags/v${PKG_VERSION}.tar.gz" PKG_DEPENDS_TARGET="toolchain linux bluez" PKG_NEED_UNPACK="${LINUX_DEPENDS}" PKG_LONGDESC="Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)" PKG_IS_KERNEL_PKG="yes" PKG_TOOLCHAIN="make"

make_target() { kernel_make -C $(kernel_path) M=${PKG_BUILD}/hid-xpadneo/src modules }

makeinstall_target() { mkdir -p ${INSTALL}/$(get_full_module_dir)/kernel/drivers/hid cp -rv ${PKG_BUILD}/hid-xpadneo/src/*.ko ${INSTALL}/$(get_full_module_dir)/kernel/drivers/hid

Install modprobe.d config files

cp -PRv ${PKG_DIR}/config/* ${INSTALL} }`

defanator commented 2 years ago

Ok, the following action fixed module.lds issue for me:

# cp /usr/src/rbp464-headers-5.10.78-2-osmc/scripts/module.lds /usr/src/rbp464-source-5.10.78-2-osmc/scripts/

Kernel source package does not seem to include the script in question:

osmc@rpi4-osmc:~$ dpkg -L rbp464-source-$(uname -r) | grep -- "module.lds$"
osmc@rpi4-osmc:~$ dpkg -L rbp464-headers-$(uname -r) | grep -- "module.lds$"
/usr/src/rbp464-headers-5.10.78-2-osmc/scripts/module.lds
osmc@rpi4-osmc:~$ 

Here's how it goes for me now:

osmc@rpi4-osmc:~$ make -f Makefile.xpadneo-osmc-aarch64 
git clone https://github.com/atar-axis/xpadneo.git
Cloning into 'xpadneo'...
remote: Enumerating objects: 3909, done.
remote: Counting objects: 100% (399/399), done.
remote: Compressing objects: 100% (196/196), done.
remote: Total 3909 (delta 255), reused 266 (delta 193), pack-reused 3510
Receiving objects: 100% (3909/3909), 20.63 MiB | 1.85 MiB/s, done.
Resolving deltas: 100% (2471/2471), done.
sudo cp -p /usr/src/rbp464-headers-5.10.78-2-osmc/scripts/module.lds /usr/src/rbp464-source-5.10.78-2-osmc/scripts/module.lds
cd xpadneo/hid-xpadneo && make ../VERSION
make[1]: Entering directory '/home/osmc/xpadneo/hid-xpadneo'
git describe --tags --dirty >../VERSION
make[1]: Leaving directory '/home/osmc/xpadneo/hid-xpadneo'
sudo rm -rf /opt/osmc-tc/aarch64-toolchain-osmc/root/xpadneo && sudo cp -r xpadneo /opt/osmc-tc/aarch64-toolchain-osmc/root/
sudo chroot /opt/osmc-tc/aarch64-toolchain-osmc /bin/sh -c 'cd /root/xpadneo/hid-xpadneo && make modules'
make -C /usr/src/linux INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/root/xpadneo/hid-xpadneo/src VERSION="v0.9-93-gcf392a7" modules
make[1]: Entering directory '/usr/src/rbp464-source-5.10.78-2-osmc'
cp /root/xpadneo/hid-xpadneo/src/hid-xpadneo.c /root/xpadneo/hid-xpadneo/src/xpadneo.c
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo.o
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo/core.o
  CC [M]  /root/xpadneo/hid-xpadneo/src/xpadneo/consumer.o
  LD [M]  /root/xpadneo/hid-xpadneo/src/hid-xpadneo.o
WARNING: Symbol version dump "Module.symvers" is missing.
         Modules may not have dependencies or modversions.
  MODPOST /root/xpadneo/hid-xpadneo/src/Module.symvers
WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol check will be entirely skipped.
  CC [M]  /root/xpadneo/hid-xpadneo/src/hid-xpadneo.mod.o
  LD [M]  /root/xpadneo/hid-xpadneo/src/hid-xpadneo.ko
make[1]: Leaving directory '/usr/src/rbp464-source-5.10.78-2-osmc'
sudo install -m644 -o osmc -g osmc /opt/osmc-tc/aarch64-toolchain-osmc/root/xpadneo/hid-xpadneo/src/hid-xpadneo.ko hid-xpadneo.ko

osmc@rpi4-osmc:~$ make -f Makefile.xpadneo-osmc-aarch64 
make: Nothing to be done for 'default'.

osmc@rpi4-osmc:~$ file hid-xpadneo.ko 
hid-xpadneo.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), BuildID[sha1]=e17c454d47cd374b12f5946dc2ff6391b93d4749, not stripped

I have updated the makefile to include workaround for module.lds thing. Also, the following report seems to be relevant but for another distro (Ubuntu): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1906131

(cc/ @samnazarko)

defanator commented 2 years ago

As far as I understand you are going in the right direction. The OSMC guys told me that the OSMC toolchain is needed and it may be troublesome to make DKMS work with that, but you already figured that out.

@SchwingMC in fact what I'm doing is one-time action with the goal of getting working .ko for a single kernel version; I gave up on DKMS under OSMC already, it doesn't seem like a reliable option.

Good news though - I made some success here, see https://github.com/atar-axis/xpadneo/issues/296#issuecomment-997403771. Could you please check whether it works on your side as well?

(My current guess is that it won't work in case of clean installation of aarch64-toolchain-osmc - I had to try to run kernel build in the chroot in order to make xpadneo able to be built outside of a kernel source tree; I suppose there's some "bootstrap" action being done from kernel's Makefile, we could investigate it further.)

samnazarko commented 2 years ago

I'm following this.

defanator commented 2 years ago

I managed to find a correct way to bring both required headers and module.lds - before trying to build any kernel modules, make module_prepare should be executed from kernel source tree. I've updated my makefile to include all necessary steps in correct order:

https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-makefile-xpadneo-osmc-aarch64

Also I have tested this on a clean system (no toolchain / kernel headers / kernel sources installed) and attached a full output log for the reference:

https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-install-log-rpi4-txt

Hope this could make life easier for folks dealing with the same stuff.

defanator commented 2 years ago

Perhaps it's too early to celebrate. I was able to build .ko but I can't load it:

root@rpi4-osmc:~/xpadneo/hid-xpadneo# make modules_install
make -C /usr/src/linux INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/root/xpadneo/hid-xpadneo/src VERSION="v0.9-93-gcf392a7" modules_install
make[1]: Entering directory '/usr/src/rbp464-source-5.10.78-2-osmc'
  INSTALL /root/xpadneo/hid-xpadneo/src/hid-xpadneo.ko
  DEPMOD  5.10.78-2-osmc
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/rbp464-source-5.10.78-2-osmc'

The above was done in chroot with /lib/modules/5.10.78-2-osmc mounted through bind and .ko appeared in the tree:

osmc@rpi4-osmc:~$ find /lib/modules/5.10.78-2-osmc/ -name "*xpadneo*"
/lib/modules/5.10.78-2-osmc/kernel/drivers/hid/hid-xpadneo.ko

But it can't be loaded:

osmc@rpi4-osmc:~$ sudo modprobe hid-xpadneo
modprobe: FATAL: Module hid-xpadneo not found in directory /lib/modules/5.10.78-2-osmc

Any hints?

defanator commented 2 years ago

Had to do this:

# sudo cp -p /boot/System.map-5.10.78-2-osmc /usr/src/rbp464-source-5.10.78-2-osmc/System.map

and in chroot:

# apt-get install kmod

After this everything seems to be fine:

root@rpi4-osmc:~/xpadneo/hid-xpadneo# make modules_install
make -C /usr/src/linux INSTALL_MOD_DIR="kernel/drivers/hid" LD=ld.bfd M=/root/xpadneo/hid-xpadneo/src VERSION="v0.9-93-gcf392a7" modules_install
make[1]: Entering directory '/usr/src/rbp464-source-5.10.78-2-osmc'
  INSTALL /root/xpadneo/hid-xpadneo/src/hid-xpadneo.ko
  DEPMOD  5.10.78-2-osmc
make[1]: Leaving directory '/usr/src/rbp464-source-5.10.78-2-osmc'

On host:

osmc@rpi4-osmc:~$ dmesg -T | grep xpad
[Sun Dec 19 20:00:10 2021] hid_xpadneo: no symbol version for module_layout
[Sun Dec 19 20:00:10 2021] hid_xpadneo: loading out-of-tree module taints kernel.
[Sun Dec 19 20:00:10 2021] loaded hid-xpadneo v0.9-93-gcf392a7
kakra commented 2 years ago

The OSMC guys told me that the OSMC toolchain is needed and it may be troublesome to make DKMS work with that

xpadneo ships with a non-dkms build makefile I'm using on Gentoo during development. It's used from the project root by running make -C hid-xpadneo reinstall - the paths and recipes may need adjustments for OSMC but other than that, it's a vanilla build file for a vanilla kernel, no dksm involved.

The makefile linked here for OSMC already resembles some of the steps I'm doing there. The version file needs some special handling and needs to be marked "intermediate" to have it clean up after the build (otherwise you won't see the new version number after a git pull).

All it needs are the dependencies, some working kernel config, and probably running make modules_prepare in the kernel once so at least its headers and the toolchain for building external modules are properly configured. Being a build file for Gentoo, it expects the kernel to already have been built fully at least once. This obviously needs some external dependencies from the distribution, e.g. kmod or a native toolchain.

All of the above steps seem to have been figured out by now - I just wanted to summarize.

kakra commented 2 years ago

as it explicitly sets KERNEL_SOURCE_DIR to /usr/src/linux

Yep, that's somewhat Gentoo specific. A more general approach is outlined in https://github.com/kakra/xpadneo/commit/4b9cff0bd468e4b199232ee491221e6c637b97aa but I didn't cherry-pick that yet as it was causing me problems sometimes and doesn't seem to work in the CI environment.

samnazarko commented 2 years ago

The OSMC guys told me that the OSMC toolchain is needed and it may be troublesome to make DKMS work with that

It's not necessary -- but it'll give you the same toolchain that we use to build the kernel you're using with. It's best to keep the toolchain the same. You can't use build-essential and the tools that package provides from the armhf package however.

We have some hacks for how we package headers -- and they may not be sufficient. But make headers_install on kernel source wasn't providing us with complete headers that allowed any modules to be built, so we took a more manual approach. If anything is missing, I'm happy to get some pointers or even a PR

https://github.com/osmc/osmc/blob/master/package/kernel-osmc/build.sh#L175

Cheers

Sam

defanator commented 2 years ago

@kakra @samnazarko thanks for your input on some details, it's very helpful to have it all here in a single thread.

My suggestion would be to include at least pre-generated arm64 headers - I can't see how it may harm anything given that both rbp464-headers-5.10.78-2-osmc and rbp464-source-5.10.78-2-osmc packages have arm64 arch. Here's the diff between sorted files in kernel source directory before and after make modules_prepare (I'm talking about everything under arch/arm64/include/generated/ tree + at least rbp464-source-5.10.78-2-osmc/scripts/module.lds):

root@rpi4-osmc:/tmp# diff -u src-a src-b
--- src-a   2021-12-20 07:50:39.273757130 +0000
+++ src-b   2021-12-20 07:53:47.714716890 +0000
@@ -1,3 +1,5 @@
+rbp464-source-5.10.78-2-osmc/.config
+rbp464-source-5.10.78-2-osmc/.missing-syscalls.d
 rbp464-source-5.10.78-2-osmc/COPYING
 rbp464-source-5.10.78-2-osmc/CREDITS
 rbp464-source-5.10.78-2-osmc/Documentation/.gitignore
@@ -13859,6 +13861,51 @@
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/asm/xen/page-coherent.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/asm/xen/page.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/asm/xor.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/bugs.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/delay.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/div64.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/dma-mapping.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/dma.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/early_ioremap.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/emergency-restart.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/hw_irq.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/irq_regs.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/kdebug.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/kmap_types.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/local.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/local64.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/mcs_spinlock.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/mm-arch-hooks.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/mmiowb.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/msi.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/qrwlock.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/qspinlock.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/rwonce.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/serial.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/set_memory.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/switch_to.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/trace_clock.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/unaligned.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/user.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/asm/vga.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/errno.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/ioctl.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/ioctls.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/ipcbuf.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/kvm_para.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/msgbuf.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/poll.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/resource.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/sembuf.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/shmbuf.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/siginfo.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/socket.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/sockios.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/stat.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/swab.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/termbits.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/termios.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/include/generated/uapi/asm/types.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/Kbuild
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/auxvec.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/bitsperlong.h
@@ -13879,6 +13926,7 @@
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/sve_context.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/ucontext.h
 rbp464-source-5.10.78-2-osmc/arch/arm64/include/uapi/asm/unistd.h
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/.asm-offsets.s.cmd
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/.gitignore
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/Makefile
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/acpi.c
@@ -13887,6 +13935,7 @@
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/alternative.c
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/armv8_deprecated.c
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/asm-offsets.c
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/asm-offsets.s
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/cacheinfo.c
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/cpu-reset.S
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/cpu-reset.h
@@ -13972,13 +14021,23 @@
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/traps.c
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso.c
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.gitignore
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.note.o.cmd
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.sigreturn.o.cmd
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.vdso.lds.cmd
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.vdso.so.dbg.cmd
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/.vgettimeofday.o.cmd
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/Makefile
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/gen_vdso_offsets.sh
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/note.S
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/note.o
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/sigreturn.S
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/sigreturn.o
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vdso.S
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vdso.lds
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vdso.lds.S
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vdso.so.dbg
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vgettimeofday.c
+rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso/vgettimeofday.o
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso32/.gitignore
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso32/Makefile
 rbp464-source-5.10.78-2-osmc/arch/arm64/kernel/vdso32/note.c
@@ -57722,6 +57781,7 @@
 rbp464-source-5.10.78-2-osmc/include/config/kdb/continue/catastrophic.h
 rbp464-source-5.10.78-2-osmc/include/config/kdb/default/enable.h
 rbp464-source-5.10.78-2-osmc/include/config/kdb/keyboard.h
+rbp464-source-5.10.78-2-osmc/include/config/kernel.release
 rbp464-source-5.10.78-2-osmc/include/config/kernel/mode/neon.h
 rbp464-source-5.10.78-2-osmc/include/config/kernfs.h
 rbp464-source-5.10.78-2-osmc/include/config/keyboard/gpio.h
@@ -60352,7 +60412,14 @@
 rbp464-source-5.10.78-2-osmc/include/dt-bindings/thermal/thermal.h
 rbp464-source-5.10.78-2-osmc/include/dt-bindings/thermal/thermal_exynos.h
 rbp464-source-5.10.78-2-osmc/include/dt-bindings/usb/pd.h
+rbp464-source-5.10.78-2-osmc/include/generated/.vdso-offsets.h.cmd
+rbp464-source-5.10.78-2-osmc/include/generated/asm-offsets.h
 rbp464-source-5.10.78-2-osmc/include/generated/autoconf.h
+rbp464-source-5.10.78-2-osmc/include/generated/bounds.h
+rbp464-source-5.10.78-2-osmc/include/generated/timeconst.h
+rbp464-source-5.10.78-2-osmc/include/generated/uapi/linux/version.h
+rbp464-source-5.10.78-2-osmc/include/generated/utsrelease.h
+rbp464-source-5.10.78-2-osmc/include/generated/vdso-offsets.h
 rbp464-source-5.10.78-2-osmc/include/keys/asymmetric-parser.h
 rbp464-source-5.10.78-2-osmc/include/keys/asymmetric-subtype.h
 rbp464-source-5.10.78-2-osmc/include/keys/asymmetric-type.h
@@ -64812,6 +64879,7 @@
 rbp464-source-5.10.78-2-osmc/ipc/syscall.c
 rbp464-source-5.10.78-2-osmc/ipc/util.c
 rbp464-source-5.10.78-2-osmc/ipc/util.h
+rbp464-source-5.10.78-2-osmc/kernel/.bounds.s.cmd
 rbp464-source-5.10.78-2-osmc/kernel/.gitignore
 rbp464-source-5.10.78-2-osmc/kernel/Kconfig.freezer
 rbp464-source-5.10.78-2-osmc/kernel/Kconfig.hz
@@ -64829,6 +64897,7 @@
 rbp464-source-5.10.78-2-osmc/kernel/auditsc.c
 rbp464-source-5.10.78-2-osmc/kernel/backtracetest.c
 rbp464-source-5.10.78-2-osmc/kernel/bounds.c
+rbp464-source-5.10.78-2-osmc/kernel/bounds.s
 rbp464-source-5.10.78-2-osmc/kernel/bpf/Makefile
 rbp464-source-5.10.78-2-osmc/kernel/bpf/arraymap.c
 rbp464-source-5.10.78-2-osmc/kernel/bpf/bpf_inode_storage.c
@@ -67994,6 +68063,7 @@
 rbp464-source-5.10.78-2-osmc/scripts/.extract-cert.cmd
 rbp464-source-5.10.78-2-osmc/scripts/.gitignore
 rbp464-source-5.10.78-2-osmc/scripts/.kallsyms.cmd
+rbp464-source-5.10.78-2-osmc/scripts/.module.lds.cmd
 rbp464-source-5.10.78-2-osmc/scripts/.recordmcount.cmd
 rbp464-source-5.10.78-2-osmc/scripts/.sorttable.cmd
 rbp464-source-5.10.78-2-osmc/scripts/Kbuild.include
@@ -68435,15 +68505,33 @@
 rbp464-source-5.10.78-2-osmc/scripts/mkmakefile
 rbp464-source-5.10.78-2-osmc/scripts/mksysmap
 rbp464-source-5.10.78-2-osmc/scripts/mkuboot.sh
+rbp464-source-5.10.78-2-osmc/scripts/mod/.devicetable-offsets.s.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.elfconfig.h.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.empty.o.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.file2alias.o.cmd
 rbp464-source-5.10.78-2-osmc/scripts/mod/.gitignore
+rbp464-source-5.10.78-2-osmc/scripts/mod/.mk_elfconfig.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.modpost.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.modpost.o.cmd
+rbp464-source-5.10.78-2-osmc/scripts/mod/.sumversion.o.cmd
 rbp464-source-5.10.78-2-osmc/scripts/mod/Makefile
 rbp464-source-5.10.78-2-osmc/scripts/mod/devicetable-offsets.c
+rbp464-source-5.10.78-2-osmc/scripts/mod/devicetable-offsets.h
+rbp464-source-5.10.78-2-osmc/scripts/mod/devicetable-offsets.s
+rbp464-source-5.10.78-2-osmc/scripts/mod/elfconfig.h
 rbp464-source-5.10.78-2-osmc/scripts/mod/empty.c
+rbp464-source-5.10.78-2-osmc/scripts/mod/empty.o
 rbp464-source-5.10.78-2-osmc/scripts/mod/file2alias.c
+rbp464-source-5.10.78-2-osmc/scripts/mod/file2alias.o
+rbp464-source-5.10.78-2-osmc/scripts/mod/mk_elfconfig
 rbp464-source-5.10.78-2-osmc/scripts/mod/mk_elfconfig.c
+rbp464-source-5.10.78-2-osmc/scripts/mod/modpost
 rbp464-source-5.10.78-2-osmc/scripts/mod/modpost.c
 rbp464-source-5.10.78-2-osmc/scripts/mod/modpost.h
+rbp464-source-5.10.78-2-osmc/scripts/mod/modpost.o
 rbp464-source-5.10.78-2-osmc/scripts/mod/sumversion.c
+rbp464-source-5.10.78-2-osmc/scripts/mod/sumversion.o
+rbp464-source-5.10.78-2-osmc/scripts/module.lds
 rbp464-source-5.10.78-2-osmc/scripts/module.lds.S
 rbp464-source-5.10.78-2-osmc/scripts/modules-check.sh
 rbp464-source-5.10.78-2-osmc/scripts/nsdeps

Obviously, I may miss some knowledge of OSMC internals, especially in regards to platforms other than Raspberries, so I don't think I'm in a good position to propose this as a PR.

@kakra I think though that the proposed helper makefile (https://gist.github.com/defanator/5535f0acfba6aaaa222a5439da582886#file-makefile-xpadneo-osmc-aarch64) could be used as a reference in FAQ/docs covering possible way of building xpadneo under OSMC. It still needs some generalization in terms of using correct kernel/source prefixes (currently it's using hardcoded one for RPI4).

kakra commented 2 years ago

I think though that the proposed helper makefile

Yes, I could think of the following (and already had that idea but wanted to wait until everything works):

  1. We could outsource the variables and general recipes to a distribution-specific Makefile, e.g. "Makefile-osmc.def", "Makefile-gentoo.def", "Makefile-generic.def" etc, then include that in the standard Makefile - or maybe the other way around
  2. Such include files would be some sort of configuration files and recipe providers for distribution-specific quirks and config
  3. This should become a PR once the OSMC-specific parts settled and have been prepared for generalization
  4. I was thinking about having a global makefile to replace all the bash installers that are currently there, leaving dkms-specifics only for the bare minimum
  5. The new "installation backend" must work for the generic case by default so it can pass our CI
Depansho commented 2 years ago

I was also trying to install the xpadneo on osmc, but without any success.

It seems like @defanator managed to get it installed and running. I followed your instructions step by step but unfortunately I am unable to get it running properly. Tbh I am also not very faimilar with building things in linux, so I just understand half what you did. What I did so far to get it running:

It seems like you did something here https://github.com/atar-axis/xpadneo/issues/296#issuecomment-997425813 that I did not understand (especially the part with running in chroot). Could you please describe that part a bit more detailed (and more understandable for newbies 😄)

cwildfoerster commented 2 years ago

I was also trying to install the xpadneo on osmc, but without any success.

It seems like @defanator managed to get it installed and running. I followed your instructions step by step but unfortunately I am unable to get it running properly. Tbh I am also not very faimilar with building things in linux, so I just understand half what you did. What I did so far to get it running:

It seems like you did something here #296 (comment) that I did not understand (especially the part with running in chroot). Could you please describe that part a bit more detailed (and more understandable for newbies 😄)

hi got it working.

first, make sure do "redo" the steps mentioned in the readme for osmc, due to an overwriting error while installing the kernel sources in the makefile:

sudo apt-get purge rbp2-headers-`uname -r`
sudo rm -rf "/lib/modules/`uname -r`/build"

after that, just in a random folder:

# install build tools
sudo apt install build-essential git wget

wget https://gist.githubusercontent.com/defanator/5535f0acfba6aaaa222a5439da582886/raw/b05e5709d59caa525f4d41de2af793572a702780/Makefile.xpadneo-osmc-aarch64
make -f  Makefile.xpadneo-osmc-aarch64

# install and update modules
sudo mv hid-xpadneo.ko /lib/modules/5.10.78-5-osmc/kernel/drivers/hid/
sudo depmod -a

# load and on boot
sudo modprobe hid-xpadneo
echo 'hid-xpadneo' | sudo tee -a /etc/modules

after that, the controller vibrates upon connecting like it should, key mapping is correct and everything works!

Depansho commented 2 years ago

I was also trying to install the xpadneo on osmc, but without any success. It seems like @defanator managed to get it installed and running. I followed your instructions step by step but unfortunately I am unable to get it running properly. Tbh I am also not very faimilar with building things in linux, so I just understand half what you did. What I did so far to get it running:

It seems like you did something here #296 (comment) that I did not understand (especially the part with running in chroot). Could you please describe that part a bit more detailed (and more understandable for newbies 😄)

hi got it working.

first, make sure do "redo" the steps mentioned in the readme for osmc, due to an overwriting error while installing the kernel sources in the makefile:

sudo apt-get purge rbp2-headers-`uname -r`
sudo rm -rf "/lib/modules/`uname -r`/build"

after that, just in a random folder:

# install build tools
sudo apt install build-essential git wget

wget https://gist.githubusercontent.com/defanator/5535f0acfba6aaaa222a5439da582886/raw/b05e5709d59caa525f4d41de2af793572a702780/Makefile.xpadneo-osmc-aarch64
make -f  Makefile.xpadneo-osmc-aarch64

# install and update modules
sudo mv hid-xpadneo.ko /lib/modules/5.10.78-5-osmc/kernel/drivers/hid/
sudo depmod -a

# load and on boot
sudo modprobe hid-xpadneo
echo 'hid-xpadneo' | sudo tee -a /etc/modules

after that, the controller vibrates upon connecting like it should, key mapping is correct and everything works!

I did what you suggested, but apparently it did not work. I tried to connect my xbox series x controller via the my osmc interface and also tried via bluetoothctl. I also disable executed echo 1 > /sys/module/bluetooth/parameters/disable_ertm. For connecting via bluetoothctl I did the following:

scan on pair MAC:ADRESS:OF:CONTROLLER trust MAC:ADRESS:OF:CONTROLLER connect MAC:ADRESS:OF:CONTROLLER

after that the controller is still flashing..

kakra commented 2 years ago

Does dmesg show that xpadneo detects the device? If yes, please check if it recommends a firmware update (this feature exists since v0.9.4).

Depansho commented 2 years ago

Did not find anything in dmesg, but bluetoothctl shows me the following, while the controller keeps flashing;


[CHG] Device 44:16:22:6A:73:9F Connected: yes
[CHG] Device 44:16:22:6A:73:9F Connected: no
[CHG] Device 44:16:22:6A:73:9F Connected: yes
[CHG] Device 44:16:22:6A:73:9F Connected: no
[CHG] Device 44:16:22:6A:73:9F Connected: yes
[CHG] Device 44:16:22:6A:73:9F Connected: no
[CHG] Device 44:16:22:6A:73:9F Connected: yes
[CHG] Device 44:16:22:6A:73:9F Connected: no
[CHG] Device 44:16:22:6A:73:9F Connected: yes
[CHG] Device 44:16:22:6A:73:9F Connected: no
[CHG] Device 44:16:22:6A:73:9F Connected: yes```
cwildfoerster commented 2 years ago

Is your controller running the latest firmware? you need a windows pc for that.

Depansho commented 2 years ago

Does dmesg show that xpadneo detects the device? If yes, please check if it recommends a firmware update (this feature exists since v0.9.4).

Is your controller running the latest firmware? you need a windows pc for that.

thank you very much for your suggestion. I updated the controller and now it works! Thanks everyone for the detailed explanation and your help!

cwildfoerster commented 2 years ago

I ran into the bluetooh not connecting issue when i tried to pair it with my steam link. Older firmware versions seem to not work correctly with standard bluetooth.

kakra commented 2 years ago

I ran into the bluetooh not connecting issue when i tried to pair it with my steam link. Older firmware versions seem to not work correctly with standard bluetooth.

Yes, that's exactly the issue. Even on Windows, the Bluetooth connection is very unstable with some Bluetooth chipset drivers when using the older firmwares. This is why I added a log line for dmesg to xpadneo recommending to upgrade the firmware:

snoweuph commented 1 year ago

running this on a clean osmc install and replacing the numbers to match my versions: 5.10.78-5 -> 5.10.78-7 it worked flawlessley

I also just today got my hands on a windows machine (becuase I dont have any at home and dont want any) at a friends house and did the firmware update on the controller

cwildfoerster commented 1 year ago

running this on a clean osmc install and replacing the numbers to match my versions: 5.10.78-5 -> 5.10.78-7 it worked flawlessley

I also just today got my hands on a windows machine (becuase I dont have any at home and dont want any) at a friends house and did the firmware update on the controller

Keep in mind, this method doesn't create modprobe configs or other files. As you may see in: https://github.com/atar-axis/xpadneo/blob/2900363b8bcc6030ccb1da89a29c637b22f95a60/hid-xpadneo/dkms.post_install#L7-L23 The option to disable ERTM may not be set, depending on your kernel (assuming you're here for osmc, you need this), so you need to do it manually with echo "options bluetooth disable_ertm=Y" > /etc/modprobe.d/bluetooth.conf

I also had issued with input lag, so you may want to have a look at https://atar-axis.github.io/xpadneo/#high-latency-or-lost-button-events-with-bluetooth-le also

snoweuph commented 1 year ago

liek I said it worked for me like described

snoweuph commented 1 year ago

with not flaws

cwildfoerster commented 8 months ago

Unfortunately this doesn't work anymore...

Its a little bit tricky, userland stuff seems to be armhf, installing gcc-10:arm64 gets rid of the gcc: error: unrecognized command-line option ‘-mstack-protector-guard=sysreg’" when cd hid-xpadneo && make modules, but then ld.so failes, but commenting /etc/ld.so.preload makes it possible to build the module. After this, reverting /etc/ld.so.preload and loading the module works. But this is garbage :-D, but it works with steam link, remember to link udev rules.

Kobtul commented 2 weeks ago

Did anybody make it work recently? I did not manage to make it build on my rpi400 on osmc. I just commented libarmen in /etc/ld.so.preload https://stackoverflow.com/questions/42443273/raspberry-pi-libarmmem-so-cannot-open-shared-object-file-error

I am stuck on make[2]: *** /lib/modules/5.15.92-1-osmc/build: No such file or directory. Stop. but the folder is there. It is something with the wrong architecture.