Help request: VDR CoreElec (chroot oder Zabrimus) und amremote/eventlird

beta · 6. Mai 2022

jrie: Danke für die Info. Ich muss mir das mal näher anschauen. Ich würde auch gerne verstehen, warum meson-ir im Gegensatz zu meson-remote so laggy ist bei verschlüsselten Sendern und 4K-Auflösung (in HD ist alles OK).

jrie · 7. Mai 2022

Richtig perfekt kann das mit dem Key-Press und Key-Release System sowieso nicht werden, siehe hier.

Ist der meson-ir bzw. der amremote Code eigentlich open source und irgendwo einsehbar?

beta · 7. Mai 2022

Zitat von jrie

Ist der meson-ir bzw. der amremote Code eigentlich open source und irgendwo einsehbar?

Ja, im CoreElec github, kernel linux-amlogic https://github.com/CoreELEC/li…ivers/media/rc/meson-ir.c

amremote findet man hier: https://github.com/CoreELEC/amremote

jrie · 8. Mai 2022

In dem Code sieht man, wie /dev/amremote konfiguriert wird, aber nicht wie die Tastendrücke nach /dev/amremote kommen.

Ich habe noch das gefunden.

Da müsste dir jemand helfen, der sich damit auskennt.

Wenn das nicht gelingt, wäre es am einfachsten, das remote-plugin entsprechend anzupassen (einen Timer starten bei Tastendruck der Autorepeats generiert, bei Tastenrelease den stoppen).

Notfalls ginge ein externer Empfänger am USB.

Für LE gibt es sogar (etwas älteren) Code von mir für meinen irmplircd-Empfänger, ebenso wenn man den Kernel selbst baut einen Patch für meinen Tastaturempfänger. Die reagieren jedenfalls absolut präzise ohne jeglichen lag und da würde ich auch Support leisten.

Natürlich wäre es viel eleganter das Amlogic Meson IR zum Laufen zu bekommen.

Dr. Seltsam · 28. Januar 2023

Zitat von beta

amremote funktioniert mit dem remote-Plugin. Das muss ich allerdings patchen, damit es keinen exklusiven zugriff auf das event-Device nimmt (sonst ist KODI nicht mehr bedienbar).

Kannst Du Deinen Patch für das remote-Plugin mal posten?

Zitat von beta

Das funktioniert sowie auch, außer dass ich hier keine Repeats im VDR habe.

Hast Du in der remote.conf von amremote die Tasten, die repeats erzeugen sollen, nochmal in den Abschnitt zwischen

Code

repeat_key_begin
repeat_key_end

kopiert?

Zitat von beta

Allerdings ist die Wiederholrate so schnell, dass VDR sie nicht kennt, Das Programm auf der Webseite des Plugins zum Setzen der Rate funktioniert nicht, da die ioctl calls nicht im Kernel implementiert sind, d.h. Tasten-Wiederholungen funktionieren nicht.

Hast Du das gelöst? Wenn ja, wie?

beta · 28. Januar 2023

Ich habe einfach folgende Zeilen aus-kommentiert, damit remote nicht exklusiven Zugriff auf das Device erhält:

Code

< //    if (ioctl(f, EVIOCGRAB, data) == 0)
< //        dsyslog("%s: exclusive access granted", name);

Meine remote.conf habe ich nicht mehr, da ich den Weg nicht mehr weiter verfolgt habe (Tasten-Wiederholungen haben nicht funktioniert).

Bei mir in der chroot-Umgebung läuft die Fernbedienung gut, wenn ich einmal für eine Sekunde KODI starte und danach den VDR. Das betrifft aber nur KEINE FTA-Sender. Bei allen FTAs läuft die Fernbedienung auch, ohne dass ich KODI vorher gestartet habe.

Dr. Seltsam · 9. April 2023

Zitat von beta

Ich antworte mir mal selbst. Das remote-Plugin funktioniert prinzipiell, die events können abgefragt und VDR auch bedient werden. Allerdings ist die Wiederholrate so schnell, dass VDR sie nicht kennt, Das Programm auf der Webseite des Plugins zum Setzen der Rate funktioniert nicht, da die ioctl calls nicht im Kernel implementiert sind, d.h. Tasten-Wiederholungen funktionieren nicht. Das Problem ist nur, dass das remote plugin das event nicht freigibt, so dass nach einem Umschalten zu KODI die Fernbedienung da nicht mehr funktioniert. Das ist alles ziemlich unschön. Ich werde wohl den Hardkernel-Treiber (meson-ir) auf CE portieren müssen, was wegen der DVB-Abhängigkeiten (z.B. crazycat-Treiber) nicht einfach ist.

