(yaVDR) IR-Empfänger einmal anders.

wino · 17. Juni 2012

Das Verhalten ist nicht yaVDR spezifisch. Habe yaVDR testweise installiert weil ich den Machern eine hohe Kompetenz anrechne und gehofft hatte, dass dieses Problem hier nicht auftritt.

Der Empfänger wird im angesteckten Zustand während des Bootvorgangs nicht erkannt und somit keine Treiber geladen. Erst nachdem das System betriebsbereit ist und ich diesen Empfänger abziehe und wieder anstecke, wird er erkannt und arbeitet korrekt.

Code

kernel: [   63.052088] Registered IR keymap rc-rc6-mce
kernel: [   63.052353] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:060c) as /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc0/input7
kernel: [   63.052587] rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:060c) as /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc0
kernel: [   63.058355] IR NEC protocol handler initialized
kernel: [   63.064918] IR RC5(x) protocol handler initialized
kernel: [   63.069692] IR RC6 protocol handler initialized
kernel: [   63.074690] IR JVC protocol handler initialized
kernel: [   63.079301] IR Sony protocol handler initialized
kernel: [   63.083804] IR SANYO protocol handler initialized
kernel: [   63.089144] input: MCE IR Keyboard/Mouse (mceusb) as /devices/virtual/input/input8
kernel: [   63.091126] IR MCE Keyboard/mouse protocol handler initialized
kernel: [   63.099908] lirc_dev: IR Remote Control driver registered, major 251 
kernel: [   63.102351] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
kernel: [   63.102360] IR LIRC bridge handler initialized
kernel: [   63.292114] mceusb 2-3:1.0: Registered   BB+ Dongle(e.d) with mce emulator interface version 1
kernel: [   63.292125] mceusb 2-3:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active)
kernel: [   63.292188] usbcore: registered new interface driver mceusb
lircd-0.9.0[2071]: could not open config file '/etc/lirc/lircd.conf'
lircd-0.9.0[2071]: No such file or directory
lircd-0.9.0[2072]: lircd(default) ready, using /var/run/lirc/lircd-lirc0
lircd-0.9.0[2072]: accepted new client on /var/run/lirc/lircd-lirc0

Alles anzeigen

Der Logauszug dient nur zur Erkennung um was es sich für ein Gerät hantelt.

MfG
wino

seahawk1986 · 17. Juni 2012

Wie wäre es mit ein bisschen mehr Infos - falls vorhanden Ausgabe von lsusb, udev-Attribute http://www.yavdr.org/documenta…e/ch02s03.html#udev-tools
Mich würde interessieren, warum da für ein Gerät, das eigentlich über rc-core läuft zusätzlich noch eine LIrc-Instanz über den lircd_helper gestartet wird...

wino · 17. Juni 2012

Die gewünschten Daten.
ir-keytable

Code

Found /sys/class/rc/rc0/ (/dev/input/event7) with:
        Driver mceusb, table rc-rc6-mce
        Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC other
        Enabled protocols: RC-6
        Repeat delay = 500 ms, repeat period = 125 ms

Die LIRC-Instanz wird wohl wegen der Unterstützung des Protokolls gestartet.

sudo udevadm info --query=all --attribute-walk --name=/dev/input/event7

Code

looking at device '/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc0/input7/event7':
    KERNEL=="event7"
    SUBSYSTEM=="input"
    DRIVER==""


  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc0/input7':
    KERNELS=="input7"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Media Center Ed. eHome Infrared Remote Transceiver (0471:060c)"
    ATTRS{phys}=="usb-0000:00:02.0-3"
    ATTRS{uniq}==""
    ATTRS{properties}=="0"


  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/rc/rc0':
    KERNELS=="rc0"
    SUBSYSTEMS=="rc"
    DRIVERS==""
    ATTRS{protocols}=="rc-5 nec [rc-6] jvc sony sanyo mce_kbd lirc"


  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0':
    KERNELS=="2-3:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="mceusb"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{bInterfaceClass}=="ff"
    ATTRS{bInterfaceSubClass}=="ff"
    ATTRS{bInterfaceProtocol}=="ff"
    ATTRS{supports_autosuspend}=="0"


  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb2/2-3':
    KERNELS=="2-3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="a0"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{urbnum}=="42"
    ATTRS{idVendor}=="0471"
    ATTRS{idProduct}=="060c"
    ATTRS{bcdDevice}=="0101"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="2"
    ATTRS{devnum}=="7"
    ATTRS{devpath}=="3"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}==" "
    ATTRS{product}=="BB+ Dongle(e.d)"
    ATTRS{serial}=="@KD@"

Alles anzeigen

lsusb -vvv

Code

Bus 002 Device 007: ID 0471:060c Philips (or NXP) Consumer Infrared Transceiver (HP)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0471 Philips (or NXP)
  idProduct          0x060c Consumer Infrared Transceiver (HP)
  bcdDevice            1.01
  iManufacturer           1  
  iProduct                2 BB+ Dongle(e.d)
  iSerial                 3 @KD@
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

Alles anzeigen

MfG
wino

seahawk1986 · 17. Juni 2012

Zitat von wino

Die LIRC-Instanz wird wohl wegen der Unterstützung des Protokolls gestartet.

