vdr-plugin-statusleds

Quote from jrie

Was hast du denn noch an Plugins bzw. an Patchen?

Bewusst nur den einen Patch - bei 2.6.6 muss ich genauer hinschauen.

Bei VDR-2.7.3 definitiv nur den für libcap fürs statusleds-plugin, hatte die VDR-Version direkt via git ausgecheckt und den Patch angewendet.

Habe es als Anlass genommen, meine Signatur auf Stand zu bringen ...

Plugins: epg2vdr, lcdproc, markad, skindesigner, softhddevice, statusleds, streamdev-server, svdrpservice, vnsiserver

Quote from jrie

Ab welcher vdr Version passiert das bei dir (bisect zwischen 2.6.6 und 2.7.3 = 3 Tests)?

Sehr gute Idee, bin dran, wird aber etwas dauern.

Ich antworte mir endlich selber ...
"Damals" muss ich mir entweder etwas falsch gemerkt oder missinterpretiert haben:
Ein konkreter Test des Ganzen mit VDR 2.6.6, um bei dem anzufangen, bei dem es klappen sollte, zeigt nun dasselbe Fehlverhalten

In dem Zuge habe ich dann auch VDR 2.7.4 versucht, ebenfalls kein Erfolg. Und jetzt verlässt mich erst einmal wieder die Lust, dem nachzugehen, weil es mit "meinem" statusleds per blinkd ja funktioniert.

Viele Grüße,
Chriss

Quote from jrie

Genauer gesagt ist cap_from_text in capability.h definiert und das kommt mit libcap-devel.
Hast du libcap-devel drin?

Ja, wenn du mit "Hast du libcap-devel drin?" meinst, ob ich es installiert habe. Bei meinem KUbuntu 24.04 ist es in als Version "1:2.66-5ubuntu2.2" installiert.
In /usr/include/sys/capability.h steht in Zeile 189:

/* libcap/cap_text.c */
extern cap_t   cap_from_text(const char *);

Viele Grüße,
Chriss

Ich antworte mal hier, da es thematisch besser passt, denke ich.

Da die Fähigkeiten von xset sind eher begrenzt sind. - Schon wenn man eine andere als die aktuelle Konsole umschalten will, muss man frickeln.
Die Geschichte mit /dev/console nie wirklich praktisch war und sich dazu, beim genaueren hinsehen, als eher übler Hack entpuppt hat, hatte ich mich gefragt, ob man die Tastatur-LEDs nicht irgendwie besser ansteuern kann.
Dabei bin ich dann auf diese API gestoßen, die mir vorher noch unbekannt war. Die scheint jetzt der Standard dafür und gut unterstützt zu sein.

Die API scheint mir auch genau das zu sein, was man hier braucht.
Man kann damit eine bestimmte LED zB. einer bestimmten (Hardware) Tastatur schalten. Ganz ohne irgendwelche Klimmzüge.

Bei einem meiner Computer und einem Laptop kann ich damit alle Gehäuse-LEDs nach belieben schalten.
Out of the Box, ich habe nichts eingestellt oder installiert, ein echo 1 | sudo tee /sys/class/leds/mainboard::LED_name/brightness reicht. Das ist schon irgendwie cool, finde ich .

Bei allen anderen Computern bekomme ich nur die 3 Keyboard-LEDs gezeigt.
Mit Ausnahme vom VDR, der hat leider gar keine kontrollierbare LED. Das simmt aber auch, da das Keyboard da keine LEDs hat. (Ist bei einem Funk-Keyboard vielleicht auch besser wegen der Batterielebensdauer. ) Von daher ist die API dort auch korrekt.

Des weiteren könnte man diese Schnittstelle in eigenen UC-Projekten auch dazu missbrauchen beliebige Ausgänge zu schalten und das mit den Standard HID-Treibern.

Du siehst, ich bin ziemlich begeistert vom meiner Entdeckung und denke, es könnte sich lohnen drauf zu setzen.

