Posts by TEN

    Nur eben nicht der Eintrag des Providers, der den richtigen Zeichensatz mitgeben müsste (wenn das nicht Nþrnberg & Wþrzburg an der Wolga sind :]) ?
    Danke nochmal, daß Du es Dir so schnell angesehen hast! Hoffe die Informationen waren so wie benötigt aufbereitet.

    ü ist in den SDTs jeweils als %FC kodiert (ISO-Latin 1/5/9)
    Der Unterschied scheint mir zu sein, daß es bei München (z.B. BetaDigital) aus ISO-8859-9, bei Nürnberg und Würzburg (M-net) aber aus ISO_6937-2 nach UTF-8 konvertiert wird:

    Ist die Frage, ob die SDT fehlerhaft ist und z.B. vom WISI nur durch Annahme von ISO-8859-? "versehentlich" berichtigt wird, oder ob w_scan sie anders parsen sollte.

    Welche Tables vom DVB-C-Provider kommen, müsste ich Dir ja mit dvbstream aus Paket dvb-tools dumpen können:
    Welcher Abruf genau würde benötigt? (Problematisch scheint nur QAM_256 f = 482000 kHz S6900C34 zu sein.)


    LANG=en_US.UTF-8 habe ich schon seit einigen Ubuntu-Versionen, und mich natürlich vergewissert, daß der Fehler trotz ergänztem Parameter in der Ausgabe landet:
    w_scan -fc -c DE -C UTF-8 >channels.UTF-8.conf
    Diese und v.a. auch das Log dazu (um Wiederholungszeilen gekürzt) anbei.


    Ein gültiges ü bekomme ich ja bei zahlreichen Sendern, grundsätzlich scheint also UTF-8 erzeugt zu werden (als %C3%BC, wohingegen %C3%BE kein Umlaut wäre).

    Wegen einer Zugangsumstellung auf M-net musste ich für diverse Geräte im Haus neue Sendersuchläufe durchführen.


    Dabei fallen Einträge wie "Energy Nþrnberg" in channels.w_scan.2016-01-04.conf z.B. wie unten hervorge- und behoben unter Ubuntu 14.04 auf:

    Fürs Wiki habe ich die Liste (auch entsprechend http://www.vdr-portal.de/board…3%A4t-qam-256#post1103530) angepasst.
    Oben zugleich ein aktuelles Beispiel, automagisch DVB-T&C unter einen Hut zu bringen, Kryptoeinträge loszuwerden und die "channel groups" (Rechts/Links-Umschaltung) einfach nutzbar zu machen.


    Beispielsweise ein Standalone-DVB-C-Tuner von Wisi zeigt "Nürnberg" aber richtig an.


    Kommt die falsche Zeichenkodierung vom (informierten) Anbieter oder doch aus einer lokalen Anwendung oder Bibliothek?

    Interessant, das scheint durch die Option für --sysconfdir=/etc/lircd in debian/rules zu passieren. Wenn ich das autoconfigure-Skript richtig interpretiere, sollte das nur auf /etc gesetzt werden (so hat es zumindest Arch Linx gemacht). Warum ircat den Pfad für die Konfigurationsdatei nicht annimmt, ist mir noch nicht klar.

    Vielen Dank nochmal! :]
    BTW Debian jessie mit Kernel 3.18.5 (blockierender mceusb-Treiber http://forum.doozan.com/read.php?2,20609,20753#msg-20753, außerdem nftables noch unfertig) und Arch (ALARM) 3.19 konnte ich auf dieser Hardware gar nicht einsetzen.

    TEN wrote:

    Bug 1: mceusb ist erst mehrere Sekunden nach letztem Empfang (Loslassen der Taste) sendefähig
    Bug 2: lircd-0.9.0-pre1 ist für /usr/bin/ircat und /usr/bin/irexec irgendwo fälschlich festverdrahtet auf /etc/lirc/lirc/lircrc
    Bug 3: Die zugehörige /etc/init.d/lirc hingegen versucht irexec dazu nicht passend fest mit -d /etc/lirc/lircrc so zu starten, daß trotz gemeldetem [ ok ] hinterher auch lircd/irw nicht benutzbar ist.

    Habe den Startprozess weiter auseinandergenommen und Variationen der /etc/init.d/lirc getestet, wobei mir auffiel, daß eine darin manuell eingetragene /usr/bin/irexec -d zwei solche Prozesse in ps aux sichtbar erzeugt.
    Normalerweise fällt das nur nicht auf, weil über start-stop-daemon der zweite nicht mehr gestartet würde.
    Ursache scheint mir zu sein, daß u.g. mit grep -r aufgespürte udev-Regel das Startskript nochmals aufruft:

    Code
    1. /lib/udev/rules.d/85-lirc.rules:ACTION=="add", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc restart udev"
    2. /lib/udev/rules.d/85-lirc.rules:ACTION=="remove", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc stop udev"

    Wie auch für den VDR selbst funktioniert restart auf /etc/init.d nicht immer zuverlässig (v.a. wenn es ausdrücklich udev dazwischenfunken lässt).


    pass 1 / irw bleibt trotz irexec und o.g. Regeln funktionsfähig, wenn man neben dem rmmod aus http://ubuntuforums.org/showthread.php?t=2270362 /etc/init.d/lirc auf den "falschen" Pfad patched und das zwangsweise Beenden der ersten irexec-Instanz aus dem stop-case übernimmt (killall in dieser Distro nicht standardmäßig installiert):

    Bis das ohnehin wegen seiner auf 50µs begrenzten (Un-)Genauigkeit auf meiner Abschussliste stehende mceusb (vgl. http://www.vdr-portal.de/board…besondere-elv#post1241754) ersetzt werden kann, möchte ich die udev-Regeln ungern stilllegen, da dieses Dongle sich unter den meisten anderen Kernels gerne mal aufhängt und seit es diese gibt dann durch Ab- und Wiederanstecken reaktiviert werden kann.

    Starte ich nach service lirc stop
    manuell /usr/sbin/lircd --device=/dev/lirc0 --listen
    und dann /usr/bin/irexec [-d] /etc/lirc/lircrc_
    gibt letzteres (bzw. bei -d dann ircat irexec) nichts aus, aber irw funktioniert weiter.


    Dabei fällt auf, daß ircat0.9.0-pre1 -c bzw. --config= nicht annimmt, sondern eine hartcodierte /etc/lirc/lirc/lircrc (also eine Verzeichnisebene "doppelt gemoppelt") verlangt.


    Setze ich nun für /usr/bin/irexec -d /etc/lirc/lirc/lircrc statt des Kommandos eine einfache Protokollierung, erscheint diese auch als user.notice in logread:
    config = echo irsend | logger


    Erstaunlicherweise finde ich dort ohne logger auch Spuren von irsend selbst:

    Code
    1. Apr 19 15:13:37 debian daemon.notice lircd-0.9.0-pre1[15911]: accepted new client on /var/run/lirc/lircd
    2. Apr 19 15:13:37 debian daemon.info lircd-0.9.0-pre1[15911]: removed client

    Es scheint also speziell irsend im Kontext von irexec ohne Effekt (aber eben auch ohne Fehlermeldung) zu bleiben.


    Lagert man irsend mit vorangestelltem sleep 3 && in ein seinerseits mit config = /etc/lirc/lirc/test.sh & abgehängt gestartetes Skript aus, funktioniert es (mit der so erzwungenen Verzögerung).


    Schließe ich daraus richtig folgendes?
    Bug 1: mceusb ist erst mehrere Sekunden nach letztem Empfang (Loslassen der Taste) sendefähig
    Bug 2: lircd-0.9.0-pre1 ist für /usr/bin/ircat und /usr/bin/irexec irgendwo fälschlich festverdrahtet auf /etc/lirc/lirc/lircrc
    Bug 3: Die zugehörige /etc/init.d/lirc hingegen versucht irexec dazu nicht passend fest mit -d /etc/lirc/lircrc so zu starten, daß trotz gemeldetem [ ok ] hinterher auch lircd/irw nicht benutzbar ist.

    Nicht dass ich wüsste, Tastatureingaben landen normalerweise einfach auf dem gerade aktiven TTY. Außerdem generiert dein Empfänger laut der Ausgabe gar keine "richtigen" Tastatur-Tastendrücke über den Treiber, sondern liefert mangels keytable zum Übersetzen in ein EV_KEY (vermutlich da er im Lirc-Modus läuft) nur ein EV_MSC mit dem decodierten Scancode, der von der Fernbedienung kommt.

    Ja, die Taste hatte ich in /etc/rc_keymaps/Universal8in1 noch nicht eingetragen (der Kernel sollte sie für lircrc ja nicht namentlich kennen müssen), sondern bislang nur in /etc/lirc/lircd.conf definiert.


    Damit ich es sprachunabhängig durchschaue:

    Code
    1. /dev/input# hexdump -C event2
    2. 00000000 07 91 33 55 fc 34 0e 00 04 00 04 00 15 00 10 00 |..3U.4..........|
    3. 00000010 07 91 33 55 fc 34 0e 00 00 00 00 00 00 00 00 00 |..3U.4..........|
    4. 00000020 08 91 33 55 b6 bf 00 00 04 00 04 00 15 00 10 00 |..3U............|
    5. 00000030 08 91 33 55 b6 bf 00 00 00 00 00 00 00 00 00 00 |..3U............|

    6 bytes Zeitstempel, 2 Bytes Event, 2 Bytes EV_MSC, 4 Bytes Scancode - d.h. auf diese letzten 4-8 Bytes müsste (m)ein Programm ggf. in Endlosschleife warten?


    Durch ir-keytable -c -w /etc/rc_keymaps/Universal8in1 bekanntgemachte Scancodes erzeugen ja nur für Tastatureingaben benötigte zusätzliche key-down/up-Events (also eigentlich nicht nötig, wenn ein Scancode lediglich z.B. eine irsend-Sequenz anstoßen soll) und machten für u.g. Effekt auch keinen Unterschied.


    seahawk1986 wrote:

    Kannst du deine Konfiguration eventuell ein bisschen genauer beschreiben? Bislang hatte ich keine Probleme damit irexec und einen lirc-Client, der vom Lirc-Socket liest, parallel zu nutzen.


    Debian wheezy mit bodhi-Kernel 3.16 erwies sich als stabilstes für Pogoplug E02 in mehreren Installationen, die folgende Aufgaben gemein haben:
    /usr/sbin/lircd --device=/dev/lirc0 --listen # mceusb, mit Clients wie VDR bidirektional (inkl. irsend) an LAN-Port 8765
    /usr/sbin/LCDd -s 1 -f -c /etc/LCDd.conf # VFD zur Statusanzeige bzw. für vdr-plugin-lcdproc wo vorhanden
    iptables # dynamisches Blacklisting v.a. der SSH-Bruteforce-Botnetze
    sshd # einzige "Konsole", und Tunnel zu übrigen Maschinen im LAN


    /etc/lirc/lircrc sollte im einfachsten Fall z.B. bei Druck auf eine IR- oder RF-Fernbedienung einen LED-Stripe schalten:

    Code
    1. begin
    2. prog = irexec
    3. remote = Universal_8in1
    4. button = VPWR
    5. config = irsend send_once I44 KEY_POWER
    6. end

    service lirc restart sorgt dann aber dafür, daß auf irw lokal wie an Clients (obwohl "pass 1" davon doch gar nicht betroffen sein sollte) und auch ir-keytable -t Funkstille einkehrt, bis /etc/lirc/lircrc wieder deaktiviert und lirc restarted wird (es genügt auch noch kein kill auf die PID von /usr/bin/irexec -d /etc/lirc/lircrc).

    Danke! :] Ähnliche Sequenzen habe ich für meine Einsatzorte in bash zusammengestellt.


    Läuft denn z.B. unter Debian&Derivaten nicht bereits systemseitig ein standardisierter Handler (außerhalb X11 etc.), der auf Tastendruck (Events) bestimmte Programme (Shellskript etc.) starten kann?
    Dann müsste ja kein weiterer wie von Dir in Python zusätzlich auf diese warten (habe headless ARMs im Einsatz, deren Installation natürlich so schlank wie möglich bleiben soll).


    Der "Basic setup flow" auf http://www.lirc.org/html/configuration-guide.html scheint mir nicht ganz zu stimmen, denn bei irw (angeblich als "pass 1" vor lircrc) kommt weder auf der LIRC-Maschine selbst noch bei ihrem Client weiter etwas an, sobald lircrc angelegt ist und dadurch automatisch irexec mitgestartet wird.

    Wie kann ich denn unter Debian unabhängig von /etc/lirc/lircrc & irexec einfach bei Auftreten eines Key-Events wie nachstehendem ein Programm starten lassen?

    ir-keytable -t wrote:

    Testing events. Please, press CTRL-C to abort.
    1429393119.200066: event MSC: scancode = 100015
    1429393119.200066: event sync


    Nicht lircrc, da bei dessen Verwendung ja nur noch darin (über irexec o.ä.) behandelte Tasten beachtet und deren Codes laut /etc/lirc/lircd.conf dann nicht mehr an (auch auf Clients laufendes) irw oder sonstige Anwendungen weitergeleitet werden.
    Kein xbindkeys o.ä., da kein grafischer Desktop.
    Konkreter Anlass ist, unabhängig auch vom VDR bestimmte Fernbedienungstasten zur Szenensteuerung zu nutzen, also irsend-Befehle an weitere Geräte absetzen zu lassen.

    http://localhost:8001/vdradmin.pl?aktion=rc_show&full_rc=1 :]
    Bzw. in http://localhost:8001 mit dem "TV select"-Symbol http://localhost:8001/bilder/view.png natürlich direkt z.B. aus dem EPG http://localhost:8001/vdradmin.pl?aktion=prog_summary umschaltbar.


    Ich verwende auf mehreren Maschinen allerdings vdr-sxfe an xineliboutput und normalerweise LIRC wie in http://ubuntuforums.org/showthread.php?t=2270362, aber obiges VDRadmind-AM als Fallback wenn unter einem der Kernels >3.16 (oder vor DKMS), in denen z.B. mceusb oder der DVBsky-Fork für cx23885 nicht stabil läuft.

    Greif doch den Code direkt im Sender ab, bevor er auf HF aufmoduliert wird.
    Empfängerseitig ist das schwierig, da Du ohne aufsynchronisieren das Nutzsignal nicht vom rauschen unterscheiden kannst.

    Die letzten Fernbedienungen ihrer Art :rolleyes: wollte ich nur ungern zerlegen (und habe immer noch kein Oszi), doch zum Glück konnte ich herausbekommen, daß 10 Nullen Vorspann gesendet werden - war dann nicht so schlimm, daß nicht alle davon beim einschwingenden Empfänger ankommen.
    Nach ein paar Runden mode2 ließ sich das Protokoll dann austüfteln und anstelle unsauberer Samples eine lircd.conf "synthetisieren".
    Fehlt mir nur ein Transceiver mit feinerem Timing als 50µs und idealerweise hoher IR-Reichweite.
    Evtl. nimmt sich hier ja einer der LIRC- oder Einschalter-µC-Entwickler http://www.harctoolbox.org/lirc_rpi.html an und verallgemeinert das zu einem Modul mit gepflegtem Kerneltreiber?

    Kann es sein das der DKMS mit o.g. Kernel nicht hinhaut ? Ich kann weder den 331er noch den 304er Nivida Treiber automatisch als auch per Hand übersetzen.. er meckert immder das er die Header/src nicht findet.. die sind aber an der üblichen Stelle Installiert... oder soll ich es gleich mal mit dem 3.19er Versuchen ?

    3.19 habe ich noch nicht zum Laufen bekommen, 3.16 (allerdings Mainline) aber mit den beiden Aufrufen von dpkg-reconfigure aus https://bugs.launchpad.net/ubu…-drivers-331/+bug/1268257 - HTH...

    Gab es da nicht verschieden schnelle Protokolle?

    Klar gibt's die, ein FS10-Protokoll z.B. bekomme ich v.a. über die gemischte IR-/Funkstrecke bei 50us max. Auflösung selten erkennbar übertragen, selbst bei synthetischer statt gesampleter lircd.conf (100us-Timings, die das mceusb aber wohl dennoch nicht genau genug abstrahlt; klassisch seriell funktionierts, aber ab Riesenkiste mit 15-fachem Stromverbrauch).


    Quote

    Die Activy verwendete doch ein schnelleres... Gibt doch versch. Tsops. Da sollte ein passender zu finden sein. Und dann daraus einen klassischen seriellen Empfänger mit Elko und Widerstand, wenn ich es korrekt erinnere machen und da einen FTDI232 da dran und gut.

    Meinst Du http://www.huitsing.nl/irftdi/ ? Der hatte im Prototyp auch einigen Jitter, sollte aber verkraftbar sein.
    Die mceusb-Limitierung scheint aber nicht am TSOP zu liegen, sondern eine eingebaute Bremse im Treiber (wahrscheinlich wegen weniger performanter, nicht allzu akkurater Dongle-Hardware) zu sein - oder kennt jemand einen Weg, sie für genaueres Timing zu lösen?

    Quote

    Nimm aber einen echten! Gibt viele Fakes...

    Wäre einem Fertiggerät mit qualitätsgesicherten Komponenten nicht abgeneigt (schon um mehr Zeit fürs allein ausreichend kopfschmerzträchtige Reversen&alternative Implementieren diverser Gebäudeautomatisierungsprotokolle zu haben), Hauptsache es wird vom Standardkernel unterstützt: Für http://dangerousprototypes.com/docs/Vanesse:_USB_IR_Toy_v3 &
    http://dangerousprototypes.com…pdated-irwidget-firmware/ scheint das ja noch nicht soweit zu sein (IRMAN-Modus kann wohl nur empfangen).


    Immerhin scheint mein langjähriger Vorschlag eines "eierlegenden Wollmilchtransceivers" (RF/IR-Integration, mehrere Übertragungswege an GPIO, zur Laufzeit abschaltbarer Softcarrier) durch den Raspberry Pi nun endlich Umsetzung zu erfahren: http://www.harctoolbox.org/lirc_rpi.html :]
    Das (evtl. inkl. Möglichkeiten neben festen Tasten auch Meßwerte diverser auf gleicher Hardware empfangbarer Funksensoren auszugeben) muß allerdings auch erst alles den Rückweg in LIRCs Standard(kernel)module finden.

    Gegenwärtig scheint das Timing noch nicht perfekt, da ein so vom seriellen Dongle erzeugtes IR-(zu-RF-)Signal erkannt wird, nicht aber das gleiche vom mceusb gesendet (was ja die eigentliche Motivation war, von den raw_codes wegzukommen - nun aber zumindest testweise Timingänderungen erheblich erleichtert).

    Evtl. ist das mit dem mceusb auch nicht hinzubekommen, da hartkodierte Auflösungsbegrenzung in http://lxr.free-electrons.com/…rivers/media/rc/mceusb.c:
    #define MCE_TIME_UNIT 50 /* Approx 50us resolution */
    (vgl. http://sourceforge.net/p/lirc/mailman/message/24253837/)


    Welcher Transceiver wird denn vom Standardkernel gut unterstützt und gibt Samples möglichst hochauflösend&originalgetreu (wie die alten seriellen Homebrew-Dongles) weiter&wieder?

    Ich weiss zwar nicht, was du genau machen willst. Aber "Visualisierung" von LIRC mache ich immer mit dem Speicheroszi. Ich lasse mir die lirc.conf erst nach Moeglichkeit generieren und verwende sie anschliessend zum Senden.


    Da sieht man naemlich erst was von LIRC oft fuer ein Schrott-lirc.conf generiert wird. Solche Fehler wuerde man anders kaum finden. Siehe auch 334


    Von Hand kann man die lirc.conf dann aber solange bequem tunen bis Original und Kopie auf dem Display exakt zur Deckung kommt.


    Ich habe es ohne Oszi z.B. mit der in http://web.archive.org/web/200…chl.fundf.net/wsprotocol/ unter Datenübertragung & Telegrammaufbau dokumentierten Codierung zu tun (Sensoren und Fernbedienungen haben bei FS10 ein gemeinsames Protokoll, vgl. http://www.elv.de/controller.aspx?cid=726&detail=33279).
    Beschrieben sind 10 Nullbits Header; 4N1; 1187,5 Mikrosekunden/Bit, 1 kurz, 0 lang (>50% Taktzeit).


    Die RF demoduliere ich mit einem IR-Umsetzer ähnlich http://web.archive.org/web/201…e.com.tw/ir-extender.html (und umgekehrt).


    LIRC liefert das im Eingangspost genannte sehr schiefe Ergebnis (ähnlich oft auch bei reinen IR-Fernbedierungen).
    Gerne würde ich anhand des theoretisch bekannten Signaltimings (statt unscharfer Samples) die lircd.conf erstellen, finde aber weder Erfahrungsberichte, wonach andere das ebenso schon durchgeführt hätten, noch das Dateiformat hinreichend für LIRC selbst dokumentiert.


    Nach den Angaben zum Derivat http://winlirc.sourceforge.net/technicaldetails.html und o.g. Protokollbeschreibung hätte ich mit einer SHIFT_ENC (heute RC5) gerechnet.
    Das Format des Dateikopfes ist zu WinLIRC einigermaßen beschrieben, aber was sollen <phead> <shead>, <leading pulse> und pre* enthalten, und v.a. wie genau verhalten sich die raw_codes zur Ausgabe?
    Als Paare aus Takt- und Totzeiten in Mikrosekunden schienen sie kaum zum erwarteten Signal zu passen - aber auch ohne Oszilloskop erscheinen mir Anstiegs- und Abklingzeiten von um die 100us bei IR-Halbleiterschaltungen nicht unwahrscheinlich.


    Es muß doch über http://www.righto.com/2010/03/…ir-remote-codes-lirc.html hinaus Dokumentation dazu geben, wie "saubere" Samples nach raw umgesetzt, und letztere umgekehrt ins Standardformat "verfeinert" werden sollen?
    Finden konnte ich hierzu jedoch nichts.
    Tatsächlich konnte ich aber mit einem anhand der raw_codes (vgl. mode2) ersonnenen und bisher wohl noch nirgends sonst beschriebenen Verfahren eine synthetische lircd.conf erstellen, die eine SPACE_ENC mit 500us Puls gefolgt von 250-300us Pause für 0 und 700us Pause für 1 enthält.


    Die Schwierigkeit dabei war, daß FS10 zumindest wie es sich aus den LIRC-Samples darstellt offenbar mit dem 5. stets gesetzten "Stop"-Bit beginnt, gefolgt von einem odd-parity-Bit (also gesetzt wenn die Summe der drei folgenden Bits gerade ist - damit rechnete ich nur, wenn auch nicht an dieser Position, auch nur weil das serielle Protokoll des ELV-Sensorempfängers schon eine vergleichbare Auffälligkeit aufweist).


    Diese manuell ausgetüftelte lircd.conf wiederum vermag dann irrecord -a anders als seine eigenen Samples in ein "nicht mehr rohes" Hex-Format zu überführen (evtl. mit einer führenden 0 zuviel):

    Für jedes Bit der binären Darstellung dieser Hex-Codes wird dann (mit dem MSB beginnend bis zum LSB, d.h. "von links nach rechts") das jeweilige o.g. Muster für zero oder one übertragen und man sieht, wie nur die letzten 3 von je 5 Bits (neben Stop und Parity) tatsächlich "Nutzlast" enthalten.
    Gegenwärtig scheint das Timing noch nicht perfekt, da ein so vom seriellen Dongle erzeugtes IR-(zu-RF-)Signal erkannt wird, nicht aber das gleiche vom mceusb gesendet (was ja die eigentliche Motivation war, von den raw_codes wegzukommen - nun aber zumindest testweise Timingänderungen erheblich erleichtert).

    Du solltest folgenden Eintrag in /etc/rc_maps.cfg hinzufügen:

    Code
    1. * rc-dvbsky Universal8in1


    Wenn du eine vernünftige Distribution nutzt

    Hat stattdessen nur zu Ubuntu 14.04 LTS gereicht, ;)

    /lib/udev/rules.d/40-ir-keytable.rules wrote:

    # Automatically load the proper keymaps after the Remote Controller device
    # creation.
    # The keycode tables rules should be at /etc/rc_maps.cfg


    ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $name"

    die Universal8in1 in /lib/udev/rc_keymaps (statt /etc/rc_keymaps) erwartet, also dorthin kopiert und folgende Zeile angehängt:

    /etc/rc_maps.cfg wrote:

    cx23885 rc-dvbsky Universal8in1


    Quote

    hast du eine udev-Regel in /usr/lib/udev/rules.d/, die dann ir-keytable -a ... beim Auftauchen eines rc-core devices ausführt. Siehe den letzten Code-Schnipsel meines letzten Kommentars.

    Vielen Dank, das hat geholfen, :] da durch Debian etc. von Pfaden abgesehen ebenso gelöst.

    Wo sollte denn zum Autostart folgende Zeile hin?
    ir-keytable -c -w /etc/rc_keymaps/Universal8in1 -s rc
    Sie z.B. in /etc/init.d/inputlirc order /etc/rc.local zu murksen, dürfte zur Verwendung durch das System der Kernel-Events ja "suboptimal" sein.