Moin beta,

ich muss hier nochmal nachfragen. Du kamst beim Testen der Fernbedienung mit meson-remote bzw. amremote (statt meson-ir) zu der Erkenntnis, dass die Tastenwiederholungen deshalb nicht funktionieren, weil die Wiederholrate so schnell ist, dass VDR sie nicht erkennt. War das eine Vermutung oder hattest Du das irgendwie ermittelt?

Ich will immer noch auf amremote umsteigen, weil die Fernbedienung damit deutlich besser läuft. Mit meson-ir muss ich die Fernbedienung genau auf den Empfänger richten, mit amremote reagiert sie auch dann, wenn ich sie an die Decke oder an die Wand hinter mir richte. Und sie läuft flüssiger. Bei meson-ir muss ich um das Prellen zu verhindern repeat- und delay-Werte mit ir-keytable setzen, die die Fernbedienung beim Scrollen dann träger machen.

Ich konnte inzwischen das remote-Plugin als Ursache für die fehlenden Wiederholungen ausschließen. Man braucht es auch gar nicht. Es muss lediglich in /storage/.config/udev.rules.d/ eine amlremote.rules mit folgendem Inhalt angelegt werden:

Code

ATTRS{name}=="aml_keypad", \
ENV{eventlircd_enable}="true"

Danach kann man eventlircd starten und es erkennt dann auch die events von meson-remote und übersetzt sie für vdr sie als normale lirc-Signale. Allerdings wiederum ohne funktionierende Tastenwiederholungen. Das liegt m.E. daran, dass entweder die getesteten Fernbedienungen keine Wiederholungen senden oder der Treiber sie generell nicht erzeugt. Bei gestopptem eventlircd und Test mit evtest sehe ich, dass bei gedrückter Taste keine Wiederholungen erkannt werden. Beim Drücken kommt genau 1x (egal wie lange man drückt)

Code

Event: time        1680960656.896313, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1

und beim Loslassen erscheint

Code

Event: time        1680960662.250876, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0

Das konnte ich sowohl mit der Original-FB der Tanix TX3 als auch mit einer Universal-FB und den Codes eines NEC-Videorekorders nachvollziehen. Man kann zwar in der remote.conf für amremote repeat-Einstellungen vornehmen, aber die zeigten bei mir keine Wirkung.

Solltest Du hingegen eine Fernbedienung haben, die mit amremote laut evtest tatsächlich Wiederholungen sendet, wäre das ein neuer Erkenntnisgewinn - dann liegt es nicht am meson-remote-Treiber.

Seahwak hatte mich auf ein Python-Script für eine ps3-FB aufmerksam gemacht, das er für yavdr mal geschrieben hatte und das Wiederholungen erzeugt. Damit werde ich jetzt mal experimentieren.

SurfaceCleanerZ · 10. April 2023

Hi,

Ob Wiederholungen bei IR-Fbs gesendet werden kannst du dir doch anschauen : Einfach mit Kamera aufnehmen, die können die IR Frequenzen noch sehen.

MfG Stefan

vdr_rossi · 28. September 2023

Gibt es hier neue Erkenntnisse?

Möchte beim Odroid N2+ den onboard IR zur vdr Bedienung nutzen. Meine aktuelle Config ist eine RC5 FB von Technotrend mit leicht verzögerter Bedienung und Nachlauf. Als Basis verwende ich https://github.com/Zabrimus/VDRSternELEC

Immerhin funktioniert einschalten und fernbedienen damit.

Bin an einer Softwarelösung mit Boardmitteln interessiert, ohne FLIRC o.ä....

Munter bleiben, Rossi

Dr. Seltsam · 28. September 2023

Ich habe das mit amremote jetzt tatsächlich hingekriegt. Das ist etwas tricky und und Zabrimus müsste dafür python-evdev in seine Distri aufnehmen. Die Tastenwiederholungen übernimmt dann ein zwischengeschaltetes python-Script, das seahawk1986 ursprünglich mal für die ps3remote geschrieben hatte.