Quote from jrie

Der KBD-Empfänger taucht als Tastatur tatsächlich unter sys/class/leds auf.

Sehr schön, darauf hatte ich gehofft.
Da bestehen also Hoffnungen, dass ich es mit meinen AVR auch hin bekomme.

Quote from jrie

Da das aber wegen statusleds2irmphidkbd nicht mehr gebraucht wird, plane ich das wieder auszubauen.
Denn wenn im BIOS Numlock an ist, stört das.

Das wäre schade, besonders für User abseits des VDR.

Meine eine Maus hat diese LED (leider funktionslos):
/sys/class/leds/input3::misc/brightness
evtl. ist das auch hier möglich?

Oder man nimmt einfach ScrollLock, das nutzt eh niemand.

Quote

Der irmplirc-Empfänger wird mangels Treiber nicht in sys/class/leds gelistet.

Schade, das war aber auch irgendwie abzusehen.
Kann der UC evtl. ein zweites, logisches HID-USB-Device erstellen, nur für die LEDs?

Ich hatte bezüglich des vdr-plugin-statusleds spontan nämlich eher andersherum gedacht:
Umstellen auf die Standard-Schnittstelle, dann braucht man nur noch ein Plugin zu pflegen.

Quote

Manche nutzen den Empfänger auch nur um eine LED ansteuern zu können. So viel Gebastel ist das nun auch wieder nicht

Wenn man denn unbedingt so eine LED haben will, kann man das machen. Mir wäre das dafür aber doch zu viel Aufwand.
Wenn ich aber nur das Plugin installieren müsste und dann eine eh schon vorhandene, aktuell ungenutzte, Gehäuse-LED entsprechend verwenden könnte, würde ich das sofort tun.

Quote from jrie

Das müsste man in den USB HID Specs nachschlagen.

Ich hatte mal ein Keyboard mit Touchpad, das hat sich als zwei USB-Devices gemeldet. Das hat mich auch auf die Idee gebracht.
(Mit den zwei USB-Devices bin ich auch sicher, da das Touchpad damals nicht richtig funktioniert hat.)

Wie das Intern gelöst hatten kann ich aber nicht sagen. Im dümmsten Fall waren wirklich zwei ICs plus ein USB-HUB verbaut.

Mein aktuelles Keyboard vom VDR hat auch ein Touchpad (aber keine LEDs), das scheint ein USB-Device zu sein:

ID 046d:c52b Logitech, Inc. Unifying Receiver 
Device Descriptor: 
 bLength                18 
 bDescriptorType         1 
 bcdUSB               2.00 
 bDeviceClass            0 (Defined at Interface level) 
 bDeviceSubClass         0  
 bDeviceProtocol         0  
 bMaxPacketSize0         8 
 idVendor           0x046d Logitech, Inc. 
 idProduct          0xc52b Unifying Receiver 
 [...]
   Interface Descriptor: 
     bLength                 9 
     bDescriptorType         4 
     bInterfaceNumber        0 
     bAlternateSetting       0 
     bNumEndpoints           1 
     bInterfaceClass         3 Human Interface Device 
     bInterfaceSubClass      1 Boot Interface Subclass 
     bInterfaceProtocol      1 Keyboard 
     iInterface              0  
[...]
   Interface Descriptor: 
     bLength                 9 
     bDescriptorType         4 
     bInterfaceNumber        1 
     bAlternateSetting       0 
     bNumEndpoints           1 
     bInterfaceClass         3 Human Interface Device 
     bInterfaceSubClass      1 Boot Interface Subclass 
     bInterfaceProtocol      2 Mouse 
     iInterface              0

Das bDeviceClass 0 (Defined at Interface level) ist auffällig.
Wobei ich nicht sicher bin, ob da der Logitech-Treiber auch was zu sagen hat.

Dann habe ich noch so einen PS/2-Keyboard+Maus-auf-USB Adapter hier rum fliegen gehabt:

