Die gibt's doch jetzt hier: https://github.com/j1rie/IRMP_PIC…026-01-09_21-26
Zwar nicht im git Repository, aber zumindest auf github als Teil des Projektes.
IRMP auf Pico - ein USB-HID-Keyboard IR-Empfänger/Sender/Einschalter mit Wake-up Timer
-
-
Gibt's eigentlich einen besonderen Grund, warum nicht alle Tastencodes (oder sogar beliebige) erlaubt sind? Lirc z.B. erlaubt viel mehr Tastencodes (und auch lirc2uinput), auch wenn man nur die offiziell unterstützten betrachtet.
-
Es gibt die HID Usage Tables vom USB Implementers’ Forum, https://usb.org/document-library/hid-usage-tables-16.
An die muss man sich halten (Kapitel 10, Keyboard/Keypad Page (0x07)). -
Bei Tastaturen mit vielen Multimediatasten und Fernbedienungen gibt es dann oft ein zweites Gerät mit Tasten aus der Consumer Page (0x0C) - eventuell ließe sich das so umsetzen.
-
Quote
All controls on the Consumer page are application-specific. That is, they affect a specific device, not the system as a
whole.Ich weiß nicht, wofür das gut wäre. Was soll damit gesteuert werden?
Für VDR gibt es das vdr-plugin-irmp und für Kodi die HID-Tastatur.
150 Keyboard Tasten mal 8 Modifier sind 1200 Kombinationen, das sollte doch reichen.
Was wäre der Sinn von anderen Codes?
Was könnte man damit machen, was man jetzt nicht kann?
Übersehe ich was? -
Außerdem kann man über eventlircd per evmap die USB HID Keyboard Keys in eine größere Menge von Keys übersetzen, wenn man das braucht.
yaVDR macht das so (#73). -
Ich hätte da noch eine Bitte zu den verwendeten Tags: Datumscodes sind für Debian Pakete als erster Bestandteil ziemlich doof (und den Zeitpunkt des letzten Commit kann man sich aus dem Git holen), weil die nicht als gültige Versionsnummer gesehen werden: https://github.com/j1rie/IRMP_PICO/tags - wäre da eventuell sowas wie Semantic Versioning möglich?
-
Würde statt 2026-01-09_21-26 denn 6.1.9-1 was taugen?
Ist zwar gemogelt, aber ich möchte mir nicht den Kopf über korrekte Versionsnummern zerbrechen müssen.Alternativ könnte ich auch mit 1.0.0 anfangen und wie beim Kilometerzähler hochzählen.
Ich glaube Klaus macht das so beim VDR.Oder 3.0.0, weil das dritte solche Projekt.
Was wäre am sinnvollsten?
-
Ich halte 3.0.0 am Sinnvollsten, bzw. 3.0.4, weil's das vierte Release dieses Projekts ist. Und immer wenn's neue Features gibt und nicht nur Fixes, kann dann die zweite Stelle der Versionsnummer hochgezählt werden.
-
Danke für die Hilfestellung.
Dann werde ich das so machen.3.0.4, weil's das vierte Release dieses Projekts ist.
Wie hast du das gezählt?
-
Ich hatte die Versionen gezählt, die Du veröffentlicht hast. Ob das bisher wirklich vier waren oder mehr, weiß ich nicht genau. Hab nur grob geschätzt. Du könntest aber auch einfach lediglich die Releases zählen, dann wäre es die 3.0.1

-
OK. Dann zähle ich die 2026-01-09_21-26 als 3.0.1.
-
Wenn Vdr mit detachted Ausgabeplugin startet und press any key to attache kommt, wie ließe sich attache in Verbindung mit dem pico lösen?
In der remote.conf habe ich erst die XKeySym.* Einträge drin gelassen, dann kommen Tasten aber doppelt bei mir. Damit würde attachen gehen.
Dann habe ich XKeySym.* Einträge auf n #Kommentar gesetzt, so kommen Tastendrücke ja über eventlirc nicht -> attachen über FB geht nicht mehr. -
Was ist Dein Ziel beim Start im detached Mode? Das Verhindern von Eingaben per Tastatur, da Du lirc verwenden möchtest?
-
-
Was ist Dein Ziel beim Start im detached Mode?
Ziel ist stromsparen bei Aufnahme.
Ist bei yavdr so, wenn pc per Timer aufgewacht und Aufnahme gemacht wird. Wenn ich als Benutzer dann den TV einschalte, sehe ich ein Bild mit sinngemäßer Meldung: press any key... to attache.
Rest schaue ich mir heute Abend an.
-
Ist bei yavdr so, wenn pc per Timer aufgewacht und Aufnahme gemacht wird.
Das ist ja auch sehr sinnvoll so.
-
OK. Dann zähle ich die 2026-01-09_21-26 als 3.0.1.
Bitte dann bei den Tags ein kleines "v" davor setzen - ich weiß nicht konkret warum, aber es ist allgemein üblich. Ich erinnere mich schemenhaft daß rein numerische Tags beim git tag Kommando komisch sein können.
Du kannst natürlich, wenn Du keine echten "Release" machen willst (und dann z.B. für ältere Release dann noch Bugfixes pflegen) auch ein datumsorientiertes Schema verwenden, aber es muß halt vernünftig formatiert sein.Beispiel: anstelle "2026-01-09_21-26" dann "v20260109" oder "v26.1.9" so wie hier
Dann sind natürlich nicht mehrere Release pro Tag möglich.....
-
Dann sind natürlich nicht mehrere Release pro Tag möglich
Mit v26.1.91 schon

Noch eine Frage:
Ich will ja auch die Windows und Linux Binaries releasen. Bis jetzt war ja nur die Firmware drin.
Vor allem die Windows Binaries ändern sich aber selten und sind groß.
Soll ich dann jedes Mal die unveränderten Windows Binaries mit in den Release rein tun, oder wie löse ich das? -
Soll ich dann jedes Mal die unveränderten Windows Binaries mit in den Release rein tun, oder wie löse ich das?Jein.
Wenn Du es so richtig richtig machen willst, dann sollte ja irgendwie die Versionsnummer in die Source hineinkommen und dann im Binary angezeigt werden - z.B. beim Aufruf von sowas wie irmpconfig -V - dann gibts natürlich bei jedem release frisch compilierte binaries. Vielleicht im aktuellen Entwicklungsstadium nicht wirklich wichtig.....
Aber solange das nicht implementiert ist, dann einfach immer wieder die unveränderten binaries releasen.
Am Ende des Tages kann man dann die Workflows von Github nutzen - für alles - test, build, release.... aber da bin ich auch noch nicht fit....
-
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!