Eventlirc bei IMON_PAD FB: Blaue Taste funktioniert nach Aufwachen aus Suspend To RAM nicht mehr da

  • Hi,


    das Thema mit der Bauen Taste gibt es ja hier im Forum schon einige male (u.a. auch von mir).
    Wie ich anderswo geschrieben hatte, habe ich es auch hinbekommen mit einer eigenen Keymap Datei
    /etc/rc_keymap/imon_pad.


    Darin steht für die blaue Taste (Pictures) der iMon-Pad FB:
    0x2ba115b7 KEY_BLUE


    anstelle von
    0x2ba115b7 KEY_IMAGES


    da ja KEY_IMAGES aus mir unbekannten Gründen nicht über /etc/eventlircd.d/03_15c2_0038.evmap
    gemappt wird.
    In /etc/rc_maps.cfg steht:
    * rc-imon-pad /etc/rc_keymaps/imon_pad
    damit meine Keytable auch gefunden wird.


    Nach einem Reboot ist alles bestens, wacht der VDR aber aus dem Suspend To RAM wieder auf,
    wird die Blaue Taste nicht mehr erkannt.


    Aufgefallen ist mir ein Unterschied bei ir-keytable.
    Nach einem Neustart wird /sys/class/rc/rc0 benutzt:

    Code
    Found /sys/class/rc/rc0/ (/dev/input/event5) with:
            Driver imon, table rc-imon-pad
            Supported protocols: RC-6 other
            Enabled protocols: other
            Repeat delay = 500 ms, repeat period = 125 ms


    Nach dem Aufwachen aus Suspend To RAM aber rc3, rc5, ...:

    Code
    Found /sys/class/rc/rc3/ (/dev/input/event5) with:
            ...


    ir-keytable -t --device /dev/input/event5 liefert für die blaue Taste
    nach dem Reboot:

    Code
    1321104346.691187: event MSC: scancode = 2ba115b7
    1321104346.691195: event key down: KEY_BLUE (0x0191)
    1321104346.691197: event sync
    1321104346.811187: event key up: KEY_BLUE (0x0191)
    1321104346.811191: event sync


    nach dem Aufwachen:

    Code
    1321104577.281673: event MSC: scancode = 2ba115b7
    1321104577.281682: event key down: KEY_IMAGES (0x01ba)
    1321104577.281684: event sync
    1321104577.505668: event key up: KEY_IMAGES (0x01ba)
    1321104577.505673: event sync


    Ich habe auch schon versucht, den Eintrag in /lib/udev/rc_keytables/imon_pad anzupassen.
    Aber auch damit hatte ich keinen Erfolg.


    Ich hoffe, einer der Eventlirc-Experten hier im Forum kann mir da weiter helfen.


    Ich liefere gerne auch noch weitere Infos.


    Danke
    Norbert

  • Nach dem Aufwachen aus Suspend To RAM aber rc3, rc5, ...:


    Ist der Rest der ir-keytable Ausgabe bis auf das rc-Gerät identisch oder gibt es da noch Unterschiede?


    Funktioniert die Taste wieder, wenn du nach dem Standby folgendes ausführst?

    Code
    sudo ir-keytable -w /etc/rc_keymaps/imon_pad

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi Seahawk,


    ja, der Rest der Ausgabe passt. Kein Unterschied.


    Nach dem Nachladen der Keytable funktioniert die Taste auch wieder.
    Hab das Gefühl, dass beim Aufwachen aus dem Suspend To RAM weder meine, noch
    die aus /lib/udev/rc_keytable gelesen wird.


    Wie kann ich da weiter debuggen?


    Danke
    Norbert

  • Hab das Gefühl, dass beim Aufwachen aus dem Suspend To RAM weder meine, noch
    die aus /lib/udev/rc_keytable gelesen wird.


    Da fühlst du vermutlich richtig...
    Versuch mal eine /etc/apm/resume.d/99ir-keytable anzulegen:

    Bash
    #!/bin/sh
    #
    # apmd proxy script for ir-keytable
    
    
    [ -x /usr/bin/ir-keytable ] || exit 0
    /usr/bin/ir-keytable -a  /etc/rc_maps.cfg

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Und so?

    Bash
    #!/bin/sh
    #
    # apmd proxy script for ir-keytable
    
    
    [ -x /usr/bin/ir-keytable ] || exit 0
    /usr/bin/ir-keytable -w /etc/rc_keymaps/imon_pad

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Schon besser, allerdings muss ich noch das Device hinzufügen:

    Code
    /usr/bin/ir-keytable -w /etc/rc_keymaps/imon_pad --device /dev/input/event5


    Da ich sonst auch eine Fehlermeldung bekomme.


    Damit hat es jetzt mehrfach geklapp :]
    Allerdings bin ich nicht sicher, dass meine imon_pad immer an event5 hängt.
    Ich habe da auch schon anderes gesehen und auch die Reihenfolge war schonmal anders.


    Zur Vollständigkeit halber hier mal die Ausgabe von ir-keytable nach einem Reboot:



    Ist das jetzt ein spezielles Problem mit meinem System, oder ist das eher allgemeiner Natur?


    Vielen Dank für die schnelle Hilfe
    Norbert

  • Ist das jetzt ein spezielles Problem mit meinem System, oder ist das eher allgemeiner Natur?


    Gute Frage, ich habe kein System mit drei rc-core Empfängern, das ich in den Standby schicken kann...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wenn ich mit meinem System was testen soll, mach ich das gerne.
    Sag einfach Bescheid.


    Benutzen tue ich nur den in meinem Silverstone Gehäuse verbauten Empfänger.
    Die anderen sind halt in den SAT-Karten integriert. Der Eigentliche Empfänger ist bei denen
    aber gar nicht angeschlossen.


    Gruß
    Norbert

  • Ok, mal ein bisschen Spielwiese:


    1. Idee:
    Die /etc/apm/resume.d/99ir-keytable mal wegverschieben oder löschen.
    Vor dem Resume mal folgendes probieren:

    Code
    rmmod rc_core
    # jetzt meckert er, dass da noch andere Module geladen sind - die notieren


    Nach dem Resume mal probieren:

    Code
    sudo rmmod rc_core <Die anderen Module mit Leerzeichen getrennt>
    sudo modprobe rc_core <Die anderen Module mit Leerzeichen getrennt>


    Klappt danach wieder alles mit den Tasten?


    2. Idee:
    Als Inhalt der /etc/apm/resume.d/99ir-keytable:

    Bash
    #!/bin/sh
    #
    # apmd proxy script for ir-keytable
    
    
    [ -x /usr/bin/ir-keytable ] || exit 0
    for a in /dev/input/event*; do ir-keytable -a /etc/rc_maps.cfg -D=$a; done


    3. Variante:
    Als Inhalt der /etc/apm/resume.d/99ir-keytable:

    Bash
    #!/bin/sh
    #
    # apmd proxy script for ir-keytable
    
    
    [ -x /usr/bin/ir-keytable ] || exit 0
    for a in /dev/input/event*; do /usr/bin/ir-keytable -w /etc/rc_keymaps/imon_pad -D=$a; done

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi Seahawk,

    hier die Ergebnisse.

    1. Idee:


    Vor Resume

    Code
    #rmmod rc_coreERROR: Module rc_core is in use by budget_ci,rc_hauppauge,cx88xx,ir_lirc_codec,rc_tt_1500,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,rc_imon_pad,ir_rc6_decoder,imon,ir_rc5_decoder,ir_nec_decoder



    Nach Resume


    Code
    # rmmod rc_core  budget_ci rc_hauppauge cx88xx ir_lirc_codec rc_tt_1500 ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder rc_imon_pad ir_rc6_decoder imon ir_rc5_decoder ir_nec_decoderERROR: Module rc_core is in use bybudget_ci,rc_hauppauge,rc_tt_1500,cx88xx,rc_imon_pad,ir_lirc_codec,ir_mce_kbd_decoder,imon,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoderERROR: Module budget_ci is in useERROR: Module cx88xx is in use by cx88_dvb,cx8800,cx8802ERROR: Module imon is in use# modprobe rc_core  budget_ci rc_hauppauge cx88xx ir_lirc_codec rc_tt_1500 ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder rc_imon_pad ir_rc6_decoder imon ir_rc5_decoder ir_nec_decoder


    Blaue Taste geht aber trotzdem nicht.



    2. Idee:
    Klappt nicht.
    Allerdings sagt mir die Man-Page auch das -D für den Delay ist und -d für das Device.
    Führe ich die letzte Zeile direkt in der Konsole aus bekomme ich folgendes:

    Code
    # for a in /dev/input/event*; do ir-keytable -a /etc/rc_maps.cfg -d $a; done
    Auto-mode can be used only with --read, --debug and --sysdev options
    Auto-mode can be used only with --read, --debug and --sysdev options
    ...


    Insgesamt 12 Fehlermeldungen.


    3. Idee:
    Klappt, aber auch hier habe ich -D durch -d ersetzt.
    Wenn ich die Befehlszeile in der Konsole ausführe ist die Ausgabe sehr lang. Für event5 bekomme ich:

    Code
    #  /usr/bin/ir-keytable -w /etc/rc_keymaps/imon_pad -d /dev/input/event5
    Read imon_pad table
    Wrote 91 keycode(s) to driver
    Speicherzugriffsfehler


    Für alle anderen lange Listen von

    Code
    Read imon_pad table
    Setting scancode 0x288195b7 with 0x00ae via EVIOCSKEYCODE: Invalid argument
    Setting scancode 0x289115b7 with 0x0074 via EVIOCSKEYCODE: Invalid argument
    Setting scancode 0x298115b7 with 0x00a7 via EVIOCSKEYCODE: Invalid argument


    Auch wenn event5 den Speicherfehler meldet, ist die blaue Taste danach auch wieder OK.


    Gruß
    Norbert

  • Hab auch noch einmal probiert.
    Am Besten hatte mir die Lösung gefallen mit dem Nachladen über die 99ir-keytable Datei.


    Ich habe sie jetzt noch etwas geändert, damit sie auch tut, wenn meine imon_pad mal nicht auf event5 sitzt.
    Geht sicherlich eleganter, scheint aber zu funktionieren:


    /etc/apm/resume.d/99ir-keytable


    Bash
    #!/bin/sh
    #
    # apmd proxy script for ir-keytable
    
    
    [ -x /usr/bin/ir-keytable ] || exit 0
    
    
    ir-keytable -w /etc/rc_keymaps/imon_pad -d $(ir-keytable 2>&1 | grep -B 1 rc-imon-pad | grep -o "/dev/input/event.")


    Norbert

  • Ist auf jeden Fall schöner als blind allen Eingabegeräten die Keymap überzustülpen...
    Am schönsten wäre wohl z.B. per cat /proc/bus/input/devies die rc-core Geräte herauszufischen und dann für diese "ir-keytable -a /etc/rc_maps.cfg -d <sysfs-Pfad>" aufzurufen, wie es beim ersten Start durch die udev-Regel passiert.
    Das hätte auch den Vorteil, dass es universell verwendbar und ggf. in yaVDR integrierbar wäre falls noch mehr Leute das Problem nach dem Standby haben.


    Falls du noch Lust hast, könntest du es so nochmal ausprobieren:

    Code
    for remote in $(ir-keytable 2>&1 | grep rc/rc | egrep -o "rc[0-9]{1,}"); do ir-keytable -a /etc/rc_maps.cfg --sysdev $remote ; done


    Damit sollten die Regeln aus der /etc/rc_maps.cfg nochmals auf alle rc-core Empfänger angewendet werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!