Achtung: amremote funktioniert nur mit NEC-Codes. Einschalten ist auch möglich. Hast Du vielleicht eine programmierbare FB, die NEC Codes kann? Wenn das kein k.o.Kriterium ist und Zabrimus das Paket aufnimmt, schreibe ich ein HowTo. Bei mir läuft es in Ubuntu-chroot, aber direkt in CE sollte es sogar einfacher sein.

vdr_rossi · 28. September 2023

Zitat von Dr. Seltsam

Achtung: amremote funktioniert nur mit NEC-Codes. Einschalten ist auch möglich. Hast Du vielleicht eine programmierbare FB, die NEC Codes kann? Wenn das kein k.o.Kriterium ist und Zabrimus das Paket aufnimmt, schreibe ich ein HowTo.

Ja, meine One for all URC1635 kann NEC.

*Edit: RC6 kann sie auch, aber in diesem Zusammenhang dummes Zeug

Super, das freut mich.

Zabrimus · 28. September 2023

Zitat von Dr. Seltsam

Das ist etwas tricky und und Zabrimus müsste dafür python-evdev in seine Distri aufnehmen.

Das habe ich probiert, aber der cross-compile für python-evdev klappt nicht. Ich verstehe nicht, was genau fehlt oder falsch ist.

Code

Build _python-evdev
BUILD      _python-evdev (target)
    TOOLCHAIN      manual
running build_ext
ecodes.c already exists ... skipping build_ecodes
building 'evdev._input' extension
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/bin/armv8a-libreelec-linux-gnueabihf-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=native -O2 -Wall -pipe -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/include -Wno-format-security -march=native -O2 -Wall -pipe -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/include -Wno-format-security -march=armv8-a+crc -mtune=cortex-a53 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mfloat-abi=hard -mfpu=neon-fp-armv8 -Wall -pipe -O2 -fomit-frame-pointer -fcommon -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8 -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/linux -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include -fPIC -I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8 -c evdev/input.c -o build/temp.linux-x86_64-3.8/evdev/input.o -std=c99 -Wno-error=declaration-after-statement
In file included from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:14:2: error: #error "Something's broken.  UCHAR_MAX should be defined in limits.h."
   14 | #error "Something's broken.  UCHAR_MAX should be defined in limits.h."
      |  ^~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:18:2: error: #error "Python's source code assumes C's unsigned char is an 8-bit type."
   18 | #error "Python's source code assumes C's unsigned char is an 8-bit type."
      |  ^~~~~