ID 13ba:0017 PCPlay PS/2 Keyboard+Mouse Adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x13ba PCPlay
  idProduct          0x0017 PS/2 Keyboard+Mouse Adapter
  bcdDevice            0.01
  iManufacturer           0 
  iProduct                1 Generic USB K/B
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x003b
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0 
[...]
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0    

Auch hier ist wieder bDeviceClass 0.
Das und zwei Interfaces, das scheint wohl der Trick zu sein.

Der Adapter liefert übrigens lustige LEDs, ganz ohne dass was dran angeschlossen ist:

/sys/class/leds/input2::compose
/sys/class/leds/input2::numlock
/sys/class/leds/input2::capslock
/sys/class/leds/input2::kana
/sys/class/leds/input2::scrolllock

Das Schalten 3 üblichen LEDs am angeschlossenen PS/2-Keyboard geht aber auch einwandfrei.

Wenn Du welche der Ausgaben komplett haben möchtest, sag Bescheid. Ich wollte das hier nur nicht ganz zumüllen.

Udev funktioniert grundsätzlich auch auf /sys/.
Ich hatte da einige Beispiele für /sys/class/leds gefunden.

Testweise habe ich mal dieses Beispiel etwas abgewandelt und ausprobiert:

SUBSYSTEM=="leds", ACTION=="add", RUN+="/bin/chgrp -R users /sys%p", RUN+="/bin/chmod -R g=u /sys%p"
SUBSYSTEM=="leds", ACTION=="change", ENV{TRIGGER}!="none", RUN+="/bin/chgrp -R users /sys%p", RUN+="/bin/chmod -R g=u /sys%p"

Es scheint zu funktionieren, jetzt kann ich auch als user meine LEDs mit echo 1 > /sys/class/leds/input0\:\:scrolllock/brightness schalten.
Ob die Berechtigungen wirklich sinnvoll gesetzt sind, kann ich momentan aber nicht beurteilen.

udevadm info -a -p /sys/class/leds/inputx... liefert bei mir unter parent device auch mit
ATTRS{id/product} und ATTRS{id/vendor} (bzw. weiter "unten" ATTRS{idProduct} ATTRS{idVendor}) die USB-IDs. Eine udev-Regel sollte also möglich sein.

Mein erster Versuch wäre mal so: (bislang ungetestet)
SUBSYSTEM=="leds", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", ACTION=="add", MODE="0660", RUN+="/usr/bin/ln -s /sys/$devpath/brightness /dev/irmp_LED"
Evtl. sind damit sogar die beiden oberen Regeln unnötig.
Wenn das so nicht geht, muss ich die Tage mal schauen, wie ich das nachstellen kann.

Alternativ könnte man natürlich auch den User die LED im Menü auswählen lassen.
/sys/class/leds/device:colour:LED_name/brightness ist eine steuerbare LED, das sollte sich recht einfach parsen lassen.
Das blöde ist nur, dass sich die devices ändern können. Da müsste man sich was überlegen.
Unter /sys/class/leds/device:colour:LED_name/device/id/ findet man aber zumindest die USB-IDs, evtl. kann man damit was machen.

Einige Funktionen wie SYMLINK+, GROUP und MODE scheinen auf /sys/ wirklich nicht zu funktionieren.
Ob das einen relevanten Unterschied macht, konnte ich bislang aber nicht rausfinden.
Zumindest scheint sich die Fragestellung auch schon ausserhalb der üblichen Dokumentation zu befinden.
Andererseits bezieht udev seine Informationen über die Devices anscheinend immer aus /sys/, wenn das stimmt, was ich gelesen habe.

Die 5 oben erwähnten LED-Namen stammen übrigens angeblich aus der HID_Spezikation.
Kana ist wohl eine Eigenheit japanischer Tastaturen, die LED sollte im Rest der Welt also unbenutzt sein.