lircrc-Plugin binär inkompatibel

Zitat von seahawk1986

Das wieder die Geschichte mit der Reihenfolge im Makefile:

Ah, der allseits beliebte gold linker schlägt wieder zu. Das Plugin ist dann wohl schon länger kaputt.

Gerald

Zitat von gda

Das Plugin ist dann wohl schon länger kaputt.

Sieht so aus: http://www.easy-vdr.de/forum/i…12822.msg107466#msg107466

MPW: Die Pakete mit dem Patch sollten verfügbar sein (wenn die grünen Zahnräder durch Häkchen ersetzt wurden): https://launchpad.net/~yavdr/+archive/testing-vdr/+packages?field.name_filter=lircrc&field.status_filter=published&field.series_filter=

Zitat von gda

Das Plugin ist dann wohl schon länger kaputt.

Sicher, nur hat es tatsächlich niemand benötigt, getestet, bemerkt ..., bis gestern ...

Ich weiß immer noch nicht ob es da Vorteile gegenüber einer gut konfigurierten irexec/irxevent Umsetzung gibt, letztere hängt immerhin nicht davon ab ob der VDR läuft ...

Regards
fnu

Zitat von fnu

Ich weiß immer noch nicht ob es da Vorteile gegenüber einer gut konfigurierten irexec/irxevent Umsetzung gibt, letztere hängt immerhin nicht davon ab ob der VDR läuft ...

Im Gegensatz zu vielen hier, bin ich ja schon immer der Meinung, dass eine externe Lösung einem Plugin immer vorzuziehen ist. Dadurch wird der VDR stabiler und die Lösung ist generell flexibler. Mit der Meinung bin ich aber generell nicht alleine, auch Linus Torvalds versucht alles was geht aus dem Kernel in den Userspace zu verlagern. Siehe das Laden von Kernel-Modulen, wird mit Hilfe von Modprobe und Udev im Userspace erledigt.

Gerald

Zitat von MPW

Bleibt noch die Frage, wie man es eigentlich benutzt...im Wiki steht dazu nicht wirklich was.

Ich würde mal mit der README und der lircrc.demo bzw. dem vdr-remote-conf-to-lircrc Skript im Quellpaket anfangen.

Zitat von fnu

Ich weiß immer noch nicht ob es da Vorteile gegenüber einer gut konfigurierten irexec/irxevent Umsetzung gibt, letztere hängt immerhin nicht davon ab ob der VDR läuft ...

Gerade dies sehe ich als Vorteil gegenüber allen anderen Lösungen...
Anders als die VDR interne Integration belegt dieses Plugin nicht den Socket und lässt auch andere Programme connecten und lirc verwenden. (z.B XBMC)
Auch das Mapping auf die Tasten sehe ich als Nachteil.
Mit dieser Lösung bleiben alle Tasten der Tastatur frei und können für den Browser oder andere Sachen verwendet werden ohne das der VDR bedient/umgeschaltet wird.
Einfach die Ausgabe des VDRs verkleinern, Browser starten und tippen.

Zusätzlich Delay, Repeat und Macros die nur für den VDR gelten.

Lirc läuft sowieso unabhängig. Ob VDR gestartet ist oder nicht spielt keine Rolle den es belegt nicht das Socket und das Plugin ist nur für VDR zuständig.

Das Plugin wird meiner Meinung nach unterschätzt.

Gruß

Hmm, also ich habe da kein Problem, VDR hört auf den Socket parallel zu inputlirc/EventLirc und irexec … und das ganze unabhängig ob der VDR läuft oder nicht …

Regards
fnu

Zitat von MPW

(umleiten auf /dev/null)

Das macht man heutzutage nicht mehr (du benutzt vdr 2.0.6, richtig?), hast du da nicht zufällig Fehlermeldungen im vdr-log?
Wenn der vdr kein Lirc benutzen soll, dann gibt man den Parameter "--lirc" einfach gar nicht an.
Ansonsten wird er ständig versuchen, sich zu /dev/null zu verbinden, was natürlich nicht geht...

Lars.

So, wie ich den Code verstehe, solltest du auf jeden Fall den vdr ohne "--lirc" starten, denn lircrc löscht das dazugehörige cRemote-Objekt sowieso wieder. Und um das zu unterbinden (unnötiges Ausführen von überflüssigem Code sollte man verhindern, dann kann auch nichts kaputt gehen), wie gesagt, den vdr ohne "--lirc" starten und das Plugin mit "-k", damit es nicht versucht, das vdr-Objekt zu löschen (was auch immer das für Folgen haben kann). Das "delete this" macht mir da auch etwas Sorgen...

Ob noch LIRC-Einträge in der remote.conf sind oder nicht, spielt keine Rolle, da es kein cRemote-Objekt gibt, dass diese auswertet.

