IRMP auf STM32 - ein USB-HID-Keyboard IR Empfänger+Einschalter mit Wakeup-Timer

  • Im git gibt es jetzt eine Beschreibung mit Bildern.

    Verbesserungsvorschläge willkommen.

  • Ich habe auf der linux-input Mail-Liste meinen Kernelpatch eingereicht.

    Falls jemand den schon ausprobiert hat, wäre etwas Unterstützung dort schön :)

  • Möglicherweise hilft der Patch auch für den Flirc, dazu müsste man die USB IDs vom Flirc mit rein nehmen. Vielleicht hat ja jemand mal Lust, das auszuprobieren (ich selbst habe keinen Flirc).


    Das sähe dann so aus in hid-irmp.c:

    Code
    1. static const struct hid_device_id irmp_devices[] = {
    2. { HID_USB_DEVICE(USB_VENDOR_ID_IRMP, USB_DEVICE_ID_IRMP_STM32_KBD) },
    3. { HID_USB_DEVICE(0x20A0, 0x0001) },
    4. { }
    5. };
  • Ich arbeite an einem Userspace Progamm, das sich das Keyboard-Gerät schnappt und die Tastendrücke an uinput weiterleitet. Das ist vielleicht besser als ein Kernel Treiber und einfacher in Distributionen einzubauen.

    Muss noch getestet werden und kommt dann in's git.


    Ohne stm32kbd2uinput werden Wiederholungen als neue Tasten erkannt, während mit stm32kbd2uinput Wiederholungen als Wiederholungen erkannt werden.


    Für den VDR ist das ziemlich egal, aber in Kodi funktionieren dann die langen Tastendrücke.

    In allen Fällen gibt es keinerlei Nachlauf.

  • Wenn man doch einen extra Daemon braucht ist halt ein großer Vorteil von dem ganzen "Ohne Treiber weil als Tastatur erkannt" wieder dahin.


    Wo genau ist eigentlich das Problem mit den "langen Tastendrücken"? Man kann Kodi ja auch mit einer "echten" Tastatur bedienen. Zumindest dort hat mich die Tastenwiederholung bisher nie gestört.

  • Ich zitiere mal:

    There are remote control receivers, which register as an USB HID keyboard and

    receive and decode signals from many IR remote controls with all kinds of IR

    protocols (for instance IRMP, the Infra Red Multi Protocol library). Most of

    those IR remote controls only send keys on key press, but not on key release.

    Because of that, the receiver sends either a release after each key press or

    after a timeout, when no key was pressed any more. The first has the

    disadvantage, that each key is processed as new, even if it is a repeat. The

    second has the disadvantage, that the autorepeat feature of the input core

    may generate keys during the timeout, while the user actually already has

    taken his finger of the remote control button.

    In order to solve the problem, this driver was made. It processes keys

    exactly as they were sent. Autorepeat is turned off and key repeats are taken

    from raw events, get translated and are passed on to input.



    Lange Tastendrücke in Kodi funktionieren nur, wenn Kodi sie als solche erkennen kann. Das geht nur wenn Tastenwiederholungen als solche erkannt werden. Kodi belegt kurze Tastendrücke mit anderen Funktionen als lange Tastendrücke.

    Viele benutzen das gar nicht, und dann stört es auch nicht, wenn es nicht geht [1, 2].

    Ein bisschen so wie mit den TSOP Boards mit extra Kondensator und Widerstand: Es geht auch ohne.

    Probier es einfach mal aus. Es ist inzwischen schon ziemlich ausgereift.

  • Wo genau ist eigentlich das Problem mit den "langen Tastendrücken"?

    Normale Tastaturen senden Key-Down und Key-Up Events (bzw. die gerade gedrückten Tasten werden engmaschig übermittelt, bei USB alle 1 - 8 ms, mit Hardware-Interrupt bei PS/2 geht das noch schneller). Die Tastenwiederholungen können in Software interpoliert werden (vgl. z.B. https://wiki.archlinux.org/ind…_typematic_delay_and_rate und https://wiki.archlinux.org/ind…_typematic_delay_and_rate). Du bekommst also in der Voreinstellung für Kernel Input Devices alle 250 ms einen wiederholten Tastendruck, wenn du eine Taste gedrückt gehalten lässt und das System bekommt ohne große Verzögerung mit, wann die Taste wieder losgelassen wurde, so dass praktisch keine ungewollten Wiederholungen generiert werden.


    Bei den meisten IR-Protokollen hast du einen Frame-Abstand von mindestens 100 ms und bekommst pro Frame effektiv ein Key-Down Event (und ggf. über das Toggle-Bit oder einen speziellen Wiederholungsframe den Hinweis, ob die Taste in der Zwischenzeit gedrückt gehalten wurde), aber keine Key-Up Events.

    Du weißt also nicht genau, ob und wann die Taste wieder losgelassen wurde, nur dass sie nicht mehr gerückt gehalten wurde, wenn nach dem typischen Abstand zwischen zwei Frames kein neuer Frame für die selbe Taste kommt (erst dann kann man ein Key-Release Event senden). Es könnten also in einem ca. 100 - 120 ms langen Fenster ungewollt Tastenwiederholungen produziert werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Der andere Unterschied ist das Scrollen durch lange Listen.

    Bei einem langen Tastendruck wird beschleunigt gescrollt.

    Wenn aber der lange Tastendruck fälschlich als viele einzelne erkannt wird, wird nicht beschleunigt.

    Auch dieses Feature ist Geschmackssache, ob man es gut findet mit Beschleunigung oder lieber nicht.


    Unterm Strich hat man die Wahl:

    * Einfach anstecken und geht

    oder

    * etwas Software drum herum und geht etwas besser


    Als Perfektionist will ich natürlich, dass auf Wunsch jegliches Detail super funktioniert, deswegen der Kernel Treiber bzw. jetzt stm32kbd2uinput.

    Ohne geht es gut, mit geht es etwas besser.


    Beim Flirc (soweit ich da Bescheid weiß) gibt es gen1 und gen2.

    gen1 hat einzelne Tastendrücke, gen2 hat Nachlauf.

    Ohne Zusatzsoftware kann eben Beides bei einem Tastaturempfänger prinzipiell nicht gehen.

  • Mit stm32kbd2uinput gibt es unvorhergesehene Probleme, kann also noch dauern.

    Der Kernelpatch funktioniert aber einwandfrei, und solange sollte man den nehmen.


    Oder man akzeptiert die kleinen Einschränkungen und hat dafür den Vorteil, dass man ihn einfach ansteckt und er geht.

    Er muss natürlich einmal mit stm32kbdIRconfig_gui konfiguriert werden, aber dass geht an jedem Windows oder Linux.

  • Kurzanleitung:

    In stm32IRconfig_gui die template.map laden. Die Tasten, die man nicht braucht, entfernen. Flashen. Dann die Fernbedienungstasten anlernen. Fertig.

    Wo finde ich die template.map genau?


    Das IRMP STM32 KBD Configuration Teil stürzt bei mir unter Windows 10 häufig ab.

    Ich muss doch unter eeprom map -> flash eeprom die Configuraton in den Stick flashen?

    Denn genau dabei stürzt er ab...

    Oder anders gefragt: Wie bekomme ich das rechts eingegebene in den Stick?

    The post was edited 3 times, last by vdr_rossi ().

  • Wo finde ich die template.map genau?

    Im git.


    Das IRMP STM32 KBD Configuration Teil stürzt bei mir unter Windows 10 häufig ab.

    Ich muss doch unter eeprom map -> flash eeprom die Configuraton in den Stick flashen?

    Denn genau dabei stürzt er ab...


    Oder anders gefragt: Wie bekomme ich das rechts eingegebene in den Stick?

    Bist du nach dieser Anleitung vorgegangen?

  • Ok, damit komme ich weiter.


    Hatte mich ohne das Template an dem Screenshot aus Beitrag 7 orientiert.

    Da fehlt ff|KEY... hinter dem Code. Was bei mir Abstürze und eben nicht flashen auslöste.

  • Moin,


    hoffe es ist passend, ergänzend zu der grundsätzlichen Frage, wie ein STM32 IRMP HID-KBD-Device unter yavdr ansible zum laufen zu bringen ist.


    Bei mir steht im Syslog:

    Die Entsprechenden Tastencodes (yavdr passend) habe ich auf die KEYs gelegt.

    Paket: yavdr-hardware-irmp und eventlircd ist installiert...


    Sehr vereinzelt kommen Tastendrücke an:

    Code
    1. root@vdr5:/home/rossi# irw /run/lirc/lircd
    2. 2 0 KEY_1 devinput

    Weit weg von einer flüssigen Bedienung.

    Wie kann ich weiter diagnostizieren? Was läuft da schief?


    Danke

  • Paket: yavdr-hardware-irmp und eventlircd ist installiert...

    Das sieht nach einem der neueren IRMP-Empfänger aus, die direkt als Keyboard arbeiten, statt die Tastendrücke über irmplircd weiterzureichen, für die USB-ID hat das Paket yavdr-hardware-irmp bislang keinen Effekt.

    Die Entsprechenden Tastencodes (yavdr passend) habe ich auf die KEYs gelegt.

    Hast du das mit einer evmap gemacht? Ich hatte jrie damals so verstanden, dass man https://github.com/j1rie/IRMP_…tlircd/03_1209_4445.evmap direkt nutzen kann, wenn man den Empfänger mit dem Konfigurationprogramm und dem Template angelernt hat.


    Und dann braucht es noch eine udev-Regel, die dafür sorgt, dass sich eventlircd das Gerät schnappt (danach den Empfänger einmal ab- und wieder anstecken):

    Code: /etc/udev/rules.d/69-irmp-kbd.rules
    1. ACTION=="add", KERNEL=="event[0-9a-f]*", SUBSYSTEM=="input", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4445", SYMLINK+="irmp_stm32", ENV{eventlircd_enable}="true", ENV{eventlircd_evmap}="03_1209_4445.evmap", TAG+="uaccess"


    Wenn das für dich klappt, kann ich das gerne ins Paket aufnehmen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ok, das habe ich so umgesetzt.


    Tastendrücke kommen nur vereinzelt an. Geprüft mit irw...

    Die kleine LED auf dem Stick blinkt aber bei jedem Tastendruck der FB.

    Konfiguration:

    Images

  • Stop mal eventlircd und schau dir mit evtest an, was da für "rohe" Tastendrücke ankommen:

    systemctl mask --runtime --now eventlircd.{socket,service}

    sudo evtest (muss ggf. auf dem gleichnamigen Paket installiert werden, dann den IRMP-Empfänger auswählen).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da kommt nix an:

    Habe eben nochmal die Tastenbelegung/Codes geprüft. Der scheint das nicht 100% in den Stick zu flashen. Zumindest habe ich nach reconnect eine andere Belegung im Stick.

    Obwohl er vorher den Flashvorgang mit ok bestätigt hat...

  • Da muss jrie was zu schreiben.


    Meiner Erfahrung nach, ist das Programm etwäs mäkelig - wenn z.B. das Format nicht passt.

    Bei Dummy Einträgen habe ich #Taste probiert und auch ffffffffffff ff|Taste


    Mein Beispiel im Anhang. Passend zur silbernen Technotrend FB.

    Files