So langsam hab sehe ich Lichter im Tunnel...
Ich verwende als Ausgabemethode vdr-sxfe@vdr-plugin-xineliboutput.
Durch das x im Namen glaub ich jetzt mal einfach das da ein X-Server mitläuft.
Wenn das soweit richtig ist, dann müsste ich in DIESEM Fall (bei xine@vdr-plugin-xine auf gar keinen Fall) X keycodes nehmen können.
Also Keyboard auf einer andere Linuxkiste hängen (oder VDR mit einer Livecd starten) und mittels xev die Codes auswerten (Quelle: https://wiki.kubuntu.org/LaptopTesting/Keycodes)
Das lasse ich mal bleiben bis ich verstanden hab wie ich dann definieren müsste...
Die These überprüfen kann ich über den Mechanismus:
Nach http://www.vdr-wiki.de/wiki/in…#Templating.2FCustomizing kann ich dann mir eine Datei schaffen die bestehenden Templates ersetzt:
cp /usr/share/yavdr/templates/var/lib/vdr/remote.conf/* /etc/yavdr/templates_custom/var/lib/vdr/remote.conf/*
edit: Verzeichnisse muss man eben erst erstellen...
Die Dateien in /etc/yavdr/templates_custom/var/lib/vdr/remote.conf/ kann ich dann ja mal gearbeiten wie es mir passt und Komplexität rausnehmen also mal graphtft und imon leeren, ich verwende ja beides nicht.
Ob er die x-codes oder die kbd nimmt, sehe ich wenn ich die jeweilige Datei geleert habe und es trotzdem noch geht...
ad /var oder /etc : Wie es am Anfang genau war weiß ich jetzt auch nimmer, jetzt liegt jedenfalls in /etc keine mehr, und in var liegt eine. Auf meinem SD-VDR siehts genauso aus wie du beschreibst: in etc ist ein symbolic link auf /var
naja. Da werd ich mal weitertüfteln.