vdr-plugin-statusleds 0.4

Könntest du die Version bitte noch taggen?

Quote from seahawk1986

Könntest du die Version bitte noch taggen?

?? es gab doch noch nie ein Tag

Könnte man auch LEDs über gpio des Odroid N2+ ansteuern?

Bei mir sind alle USB Ports belegt, d.h. einfache Tastatur oder RP2040 ist raus.

Im Wiki steht -> https://wiki.odroid.com/odroid…ent_40pins#tab__odroid-n2

Danke vorab

Wenn ich das im Code richtig sehe, kann man dem Plugin das Programm, das das Umschalten übernimmt als Argument mitgeben:

-i stm32IRstatusled_path - das Programm bekommt dann ein Argument -s 1 bzw. -s 0 mitgegeben, um die LED an- bzw. auszuschalten: https://github.com/j1rie/vdr-p…ob/main/statusleds.c#L306 f.

Also bräuchtest du nur ein Skript oder Programm angeben, das diese Argumente akzeptiert und kannst dann beliebige Aktionen damit umsetzen.

Quote from vdr_rossi

Bei mir sind alle USB Ports belegt, d.h. einfache Tastatur oder RP2040 ist raus.

Ein USB hub wäre ein weiterer Weg.

Danke für Hinweise und Ideen.

D.h. für mein Odroid N2 gpio Ansteuervorhaben, müsste eine "Brücke" nach dem Muster stm32IRstatusled gebaut werden.

Ok, Verständnisfrage:

Könnte man die IRMP auf STM32 USB-HID Keyboard Variante nicht so ändern, dass auch Tastatur LEDs (Num Lock, Caps Lock, Scroll Lock) über Pins ansteuerbar sind? In der Firmware direkt.

Das am Ende ein LED Verhalten so wie bei einer echten Tastatur herauskommt . Konfigurierbar mit LED a verwendet gpio x und y

Wenn Grundfunktion mit den drei LEDs reichen, müsste das statusleds Plugin gar nicht angefasst werden.

Dann bräuchte man die "Brücke" stm32IRstatusled nur für Größeres.

Das Plugin versucht auch die Tastatur-LEDs anzusteuern, aber der VDR muss dazu Zugriff auf eine aktive Konsole haben - wenn das nicht klappt, kann man das im Log sehen: https://github.com/j1rie/vdr-p…ob/main/statusleds.c#L312

Quote from vdr_rossi

Könnte man die IRMP auf STM32 USB-HID Keyboard Variante nicht so ändern, dass auch Tastatur LEDs (Num Lock, Caps Lock, Scroll Lock) über Pins ansteuerbar sind? In der Firmware direkt.

Mir ist da nicht ganz klar, wie du dir das vorstellst - man muss ja zwangsweise über einen USB-Endpunkt gehen, um Informationen an den Empfänger zu schicken und der selber hat keine Kontrolle über andere Tastaturen - da der Empfänger an vielen Systemen genutzt wird, bei denen der VDR keinen Zugriff auf eine aktive Konsole hat (z.B. weil ein X-Server auf der aktiven Konsole läuft), bietet der Weg über ein dediziertes Programm die Möglichkeit sich nicht von Terminal-Kontrollsequenzen abhängig zu machen.

So ein Wrapper-Skript ist kein großer Aufwand:

#!/usr/bin/env python3
import argparse
import sys
from pathlib import Path

LED_PATH = Path('/sys/class/gpio/gpio477/')

parser = argparse.ArgumentParser(description="GPIO Wrapper to toggle an LED")
parser.add_argument('-s', type=int, choices=[0,1], help="pass 1 for 'on' or 0 for 'off'")
args = parser.parse_args()

try:
    with open(LED_PATH / 'direction', 'w') as f:
        print('out', file=f)
    with open(LED_PATH / 'value', 'w') as s:
        print(f"{args.s}", file=s)
except Exception as e:
    print(f"could not access {LED_PATH}:", e, file=sys.stderr)

Einfach/anders ausgedrückt:

Die IRMP auf STM32 USB-HID Keyboard Variante verhält sich ja dem System gegenüber wie eine normale Tastatur.

In meiner Denke könnte diese "Tastatur" im Vergleich, auch eine normale USB Tastatur, mit eben 3 LEDs sein.

Stelle mir also vor dass in der Firmware genau diese LED Funktion mit abgebildet wird. Nur das die passenden LEDs (Num Lock, Caps Lock, Scroll Lock) konfigurierbar an gpio x und y hängen.

Und dann genau wie Num Lock, Caps Lock u. Scroll Lock einer normalen Tastatur funktionieren.

