Hat sich dann damit erledigt, oder?
IRMP auf Pico - ein USB-HID-Keyboard IR-Empfänger/Sender/Einschalter mit Wake-up Timer
-
-
-
Hat sich dann damit erledigt, oder?
Ja.
-
Das Problem war, dass doppelte Tastendrücke angekommen sind und mir nur softhddevice geläufig ist, aber nicht softhddevice-drm-gles. Unter softhddevice braucht man -N, unter softhddevice-drm-gles braucht man --no-kbd.
Das ist alles.Ok, dazu muss man erstmal den "Tastenfluss" im Vdr verstehen... und ich glaube das habe ich noch nicht zu 100%.
Darum ja auch meine Frage, ob man --no-kbd im irmp Zusammenhang, unabhängig vom Ausgabedevice, setzen sollte?
Schaubild aus yavdr Doku:
[Blocked Image: https://www.yavdr.org/documentation/…lesyaVDR0.5.png]Da fehlt noch die Plugin (z.B. vdr-plugin-irmp oder vdr-plugin-remote) Möglichkeit. Damit wird IR direkt angesprochen und benötigt keine andere "Brücke" aus dem Bild.
Beim Wechsel von Vdr zu Kodi dann aber für Kodi schon.D.h. --no-kbd schaltet auf Vdr Ebene Tastatur/Fernbedienung gleich ab und damit ist zwingend ein irmp oder remote Plugin notwendig? Parallel geht lirc (siehe unten Kasten) auch noch zum Vdr oder Kodi?
Und lirc ist die standard Eingabemöglichkeit für Vdr. Könnte man lirc Eingabe für Vdr nicht auch deaktivieren? das nur vdr-plugin-irmp übrig bleibt.Habe hier erst jetzt gelesen. Ich versteh nicht, was das Problem ist... Siehe RE: [softhddevice-drm-gles] Raspberry 4 und 5
Wie bekäme softhddevice-drm-gles denn mit, dass es einen Menüpunkt anwählen soll, wenn es nicht mehr auf eine Eingabe reagiert?
Ich denke über Vdr und dem lirc Weg. Tastatur kommt ja über eventlircd zum vdr lirc? Ohne eventlircd dann aber gar nicht- korrekt.
Problem ist die doppelte Eingabequelle: Irmp Plugin und Tastatur -> darum -N Patch.Oder habe ich die Zusammenhänge nicht richtig verstanden und Mist geschrieben?
-
softhddevice-drm-gles ist da komplett aus dem Spiel. Das reagiert im Prinzip gar nicht auf irgendwelche Eingaben. Ubd woher die kommen (lirc, kbd, etc.) interessiert es auch nicht bzw. das weiß es auch gar nicht. Wenn man über VDR das Plugin-Menu und irgendwas darin auswählt ö passiert was. Aber dass z.B. OK oder eine Pfeiltaste gedrückt wurde, davon weiß das Plugin nichts. Das kommt von VDR. softhddevice-drm-gles verarbeitet "lowlevel" Eingaben nicht. Es hält sichvaus der Remote-Geschichte komplett raus.
In deinem Schaubild käme das Plugin als Pfeil nach VDR. In alles was vorher passiert, greift es nicht ein.
-
Darum ja auch meine Frage, ob man --no-kbd im irmp Zusammenhang, unabhängig vom Ausgabedevice, setzen sollte?
Wenn man mal eine Tastatur benutzen will eher nicht. Kommt halt drauf an.
Könnte man lirc Eingabe für Vdr nicht auch deaktivieren?
Nicht nötig, da nur an wenn --lirc benutzt wird.
Problem ist die doppelte Eingabequelle: Irmp Plugin und Tastatur -> darum -N Patch.
Ist nur für softhddevice nötig. Bei softhddevice-drm-gles reicht --no-kbd.
-
Das kommt von VDR. softhddevice-drm-gles verarbeitet "lowlevel" Eingaben nicht. Es hält sich aus der Remote-Geschichte komplett raus.
Ok, das ist auch der richtige Weg. Andernfalls ist die Gefahr von Doppeleingabe gegeben.
Damit ein Vdr über Tastatur komplett bedienbar ist, ist eventlircd aber Voraussetzung oder eben das Irmp Plugin für hid raw

-
Nicht nötig, da nur an wenn --lirc benutzt wird.
Gut, dann habe ich --lirc auch aus /storage/.config/vdropt/conf.d/vdr.conf herausgenommen.
-
Es gibt neue Firmware. Ich habe das Verhalten bei Fernbedienungs-Protokoll Wechsel verbessert.
Damit sollten alle durch die Einführung der neuen Features entstandenen Probleme gelöst sein und dem produktivem Einsatz steht nichts im Weg.
-
Da ich vom "STM32_KBD", das mit 1209:4445 einhergeht, weg wollte, ist es glaube ich am saubersten, für "Pico" 1209:4446 zu verwenden.
Bleibt es bei hier bei 1209:4446?
Muss das vielleicht irgendwo in Vendor/Device-ID-Datenbanken eingetragen werden, wie du es für 4443, 4444 und 4445 getan hast?
-
Bleibt es bei hier bei 1209:4446?
Ja.
Muss das vielleicht irgendwo in Vendor/Device-ID-Datenbanken eingetragen werden, wie du es für 4443, 4444 und 4445 getan hast?
Kommt noch.
Aber seit vielen Jahren wurde das nicht übernommen.
4443 und 4444 sind in usb.ids drin, 4445 aber nicht.
Das macht aber nichts. -
-
Die aktuelle Firmware funktioniert noch nicht korrekt als Tastatur. Beim Drücken einer Taste werden viel mehr Events gesendet, als bei der alten kbd Firmware. Im detail werden sämtliche Meta-Tasten als gedrückt gesendet.
Ich habe hier zwei Beispiele der Ausgabe von evtest beim einmaligen kurzen Drücken der Taste "1".
Zuerst die Ausgabe der aktuellen Firmware:Code
Display MoreEvent: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0 Event: time 1767819013.401869, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1 Event: time 1767819013.401869, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2 Event: time 1767819013.401869, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3 Event: time 1767819013.401869, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1 Event: time 1767819013.401869, -------------- SYN_REPORT ------------ Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e4 Event: time 1767819013.401869, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e5 Event: time 1767819013.401869, type 1 (EV_KEY), code 54 (KEY_RIGHTSHIFT), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6 Event: time 1767819013.401869, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 1 Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e7 Event: time 1767819013.401869, type 1 (EV_KEY), code 126 (KEY_RIGHTMETA), value 1 Event: time 1767819013.401869, -------------- SYN_REPORT ------------ Event: time 1767819013.401869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001e Event: time 1767819013.401869, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1767819013.401869, -------------- SYN_REPORT ------------ Event: time 1767819013.655078, type 1 (EV_KEY), code 2 (KEY_1), value 2 Event: time 1767819013.655078, -------------- SYN_REPORT ------------ Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0 Event: time 1767819013.655893, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e1 Event: time 1767819013.655893, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2 Event: time 1767819013.655893, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3 Event: time 1767819013.655893, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0 Event: time 1767819013.655893, -------------- SYN_REPORT ------------ Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e4 Event: time 1767819013.655893, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e5 Event: time 1767819013.655893, type 1 (EV_KEY), code 54 (KEY_RIGHTSHIFT), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6 Event: time 1767819013.655893, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 0 Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e7 Event: time 1767819013.655893, type 1 (EV_KEY), code 126 (KEY_RIGHTMETA), value 0 Event: time 1767819013.655893, -------------- SYN_REPORT ------------ Event: time 1767819013.655893, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001e Event: time 1767819013.655893, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1767819013.655893, -------------- SYN_REPORT ------------
Und dann die Ausgabe der Alten Firmware:CodeEvent: time 1767820947.773513, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700ff Event: time 1767820947.773513, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1 Event: time 1767820947.773513, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001e Event: time 1767820947.773513, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1767820947.773513, -------------- SYN_REPORT ------------ Event: time 1767820947.777292, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700ff Event: time 1767820947.777292, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0 Event: time 1767820947.777292, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7001e Event: time 1767820947.777292, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1767820947.777292, -------------- SYN_REPORT ------------Dabei ist es unerheblich ob ich die alte gespeicherte Konfiguration beibehalte, oder die Taste "1" neu anlerne. Ich verwende die selbe Software zum Anlernen wie bei der alten Firmware, als die Software, die ich für das MLD Setup erstellt habe.
Magst Du noch mal schauen, ob Du das Problem beheben kannst?
Claus
-
Danke für den Fehlerbericht.
Durch die Umstellung auf tinyusb's Descriptor gehen die Modifier nicht mehr, war mir noch gar nicht aufgefallen.
Wird bald behoben. -
Damit das github Repo nicht unnötig groß wird, gibt es die Firmware jetzt als Release: https://github.com/j1rie/IRMP_PIC…026-01-09_21-26
-
Enthält das bereits einen Fix für die Modifier Tastencodes?
-
-
Ich hab's getestet. Funktioniert jetzt.

Ob sich Tasten mit Modifier anlernen lassen, habe ich aber noch nicht getestet, da wir bei der MLD sowas nicht verwenden
-
Beim Anlernen hat sich nichts verändert.
Theoretisch könnte ich jetzt statt 1 Modifier gleich 8 Modifier anlernen und auf einmal senden, eben wie bei einer echten Tastatur (und wie fälschlich in #53).
Aber da das wohl niemand braucht, lasse ich es so wie es ist. -
Post by vdr_rossi (
January 10, 2026 at 6:53 PM ).This post was deleted by the author themselves: Gefunden (January 10, 2026 at 6:56 PM ). -
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!