In file included from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:43,
                 from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:25,
                 from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/struct_FILE.h:95:3: error: unknown type name 'size_t'
   95 |   size_t __pad5;
      |   ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/struct_FILE.h:98:67: error: 'size_t' undeclared here (not in a function)
   98 |   char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)];
      |                                                                   ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/struct_FILE.h:1:1: note: 'size_t' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
  +++ |+#include <stddef.h>
    1 | /* Copyright (C) 1991-2020 Free Software Foundation, Inc.
In file included from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:46,
                 from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:25,
                 from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/cookie_io_functions_t.h:28:43: error: expected declaration specifiers or '...' before 'size_t'
   28 |                                           size_t __nbytes);
      |                                           ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/cookie_io_functions_t.h:37:44: error: expected declaration specifiers or '...' before 'size_t'
   37 |                                            size_t __nbytes);
      |                                            ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/cookie_io_functions_t.h:57:3: error: unknown type name 'cookie_read_function_t'
   57 |   cookie_read_function_t *read;  /* Read bytes.  */
      |   ^~~~~~~~~~~~~~~~~~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/bits/types/cookie_io_functions_t.h:58:3: error: unknown type name 'cookie_write_function_t'
   58 |   cookie_write_function_t *write; /* Write bytes.  */
      |   ^~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:25,
                 from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:292:35: error: expected declaration specifiers or '...' before 'size_t'
  292 | extern FILE *fmemopen (void *__s, size_t __len, const char *__modes)
      |                                   ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:298:47: error: expected declaration specifiers or '...' before 'size_t'
  298 | extern FILE *open_memstream (char **__bufloc, size_t *__sizeloc) __THROW __wur;
      |                                               ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:309:20: error: expected declaration specifiers or '...' before 'size_t'
  309 |       int __modes, size_t __n) __THROW;
      |                    ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:315:10: error: expected declaration specifiers or '...' before 'size_t'
  315 |          size_t __size) __THROW;
      |          ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:354:44: error: expected declaration specifiers or '...' before 'size_t'
  354 | extern int snprintf (char *__restrict __s, size_t __maxlen,
      |                                            ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:358:45: error: expected declaration specifiers or '...' before 'size_t'
  358 | extern int vsnprintf (char *__restrict __s, size_t __maxlen,
      |                                             ^~~~~~
In file included from /home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:25,
                 from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:609:30: error: expected declaration specifiers or '...' before 'size_t'
  609 |                              size_t *__restrict __n, int __delimiter,
      |                              ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:612:28: error: expected declaration specifiers or '...' before 'size_t'
  612 |                            size_t *__restrict __n, int __delimiter,
      |                            ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:622:27: error: expected declaration specifiers or '...' before 'size_t'
  622 |                           size_t *__restrict __n,
      |                           ^~~~~~
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include/stdio.h:651:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'fread'
  651 | extern size_t fread (void *__restrict __ptr, size_t __size,
      |               ^~~~~

<ganz viele weiter Fehlermeldungen>

evdev/input.c:577:5: note: (near initialization for 'moduledef.m_free')
evdev/input.c:577:5: error: initializer element is not constant
evdev/input.c:577:5: note: (near initialization for 'moduledef.m_free')
evdev/input.c: In function 'moduleinit':
evdev/input.c:584:11: warning: comparison of distinct pointer types lacks a cast
  584 |     if (m == NULL) return NULL;
      |           ^~
evdev/input.c:584:27: warning: returning 'PyMethodDef *' from a function with incompatible return type 'PyObject *' {aka 'struct _object *'} [-Wincompatible-pointer-types]
  584 |     if (m == NULL) return NULL;
      |                           ^~~~
error: command '/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/bin/armv8a-libreelec-linux-gnueabihf-gcc' failed with exit status 1
FAILURE: scripts/build _python-evdev during make_target (package.mk)
*********** FAILED COMMAND ***********
python3 setup.py build_ext
**************************************

Alles anzeigen

Dr. Seltsam · 28. September 2023

Da scheinen header nicht zu passen. Fehlt evtl. python-dev oder python3-devel oder so ähnlich?

Es wird versucht, gegen Header von python 3.8 zu kompilieren. Ist CE nicht schon bei einer höheren Version?

Wo hast Du die Sourcen von python-evdev her? Ist das überhaupt eine Version die python3 unterstützt?

Zabrimus · 29. September 2023

Zitat von Dr. Seltsam

Da scheinen header nicht zu passen. Fehlt evtl. python-dev oder python3-devel oder so ähnlich?
Es wird versucht, gegen Header von python 3.8 zu kompilieren. Ist CE nicht schon bei einer höheren Version?
Wo hast Du die Sourcen von python-evdev her? Ist das überhaupt eine Version die python3 unterstützt?

Die Python3 Header werden schon gefunden. Verwendet habe ich die aktuelle Version (git) aus dem Repository: https://github.com/gvalkov/python-evdev.

Kompiliert habe ich mit CE 19. Es kann sein, daß 20 oder 21 schon höher sind. Welche Python Versionen tatsächlich untersützt werden ist irgendwie so gar nicht herauszufinden. Aus der setup.py könnte man schliessen, daß es die Versionen 3.6 - 3.11 sind, aber das ist etwas unsicher.

Code

classifiers = [
    'Development Status :: 5 - Production/Stable',
    'Programming Language :: Python :: 3',
    'Programming Language :: Python :: 3.6',
    'Programming Language :: Python :: 3.7',
    'Programming Language :: Python :: 3.8',
    'Programming Language :: Python :: 3.9',
    'Programming Language :: Python :: 3.10',
    'Programming Language :: Python :: 3.11',
    'Operating System :: POSIX :: Linux',
    'Intended Audience :: Developers',
    'Topic :: Software Development :: Libraries',
    'License :: OSI Approved :: BSD License',
    'Programming Language :: Python :: Implementation :: CPython',
]

Alles anzeigen

Mal ein Beispiel, daß ich nicht verstehe.

Code

Compiler-Parameter:
-I/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/glibc-2.32/usr/include

Limits.h:
grep UCHAR_MAX ./glibc-2.32/include/limits.h
#  define UCHAR_MAX     255
#   define CHAR_MAX     UCHAR_MAX

Compiler-Fehlermeldung:
In file included from evdev/input.c:10:
/home/rh/projekte/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/python3.8/Python.h:14:2: error: #error "Something's broken.  UCHAR_MAX should be defined in limits.h."
   14 | #error "Something's broken.  UCHAR_MAX should be defined in limits.h."
      |  ^~~~~

Alles anzeigen

Ich habe auch die Reihenfolge der "-I" geändert, aber das brachte nicht das gewünschte Ergebnis.

Dr. Seltsam · 29. September 2023

Probier mal unter CE 20 zu bauen. Könnte ein Bug im Compiler sein:

[solved] Something's broken. UCHAR_MAX should be defined in limits.h. - FreeCAD Forum

rell · 29. September 2023

Zabrimus: wie sieht deine package.mk aus?

Zabrimus · 30. September 2023

Zitat von Dr. Seltsam

Probier mal unter CE 20 zu bauen. Könnte ein Bug im Compiler sein:

Ich habe den 20er Build gerade mal gestartet. Mal schauen, ob das besser geht.

Zitat von rell

wie sieht deine package.mk aus?

Ich habe die mal angehängt. Committen wollte ich erst, wenn es klappt. Und wenn es nur für CE20 und hoffentlich LE funktioniert.

package.mk.txt

rell · 30. September 2023

Bei mir hat es gestern "gebaut", allerdings hat es x86 Sachen erstellt in einem arm build.

Ich kann dir am abend die package.mk schicken.

Ich musste die Header angeben.

python-evdev/setup.py at main · gvalkov/python-evdev

Python bindings for the Linux input subsystem. Contribute to gvalkov/python-evdev development by creating an account on GitHub.

github.com

Mit ${SYSROOT_PREFIX}/...

Zabrimus · 30. September 2023

Zitat von rell

Bei mir hat es gestern "gebaut", allerdings hat es x86 Sachen erstellt in einem arm build.
Ich kann dir am abend die package.mk schicken.

Bei den x86 Sachen wurde ich auch etwas stutzig. Da bist weiter als ich. Der CE20er Build funktioniert auch nicht. Allerdings wird sich jetzt über size_t beschwert. Irgendwas ist in meinem Build wohl grundsätzlich falsch.

rell · 2. Oktober 2023

Code

# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2016-present Team LibreELEC (https://libreelec.tv)

PKG_NAME="_python-evdev"
PKG_VERSION="2dd6ce6364bb67eedb209f6aa0bace0c18a3a40a"
PKG_SHA256="b802f9e25c6c218facd54780c4b3d6436fb769d51e3aa286df63a382a4c799ab"
PKG_LICENSE=""
PKG_SITE="https://github.com/gvalkov/python-evdev/"
PKG_URL="https://github.com/gvalkov/python-evdev/archive/${PKG_VERSION}.zip"
PKG_DEPENDS_TARGET="toolchain libevdev Python3 distutilscross:host"
PKG_SOURCE_DIR="python-evdev-${PKG_VERSION}"
PKG_LONGDESC="Python bindings for the Linux input subsystem"
PKG_TOOLCHAIN="manual"

pre_configure_target() {
  export LDSHARED="${CC} -shared"
}

make_target() {
  python setup.py \
         build \
         build_ecodes --evdev-headers ${SYSROOT_PREFIX}/usr/include/linux/input.h:${SYSROOT_PREFIX}/usr/include/linux/input-event-codes.h \
         build_ext --include-dirs ${SYSROOT_PREFIX}/
}

makeinstall_target() {
  python setup.py install --root=$INSTALL/usr --home=""
}

post_makeinstall_target() {
  find ${INSTALL}/usr/lib -name "*py" -exec rm -rf "{}" ";"
}

Alles anzeigen

So baut das bei mir und landet in /usr/lib/python. Keine Ahnung, ob das reicht und ob es nicht /usr/lib/python3.11 sein sollte. Getestet unter LE/RK3399.

Vielleicht hilft dir das weiter.

Help request: VDR CoreElec (chroot oder Zabrimus) und amremote/eventlird

Jetzt mitmachen!

Teilen