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

  • 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.