Aber selbst wenn sich das so verhält, bleibt das Problem mit aktiver VDR Konsole. Darum das Programm stm32IRstatusled als Brücke.

Eine echte Tastatur lässt sich auch nur an aktiver Konsole verwenden - verstehe.

Zurück zu meinem 1. Ansatz.

Danke für das Script - schaue ich mir heute Abend nochmal konkreter an.

Klemme dann eine LED an gpio Pins und versuche...

Bitte.

Verstehe aktive Konsole in diesem Zusammenhang so: Tastatur bzw. LED funktioniert nur, wenn vdr in dieser aktiven Konsole läuft.

Kann nicht beurteilen in welchen Fällen (Hardware/Ausgabeplugin) das gegeben ist.

Z.B. bei vdr-plugin-softhdodroid ist ja kein X Server im Spiel, da läuft Tastatur direkt in der vdr Konsole - d.h. da funktioniert es gleich so.

Werde es mit vorhandener Hardware und Ausgabeplugins einfach mal ausprobieren.

Plan B wäre dann immer noch gpio mit dem vorgeschlagenen Skript.

Ich brauche Bastelzeit...

Hallo zusammen,

habe heute von kUbuntu 24.04 auf 24.10 aktualisiert, den VDR (2.7.3) und Plugins neu kompiliert und nun logged das statusleds-plugin:

2024-11-14T17:19:33.008777+01:00 HTPC vdr[92982]: vdr: cap_from_text failed: Invalid argument

2024-11-14T17:19:33.009450+01:00 HTPC systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

2024-11-14T17:19:33.009506+01:00 HTPC systemd[1]: vdr.service: Failed with result 'exit-code'.

wenn der VDR mit dem folgenden Patch versehen wurde (aus "patch_for_vdr.diff" aus dem neuen Plugin Sourcecode:

cap_sys_tty_config=ep

Wenn ich dies entferne, startet der VDR normal, aber kann "natürlich" die Keyboard LED bei einer Aufnahme nicht blinken lassen.
VDR logged dann beim Start:

2024-11-14T18:20:47.695110+01:00 HTPC vdr: [103227] Status LED's: Thread started (pid=103204)

2024-11-14T18:20:47.695143+01:00 HTPC vdr: [103227] ERROR: Status LED's: Can't open console /dev/tty

2024-11-14T18:20:47.695165+01:00 HTPC vdr: [103227] Status LED's: Thread ended (pid=103204)

Habe ich auch hier gemeldet, vielleicht kennt jemand ja eine Lösung oder hat eine Idee dazu ...

Viele Grüße,

Chriss

Danke jrie!

Interessant wird's leider nun umso mehr. In Ubuntu ist die v2.66 von libcap schon seit 23.10 enthalten (wenn die Infos von cap_from_text stimmen), davor war's 2.44. Bin auch die Änderungen zwischen 2.63 und 2.66 einzeln durchgegangen und habe dabei für meine Augen nichts auch nur annähernd Verdächtiges gefunden.

Musste mein System auf kUbuntu 24.04 zurückrollen (Backup der Platte von vorher eingespielt), weil Ubuntu in 24.10 Wayland als default eingestellt hat.

Da softhddevice kein Fenster mit Wayland geöffnet bekommt ... und ich es ums Verrecken nicht hinbekommen habe, X11 wieder zu reaktivieren, ohne mich dazu jedes Mal manuell anmelden und dabei X11 auswählen zu müssen, habe ich die Rolle rückwärts gemacht.

Trotzdem habe ich dann von vdr-2.6.6 auf vdr-2.7.3 aktualisiert (ich compiliere immer alles rund um den VDR selber) und da ist das Verhalten haargenau gleich.

Mit Patch kommt: cap_from_text failed: Invalid argument, ohne Patch: natürlich kein blinkendes LED; weshalb ich momentan noch "meine" Version von statusleds weiterbenutze, die den blinkd nutzt.

Bin also erst einmal noch ratloser als vorher, aber ggf. hilft dies dem einen oder anderen Mitleser, sich ein Update auf (k)Ubuntu in ähnlichem Szenario wie meinem, reiflich zu überlegen oder für sich schneller Ursachen eingrenzen zu können.

Viele Grüße,

Chriss

Sorry, hatte das vergessen zu schreiben ...

Quote from jrie

Ging es denn mit vdr-2.6.6?

Jupp, daher bin ich ja so überrascht.

Wenn dies andere mit einem aktuellen und gepatchten VDR nicht haben, verbuche ich es einfach als eine Merkwürdigkeit meines Systems - und behalte es im Auge bei künftigen Versionen.