Zumindest das kann ich bei meinem CIR-Empfänger, der auch LIRC als Protokoll unterstützt nicht beobachten... und eine entsprechende udev-Regel in /lib/udev/rules.d/98-lircd.conf, die den lircd_helper aufruft kann ich auch nicht sehen.

Was sagt denn die Ausgabe davon:

Code

ps ax | grep lirc

Warum der Empfänger beim Booten nicht erkannt wird, weiß ich leider auch nicht... (d.h. dass z.B. lsusb nach dem Booten nichts für das Gerät ausgibt, bis es erneut eingesteckt wurde?)

wino · 17. Juni 2012

Zitat
Was sagt denn die Ausgabe davon:
Code
ps ax | grep lirc

Die Ausgabe von ps ax | grep lirc

Code

1036 ?        S<s    0:00 /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd
 1037 ?        Ss     0:00 /usr/bin/irexec /etc/lirc/lircrc
 1511 ?        S<sl   0:15 /usr/bin/vdr --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown.wrapper -E /var/cache/vdr/epg.data -u vdr -g /tmp --port 6419 -w 0 -Pconflictcheckonly -Pfemon -Pmarkad -Pepgsearchonly -Pmenuorg -Pxvdr -t 10 -Pquickepgsearch -Pdvbhddevice -Pwirbelscan -Ptext2skin -Pskinpearlhd --epgimages=/var/cache/vdr/epgimages -Plive --port=8008 --ip=0.0.0.0 --log=INFO --epgimages=/var/cache/vdr/epgimages -Pextrecmenu -Pepgsearch -f /usr/bin/svdrpsend -Pchannellists -Prestfulapi --port=8002 --ip=0.0.0.0 --epgimages=/var/cache/vdr/epgimages --channellogos=/usr/share/vdr-channellogos -Pdbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hooks-wrapper=/usr/share/vdr/plugins/dbus2vdr/shutdown-wrapper --upstart -Piptv -Pstreamdev-server -Pdynamite 
 6042 ?        Ss     0:00 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lirc/lircd-lirc0.pid /etc/lirc/lircd.conf
 6048 ?        S      0:00 /usr/bin/python /usr/bin/lircd2uinput --lircd-socket=/var/run/lirc/lircd-lirc0
 7915 tty1     S+     0:00 grep --color=auto lirc

Zitat

Warum der Empfänger beim Booten nicht erkannt wird, weiß ich leider auch nicht... (d.h. dass z.B. lsusb nach dem Booten nichts für das Gerät ausgibt, bis es erneut eingesteckt wurde?)

Genau das ist das Problem. Das Gerät wird beim Booten nicht erkannt und wird auch nicht bei der Ausgabe von lsusb angezeigt.

Code

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter
Bus 002 Device 006: ID 0db0:6982 Micro Star International Medion Flash XL Card Reader

Noch eine Besonderheit. Nach Poweroff bleibt der Empfänger aktiv (grüne LED leuchtet weiter) und nimmt weiter Tastendrücke (rote LED) entgegen.

MfG
wino

seahawk1986 · 17. Juni 2012

Hast du mal versucht die Option "USB-wakeup deaktivieren bei inkompatibler Hardware" zu nutzen?

wino · 17. Juni 2012

Wenn man sich einmal auf gda verlässt. Nur ein Scherz! Seiner Empfehlung bin gefolgt hierund nun das.

MfG
wino

seahawk1986 · 17. Juni 2012

Was für ein Mainboard hast du denn? Wenn da schon die ACPI-Unterstützung im Eimer ist...

wino · 17. Juni 2012

Zitat

Hast du mal versucht die Option "USB-wakeup deaktivieren bei inkompatibler Hardware" zu nutzen?

Nein, die Option lässt sich nur bei aktivierten Suspend to RAM auswählen.

MfG
wino

wino · 17. Juni 2012

Zitat

Was für ein Mainboard hast du denn? Wenn da schon die ACPI-Unterstützung im Eimer ist...

Es ist ein Asrock N68-S3 UCC mit einem Athlon II X2 4400e (unlocked Sempron 140).

EDIT: OK. Du hast mich mit Deiner Nachfrage mit der Nase (leuchtende LEDs) auf das Problem gestoßen. Mal schauen ob im BIOS etwas verstellt ist. Danke für Deine Bemühung mir zu helfen.

MfG
wino

wino · 17. Juni 2012

Den Empfänger kann ich mit diesem Board vergessen. Ein anderer tut es.

Code

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter
Bus 002 Device 002: ID 0bc7:0006 X10 Wireless Technology, Inc. Wireless Transceiver (ACPI-compliant)
Bus 002 Device 003: ID 0db0:6982 Micro Star International Medion Flash XL Card Reader

MfG
wino

speefak · 19. Juni 2012

ich habe da ein ähnliches problem :

der empfänger wird angezeigt, auch kommen eingaben beim irw. allerdings passiert im XBMC rein gar nichts.

seahawk1986 · 19. Juni 2012

Zitat von speefak

uch kommen eingaben beim irw. allerdings passiert im XBMC rein gar nichts.

IMHO ist das ein ganz anderes Problem...
Kannst du das System genauer beschreiben? Nutzt du in deinem Setup überhaupt eventlircd?

(yaVDR) IR-Empfänger einmal anders.

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema