[gelöst] [0.4] Wie genau evmap ändern? (X10)

    Hallo,


    ich muss gestehen, ich habe noch nicht so viel Erfahrung mit (ya)vdr. Bei yavdr 0.3 habe ichs grad hinbekommen meine Tastenbelegung zu ändern über die remote.conf und jetzt kam eventlircd mit 0.4.


    Also ich habe folgende X10 Fernbedienung: http://www.vdr-wiki.de/wiki/in…p/Fernbedienung_-_USB_X10 (die ganz Linke)


    lsusb ->

    Code
    1. Bus 005 Device 002: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)


    Also greift für diese FB ja wohl /etc/eventlircd.d/03_0bc7_0006.evmap wenn ich das richtig verstanden habe:



    Links das Tasten Event, rechts das Lirc Event.


    Ich möchte die Tasten den UserTasten nach meinem Belieben zuordnen, um mit keymacros zu arbeiten, um z.B. XBMC per Knopfdruck aus dem vdr heraus zu starten.


    Wenn ich das richtig verstehe, schaue ich nun in der remote.conf nach, welche Tasten den User[0-9] zugeordnet sind:



    Wie muss der entsprechende Eintrag jetzt in der evmap aussehen, sodass ich mit der Taste KEY_DVD(kommt bei irw an wenn ich die Taste DVD drücke) auf LIRC.User0 z.B. mappe?

    Code
    1. KEY_DVD = KEY_TEXT

    ?????


    Ich bitte um Hilfe,


    Grüße, Kokel

    Hardware Ranch

    The post was edited 1 time, last by kokel ().

    Hallo, soweit ich das sehe, hast du es richtig verstanden. Nach der Änderung muss dann noch eventlircd neu gestartet werden.

    Code
    1. sudo stop eventlircd
    2. sudo start eventlircd
    Meine VDRs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    OK, danke, hat jedoch nicht funktioniert.


    Habe Testweise die Zuweisung in der /etc/eventlircd.d/03_0bc7_0006_pollin.evmap vorgenommen und da hats zwar funktioniert, allerdings mappt das Lirc Event "KEY_TEXT" auf den Videotext, klar.


    1. Was sind denn die Lirc Events für die User[0-9] Tasten?
    2. Warum greift denn die oben genannte evmap und nicht die /etc/eventlircd.d/03_0bc7_0006.evmap?
    In der /lib/udev/rules.d/98-eventlircd-names.rules steht:


    Code
    1. ATTRS{name}=="X10 Wireless Technology Inc USB Receiver", \
    2. ENV{eventlircd_enable}="true", \
    3. ENV{eventlircd_evmap}="03_0bc7_0006.evmap"
    6. ATTRS{name}=="X10 WTI RF receiver", \
    7. ENV{eventlircd_enable}="true", \
    8. ENV{eventlircd_evmap}="03_0bc7_0006_pollin.evmap"


    lsusb siehe erstem Post. Demnach müsste doch die evmap 03_0bc7_0006.evmap greifen, es greift jedoch die mit dem suffix _pollin.

    Hardware Ranch

    Zu 1) Ein Blich in die remote.conf oder diese Tabelle: https://bugs.yavdr.com/project…tegration_04#Eventmapping sollte die Frage nach den Tastennamen eigentlich beantworten. Links die VDR-internen Lirc-Tasten, rechts der Name des "Events" der ankommen muss, um die Taste auszulösen.
    Zu 2) Die Udev-Regel schaut in diesem Fall nicht auf die ID von Modell und Hersteller, sondern matcht nach dem Namen des angeschlossenen Empfängers, da das das ein valides Entscheidungsmerkmal im Gegensatz zur Produkt- und Hersteller-ID ist.
    Mehr über die Merkmale eines Geräts, die udev verwerten kann findet man mittels udevadm heraus: http://www.yavdr.org/documenta….html#udev#udev-crashkurs

    Meine VDRs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Danke für die Antwort.


    Hatte die User0 in der keymacros.conf doppelt belegt, sorry, das war mein Fehler.


    Es funktioniert jetzt.


    Aber das die udev Regel mit dem suffix _pollin greift ist mir immer noch ein Rätsel


    • lsusb: X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)
    • 03_0bc7_0006.evmap X10 Wireless Technology Inc USB Receiver
    • 03_0bc7_0006_pollin.evmap X10 WTI RF receiver


    Da matcht meines Verständnisses nach "03_0bc7_0006.evmap" besser oder wie läuft das matching genau ab?

    Hardware Ranch

    Was udev so sieht, siehst du wenn du per "cat /proc/bus/input/devices" den Pfad deines X-10 Empfängers als Eingabegerät herausfindest und dann folgendes Aufrufst:

    Code
    1. sudo udevadm info --query=all --attribute-walk --name=/dev/input/eventX # wobei eventX das entsprechende Eingabegerät ist
    Meine VDRs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    OK, demnach stimmts:


    Code
    1. looking at parent device '/devices/pci0000:00/0000:00:1d.3/usb5/5-1/input/input3':
    2. KERNELS=="input3"
    3. SUBSYSTEMS=="input"
    4. DRIVERS==""
    5. ATTRS{name}=="X10 WTI RF receiver"
    6. ATTRS{phys}=="usb-0000:00:1d.3-1/input0"
    7. ATTRS{uniq}==""
    8. ATTRS{properties}=="0"


    Aber warum udev das so sieht versteh ich immer noch nicht, aber andere Baustelle.


    Newbie Frage, wie setzte ich den Thread auf "Solved" ?

    Hardware Ranch
    kokel wrote:

    Aber warum udev das so sieht versteh ich immer noch nicht, aber andere Baustelle.


    Weil es eben nur auf die Variable

    Code
    1. ATTRS{name}=="X10 WTI RF receiver"

    schaut. Klingt komisch ist aber ganz natürlich und erklärlich ;)

    kokel wrote:

    Newbie Frage, wie setzte ich den Thread auf "Solved" ?


    Am besten den Titel des ersten Posts verändern, das Forum hier hat AFAIK noch keinen extra Knopf dafür.

    Meine VDRs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    seahawk1986 wrote:

    Weil es eben nur auf die Variable

    Quellcode


    1 ATTRS{name}=="X10 WTI RF receiver"


    schaut. Klingt komisch ist aber ganz natürlich und erklärlich ;)


    Aber wo ist die Variable gesetzt ?


    Und warum zeigt ein lsusb

    Code
    1. Bus 005 Device 002: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)


    einen anderen String als cat /proc/bus/input/devices


    Code
    1. I: Bus=0003 Vendor=0bc7 Product=0006 Version=0100
    2. N: Name="X10 WTI RF receiver"
    3. P: Phys=usb-0000:00:1d.3-1/input0
    4. S: Sysfs=/devices/pci0000:00/0000:00:1d.3/usb5/5-1/input/input3
    5. U: Uniq=
    6. H: Handlers=kbd mouse0 event3
    7. B: PROP=0
    8. B: EV=7
    9. B: KEY=108c0020 200004300000000 1b0000 8f00 1018091400811 9e1ec100000000 7407f41840ffc
    10. B: REL=3
    Hardware Ranch

    Vielleicht kann das einer Beantworten der da tiefer drin steckt... Ich vermute mal Ausgabe des im USB-Gerät gespeicherten Namens vs. Name im Treiber.

    Meine VDRs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ab Kernel 3.2 wird es eh eine rc-core Variante dieses Treibers geben.


    Auf den Namen mussten wir matchen weil der ati_remote Treiber einen Bug hatte der anders als andere Empfänger die VENDOR_ID und PRODUCT_ID nicht korrekt gelesen werden konnte und somit die Standardvariante über usbid nicht zog. (Paul Bender hatte hierzu einen Patch gepostet auf der Lirc ML imho)