Was in "config" steht wird dann von cKey::FromString in ein tKey umgewandelt und per cRemote::Put an den vdr verfüttert.

Sonst musst du mal ein paar Debug-Ausgaben einbauen, um zu sehen, ob die Eingaben im Plugin ankommen und was es daraus macht.

Lars.

Deine config liegt unter /var/lib/vdr/.lircrc?
Steht denn irgendwas im syslog?

Lars.

Da sind so einige Stellen im Code, über die ich etwas stolpere.

Beispiel:

if (!m_pszLircrcFileArg)
  {
    char* pszLircrcFile = NULL;
    char* pszHome = getenv("HOME");
    if (!pszHome) pszHome=const_cast<char*>("/");
    pszLircrcFile = (char*)malloc(strlen(pszHome)+1+strlen(LIRCRC_USER_FILE)+1);
    if (!pszLircrcFile){
      esyslog("%s: fatal error - out of memory", Name());
    } else {
      strcpy(pszLircrcFile, pszHome);
      if ((strlen(pszHome) > 0) && (pszLircrcFile[strlen(pszLircrcFile)-1] != '/'))
        strcat(pszLircrcFile,"/");
      strcat(pszLircrcFile, LIRCRC_USER_FILE);
      m_pszLircrcFileArg = pszLircrcFile;
    }
    if (pszLircrcFile)
      free(pszLircrcFile);
  }

Falls du den Pfad zur .lircrc nicht dem Plugin per Kommandozeile mitgibst, will er sie aus $HOME/.lircrc lesen und baut deshalb den String in "pszLircrcFile" zusammen, um sich den Pointer dann in "m_pszLircrcFileArg" zu merken. Und danach wird "pszLircrcFile" freigegeben. Das ist nicht gut. Oder übersehe ich da was?

Außerdem gibt es im Thread keine vernünftige Ausstiegsbedingung. Der Thread muss gekillt werden, anstatt dass er sich (z.B. bei vdr-Ende) sorgfältig beendet.
Und die meisten Info-Meldungen werden als Fehler ins syslog geschrieben, schön ist das nicht.

Das Plugin scheint mit der heißen Nadel gestrickt worden zu sein. Die Idee dahinter ist zwar nett, aber für meinen Geschmack leider nicht gut umgesetzt.

Aber ich brauche kein lirc, deshalb ist es für mich nicht weiter interessant...

Lars.

Um --lirc zu deaktivieren, genügt es LIRC="" in der /etc/default/vdr zu setzen.

Ich benutz(t)e plugin-loader2 und den Upstart-Job, vom Init-Script weiß ich nichts. Kann sein, dass LIRC_DEV (o.ä.) leer sein muss, keine Ahnung.
Oder einfach mal mit den neuen conf.d-Möglichkeiten spielen und alle Parameter unter /etc/vdr/conf.d ablegen (bzw. in /etc/vdr/conf.local.d und dann nach conf.d verlinken). Dadurch bekommst du viel leichter eine Kontrolle über die Konfiguration deines vdr.

Musst halt irgendwie in deinem Startmechanismus dafür sorgen, dass "--lirc" nicht an den vdr übergeben wird.
Und du solltest überlegen, zum Upstart-Job überzugehen. Dann wird der Übergang zu systemd in zwei Jahren leichter.

Lars.

Zitat von fnu

Hmm, also ich habe da kein Problem, VDR hört auf den Socket parallel zu inputlirc/EventLirc und irexec … und das ganze unabhängig ob der VDR läuft oder nicht …

Zitat von MPW

Das stimmt so nicht, das läuft auch sonst parallel.

Zitat von MPW

Das geht auch mit irxevent oder dem klassischen Lirc+VDR.

Ok, hatte ich anders in Erinnerung, sorry...

Ich habe das Plugin seit Veröffentlichung in Betrieb.

Grundvoraussetzung:
Zunächst muß lirc vollkommen unabhängig vom VDR oder dem Plugin laufen.

lircrc Config vom Plugin

# VDR Key - Up
begin
  prog   = VDR
  remote = *
  button = KEY_UP
  delay  = 4
  repeat = 1
  config = Up
end


# VDR Key - Down
begin
  prog   = VDR
  remote = *
  button = KEY_DOWN
  delay  = 4
  repeat = 1
  config = Down
end


# VDR Key - Menu
begin
  prog   = VDR
  remote = *
  button = KEY_MENU
  delay  = 0
  repeat = 0
  config = Menu
end

VDR Startup:

-P lircrc --prog=VDR --kill /pfad/zu/lircrc

Ob VDR mit --lirc startet oder nicht ist egal, da wie erwähnt der betreffende Teil deaktiviert wird.
Schöner ist natürlich wenn er erst gar nicht gestartet wird.

Das Plugin funktioniert bei mir einwandfrei.

Gruß

ps.: Mein lirc Socket erstelle ich unter "/var/run/lirc/lircd"