[iwow]

Hallo,

ein kleines Problem habe ich jetzt noch. Aus irgend welchen Gründen scheint sich die Initialisierung der USB Geräte geändert zu haben. Ich starte inputlirc ja mit genau den Devices, die zum USB-IR-Reciver gehören. Leider sind diese Devices zum Zeitpunkt wo inputlirc startet nicht vorhanden. Wenn ich mich dann mit SSH auf dem System anmelde sind sie da und ich kann /etc/init.d/inputlirc start erfolgreich ausführen. In der Datei /var/log/sysinit steht folgendes:

Code: [Select]

Initialisation wakeup:
^[[1A^[[83G^[[1;32mdone^[[0;39m
Could not open /dev/input/event2: No such file or directory
Could not open /dev/input/event3: No such file or directory
Unable to open any event device!
Starting inputlircd:
^[[1A^[[83G^[[1;32mdone^[[0;39m
Loading sound driver:
^[[1A^[[83G^[[1;32mdone^[[0;39m

Loading dvb driver
^[[1A^[[83G^[[1;32mdone^[[0;39m
Loading usb dvb driver
Starting xorg
^[[1A^[[83G^[[1;32mdone^[[0;39m
^[[1A^[[83G^[[1;32mdone^[[0;39m
Starting VDR
^[[1A^[[83G^[[1;32mdone^[[0;39m

Vielleicht ist ja meine neue Sat Karte (TiVii S480 die als zwei USB Devices erkannt wird) daran schuld. Kann die das Laufzeitverhalten beeinflussen? Kann man die Reihenfolge, in der die Services gestartet werden beeinflussen?

Danke.

Gruß Wolfgang

 

[clausmuus]

in der Datei /etc/init.d/inputlirc, kannst Du im Bereich init unter before zum vdr auch noch das dvb eintragen (before="vdr dvb"), oder einfach das vdr durch dvb ersetzen, dann wird in Zukunft inputlirk vor dvb gestartet.

Claus

[clausmuus]

Woran lässt sich eigentlich erkennen welches event Device das richtige ist? Können wir das irgendwie automatisieren? oder stört es gar nicht, das alle verfügbaren Devices genommen werden?

Claus

[iwow]

Hallo Claus,

habe deine Vorschlag von oben ausprobiert, hat aber leider nicht geholfen.

Woran erkennt man das richtige device?

Also ich schaue mir immer die Ausgaben von cat /proc/bus/input/devices an. Bei mir kommt da folgendes raus (Tastatur + Fernbedienung, aber keine Maus):

Code: [Select]

I: Bus=0003 Vendor=046d Product=c30e Version=0110
N: Name="Logitech HID compliant keyboard"
P: Phys=usb-0000:00:13.5-3.2/input0
S: Sysfs=/devices/pci0000:00/0000:00:13.5/usb1/1-3/1-3.2/1-3.2:1.0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0
B: PROP=0
B: EV=120013
B: KEY=10000 7 ff800000 7ff febeffdf f3cfffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=046d Product=c30e Version=0110
N: Name="Logitech HID compliant keyboard"
P: Phys=usb-0000:00:13.5-3.2/input1
S: Sysfs=/devices/pci0000:00/0000:00:13.5/usb1/1-3/1-3.2/1-3.2:1.1/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=13
B: KEY=fff ffffffff ffffffff 0 2000000 387a d800d001 1e0000 0 0 0
B: MSC=10

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:13.5-3.3/input0
S: Sysfs=/devices/pci0000:00/0000:00:13.5/usb1/1-3/1-3.3/1-3.3:1.0/input/input2
U: Uniq=
H: Handlers=sysrq kbd event2
B: PROP=0
B: EV=120013
B: KEY=e080ffdf 1cfffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:13.5-3.3/input1
S: Sysfs=/devices/pci0000:00/0000:00:13.5/usb1/1-3/1-3.3/1-3.3:1.1/input/input3
U: Uniq=
H: Handlers=kbd mouse0 event3
B: PROP=0
B: EV=17
B: KEY=1f0000 0 2020000 3878 d801d001 1e0000 0 0 0
B: REL=103
B: MSC=10

I: Bus=0003 Vendor=9022 Product=d660 Version=0000
N: Name="IR-receiver inside an USB DVB receiver"
P: Phys=usb-0000:02:00.1-1/ir0
S: Sysfs=/devices/pci0000:00/0000:00:06.0/0000:02:00.1/usb2/2-1/input/input6
U: Uniq=
H: Handlers=kbd event4
B: PROP=0
B: EV=3
B: KEY=6c0904 2470c1 0 0 0 8 10000 190 40000840 1e1680 1 f8000000 ffc

I: Bus=0003 Vendor=9022 Product=d660 Version=0000
N: Name="IR-receiver inside an USB DVB receiver"
P: Phys=usb-0000:02:00.3-1/ir0
S: Sysfs=/devices/pci0000:00/0000:00:06.0/0000:02:00.3/usb3/3-1/input/input7
U: Uniq=
H: Handlers=kbd event5
B: PROP=0
B: EV=3
B: KEY=6c0904 2470c1 0 0 0 8 10000 190 40000840 1e1680 1 f8000000 ffc

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input8
U: Uniq=
H: Handlers=kbd event6
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input9
U: Uniq=
H: Handlers=kbd event7
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

Am Namen erkenne ich dann, zu welchen Eingabe-Device das /dev/input/eventX gehört. Bei mir ist das N: Name="HID 05a4:9881"

Auf alle Devices zu hören geht leider nicht, weil inputlircd mit der Option -g gestartet werden muss was dazu führt, das kein anderer Prozess mehr auf das Device zugreifen kann. Lässt man -g weg, werden z.B. die Tasten Rauf / Runter doppelt interpretiert (einmal von inputlircd und einmal über X). Wenn man dann also alle Devices überwacht kann man nicht mehr über die Tastatur arbeiten.

Eine Möglichkeit wäre, das X nicht auf die Devices der Fernbedienung hört. Das habe ich aber leider nicht hinbekommen, da die xorg.conf anscheint immer neu geschrieben wird. Bei mir steht da z.B.

Code: [Select]

 InputDevice "Input-event0"
  InputDevice "Input-event1"
  InputDevice "Input-event2"
  InputDevice "Input-event3"

Warum event4-7 fehlt weiß ich nicht.


Gruß Wolfgang

P.S. MLD 3.0 läuft nun schon 3 Tage im Dauerbetrieb (4 Personenhaushalt). Läuft bisher alles super.  :applaus  

[clausmuus]

Was hast Du denn in der /etc/rc.config unter INPUTRC_ARGS eingetragen? Interessant ist der Wert, der die oben genannte FehlerProduziert.

Hast Du eigendlich mehr als 4 /dev/input/eventX devices? Beim Start von x wird nacgeschaut welche event devices existieren und für alle einträge in der xorg.conf angelegt. Du kannst das unterbinden indem Du dem Layout nen anderen Namen als Layout-MLD gibst.

Claus

[iwow]

Hallo

@Claus: zunächst zu deinen Fragen:

Ich habe bei INPUTLIRC_ARGS foglendes stehen: /dev/input/event2 /dev/input/event3 -g -c -m0

Physikalisch habe ich folgende Eingabegeräte:
1) USB-Tastatur (event0 und event1)
2) MCE Fernbedienung: (event2 und event3; einmal Maus, einmal Tastatur)
3) IR Receiver an der TeVii S480 (event4 und event5; warum 2 erkannt werden kann ich nicht genau sagen, evtl. weil die S480 aus zwei USB S660 besteht und jede davon einen IR hat)
4) Power Button (event6 und event7; warum der 2 mal erkannt wird ==> keine Ahnung)

Ich glaube nun eine recht stabile Lösung gefunden zu haben.

1) Ich starte inputlirc so spät wie möglich (in /etc/init.d/xorg before="inputlirc" eingetragen); seitdem kommen die Fehlermeldungen von oben, das /dev/input/eventX nicht geöffnet werden kann nicht mehr).
2) Ich habe versucht, den -g Parameter bei inputlirc zu entfernen. Der sorgt ja dafür, das nur noch inputlirc von dem Device lesen kann und somit die Tasten nicht doppelt vom VDR interpretiert werden (einmal inputlirc, einmal X). Ich habe dazu aus der remote.conf alle bis auf einem Eintrag (User9) für KGB und XKey entfernt und inputlirc mit allen event devices gestartet /dev/input/event*. Läuft zumindestens seit gestern Abend OK.

@Claus/MarMic: Was haltet Ihr von der Lösung? Könnte man das in den Standard aufnehmen (z.B. wenn inputlirc installiert ==> dann andere remote.conf).


Jetzt habe ich noch ein Problem mit meinem neuen Mainboard, dafür öffne ich gleich einen anderen Thread (sonst OOT )

Gruß Wolfgang  

[iwow]

Hallo,

zunächst einmal die gute Nachricht. Die Treiberinstallation funktioniert mit dem dvb-remote addon ohne Probleme  :applaus

Ich glaube ich habe auch eine mögliche Ursache dafür gefunden, das ich inputlirc erst nach xorg starten muss.

Wenn der USB IR Empfänger direkt an eine USB-Buchse des PCs angeschlossen ist, startet inputlirc ohne Probleme. Wenn der Empfänger aber wie in meinem Fall über eine aktive USB-Verlängung + USB-HUB angeschlossen ist, muss ich den Kunstgriff mit xorg machen. Nur dann startet inputlirc zuverlässig.

Werde diese Vermutung mal überprüfen, indem ich die aktive USB-Verlängung bzw. USB-Hub weg lasse.

Eine

[clausmuus]

Wie muss die runvdr angepasst werden. Eigendlich sollte inputlircd ebenso wie lircd erkannt werden.

Claus

[iwow]

Hallo Claus,

ich habe die Zeile 54 wie folgt angepasst:

Code: [Select]

       if ps | grep -v "grep" | grep -q "inputlircd" && (! test -e /usr/bin/vdr
 
Wenn ich jetzt so drüber nachdenke ist das glaube ich nicht wirklich notwendig, da grep -q "lircd" als Filter auch für inputlircd funktioniert.

Oder?

Gruß Wolfgang

[iwow]

Hallo,

die Probleme hören nicht auf  :computertod

Ich bekomme ab und zu folgende Meldung in /var/log/messages

Code: [Select]

Jul 27 16:09:34 (none) user.err kernel: hub 1-3.1:1.0: port 2 disabled by hub (EMI?), re-enabling...
Jul 27 16:09:34 (none) user.info kernel: usb 1-3.1.2: USB disconnect, device number 5
Jul 27 18:09:34 (none) user.err inputlircd: Error processing event from event2: No such device


Jul 27 18:09:34 (none) user.notice root: HOTPLUG: input DEVNAME=input/event2 ACTION=remove HOME=/ SEQNUM=1499 MAJOR=13 DEVPATH=
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: input UNIQ="" PROP=0 ACTION=remove PHYS="usb-0000:00:12.2-3.1.2/input0" HOME=
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb ACTION=remove HOME=/ SEQNUM=1502 DEVPATH=/devices/pci0000:00/0000:00:12.2
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: hid HID_ID=0003:000005A4:00009881 ACTION=remove HOME=/ SEQNUM=1501 DEVPATH=/d
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: input DEVNAME=input/mouse0 ACTION=remove HOME=/ SEQNUM=1503 MAJOR=13 DEVPATH=
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: input DEVNAME=input/event3 ACTION=remove HOME=/ SEQNUM=1504 MAJOR=13 DEVPATH=
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: hid HID_ID=0003:000005A4:00009881 ACTION=remove HOME=/ SEQNUM=1506 DEVPATH=/d
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: input UNIQ="" PROP=0 ACTION=remove PHYS="usb-0000:00:12.2-3.1.2/input1" HOME=
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb ACTION=remove HOME=/ SEQNUM=1507 DEVPATH=/devices/pci0000:00/0000:00:12.2
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb_device DEVNAME=usbdev1.5 ACTION=remove HOME=/ SEQNUM=1508 MAJOR=189 DEVPA
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb DEVNAME=bus/usb/001/005 ACTION=remove HOME=/ SEQNUM=1509 BUSNUM=001 MAJOR
Jul 27 16:09:34 (none) user.info kernel: usb 1-3.1.2: new low speed USB device number 6 using ehci_hcd
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb DEVNAME=bus/usb/001/006 ACTION=add HOME=/ SEQNUM=1510 BUSNUM=001 MAJOR=18
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: usb ACTION=add HOME=/ SEQNUM=1511 DEVPATH=/devices/pci0000:00/0000:00:12.2/us
Jul 27 18:09:34 (none) user.notice root: HOTPLUG: hid HID_ID=0003:000005A4:00009881 ACTION=add HOME=/ SEQNUM=1512 DEVPATH=/devi
Jul 27 16:09:35 (none) user.info kernel: input: HID 05a4:9881 as /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.2/1-3.1.
Jul 27 16:09:35 (none) user.info kernel: generic-usb 0003:05A4:9881.0005: input: USB HID v1.10 Keyboard [HID 05a4:9881] on usb-
Jul 27 18:09:35 (none) user.notice root: HOTPLUG: input UNIQ="" PROP=0 ACTION=add PHYS="usb-0000:00:12.2-3.1.2/input0" HOME=/ S
-

Danach reagiert die Fernbedienung nicht mehr und es hilft nur noch ein inputlirc restart.

Es scheint so, als ob sich der IR-USB Empfänger ab und zu vom USB Bus abmeldet. Der IR-USB Empfänger ist wie folgt angeschlossen.

IR-USB-Empfänger ==> USB-HUB mit Stromversorgung ==> Aktive USB Verlängerung (8m) ==> USB-Kabel durch die Decke ==> PC

Scheint wohl nicht die beste Lösung zu sein. Kennt jemand eine Andere Lösung, um 10m zwischen PC und Empfänger zu überbrücken?

[clausmuus]

erst mal wäre wichtig zu wissen, ob es reicht inputlircd neu zu starten, ob der Treiber neu geladen werden muss, oder ob beides erforderlichist.
Also beim nächsten ausfall mal gezielt nur einen der Teile neu starten.
Das Automatisieren kommt dann später.

Claus

[iwow]

Hallo,

ich habe die Ausfälle nun einige Zeit beobachtet. Ich konnte nicht alle Ausfälle untersuchen, da ich meiner Frau und meine beiden Kindern "nur" ein CTRL-ALT-F1 und dann reboot zumuten möchte.

Die Ausfälle die ich beobachtet habe lassen sich wie folgt beschreiben:

a) Bild und Ton wird normal dargestellt, die Fernbedienung reagiert nicht. Mit CTRL-ALT-F1 in die Console gewechselt und mit "ps | grep input" überprüft, ob inputlirc noch läuft. Es war immer so, das inputlirc nicht mehr lief (in der message Datei war oben aufgeführte Fehlermeldung zu finden). Ein lsmod zeigt, das der Treiber mceusb noch da ist. Nach einem /etc/init.d/inputlirc start mit anschliessendem Umschalten auf die X-Console war das Problem behoben. VDR einschl. xbmc konnten danach einwandfrei bedient werden.

B) Bild steht bzw. es wird das MLD-Logo angezeigt. Fernbedienung funktioniert noch. Nach 2mal OK Taste auf FB drücken kommt auch das Bild/Ton wieder.

c) Bild steht bzw. es wird das MLD-Logo angezeigt. Fernnbedienung funktioniert nicht. Wenn ich dann das gleiche wie unter a) durchführe und dann 2mal OK drücke, bekomme ich auch ein Bild wieder.

d) Es ist genau einmal vorgekommen, das im Fall c) ein neustart von inputlirc nichts gebracht hat. Da die Kinder schnell etwas sehen wollten, konnte ich mir leider nicht die Zeit nehmen, erst den mceusb Treiber mit rmmod / modprobe neu zu laden.

Es liegt also sehr häufig daran, das inputlirc sich einfach beendet.

@Claus: Infos soweit OK?

Ich werde nun analog zu runvdr ein Script schreiben, das inputlirc automatisch neu startet, wenn sich inputlirc unerwartet beendet (nur wenn eine Datei /tmp/inputlirc_stop existiert, wird wirklich beendet, wie bei runvdr)

Das ist für mich aber nur ein Workaround. Ich werde wohl meine alten C Kenntnisse noch mal rauskramen und das inputlirc Programm so ändern, das es damit zurecht kommt, das ein Device "verschwindet" bzw. "hinzu kommen" kann.

Oder hat jemand noch eine andere Idee?

Gruß Wolfgang

[MarMic]

puh absolut keinen plan dazu

vllt kannste ja mal inputlirc aufruf stracen und mitloggen... vllt finden wir dann raus warum es sich verabschiedet. strace findest du im config.devel addon.

greetz MarMic

p.s. haben andere leute im netz ähnliche probs??

[clausmuus]

Ich denke das ist eher nen job für nen debugger
OK, ich werd's nicht debuggen. Aber nen script schreiben, dass automatisch inputlirc neu startet, das sollte ich hin bekommen.
Morgen gibt's ne neue Version.

Claus

[iwow]

Hallo Claus,

warum bist du der Meinung, das man hier debuggen muss?

Für mich ist das Verhalten von inputlirc erklärbar:

Immer dann, wenn ein USB disconnect kommt, wird das event Device z.B. /dev/input/event2 ungültig.

Inputlirc reagiert darauf mit einem "exit (EX_OSERR))"

Code: [Select]

if(read(evdev->fd, &event, sizeof event) != sizeof event) {
 syslog(LOG_ERR, "Error processing event from %s: %sn", evdev->name, strerror(errno));
 exit(EX_OSERR);
}

Für mich stellt sich die Frage, warum ein disconnect kommt. Im Internet habe ältere Einträge (2007 / 2008) gefunden, das es damit zusammen hängen könnte, das der Kernel so konfiguriert ist, das autosuspend  eingeschaltet ist:


Quelle 1

oder

Quelle 2

In der zweiten Quelle wird folgendes empfohlen

Code: [Select]

1) As root open for editing the file "/etc/rc.local", e.g. by "sudo nano /etc/rc.local"

2) Add the following three lines before the last line (which should contain the text "exit 0" and must be kept like that).

echo -1 > /sys/module/usbcore/parameters/autosuspend
sleep 1
/usr/sbin/lsusb

3) Restart your machine


Der Pfad (/sys/module...) scheint sich beim aktuellen Kernel geändert zu haben, aber laut
dieser Dokumentation ist es weiterhin möglich.

Meint Ihr es ist ein Versuch wert oder suche ich an der falschen Stelle?

Gruß Wolfgang