VDR Portal

Quoted from "poggenpower"

das mit dem --unput habe ich auch noch nicht ganz verstanden. Das Konzept vom yaVDR ist doch, dass alles - auch der lircd - die Events in den eventlircd pumpt. Soll ich da was dran ändern?

Also mit --uinput erzeugt lircd ein Eingabegerät unter /dev/input/event<X>, das von eventlircd mittels udev-Regel eingebunden wird (weil es lircd heißt). Das Problem dabei ist IMHO, dass zu viele Tastendrücke von der FB pro Tastendruck auf diesem Gerät ankommen. Mein Ansatz ersetzt nun das, was --uinput machen würde, erlaubt dabei abgestimmt auf die eigene Fernbedienung die Wunsch-Tastenwiederholrate usw. anzupassen und erstellt letztendlich auch ein Eingabegerät unter /dev/input/event<X>, das dann von eventlircd ausgewertet wird - nur ohne nervige Tastenpreller und mit auf Wunsch mehr an die eigenen Bedürfnisse angepasster Tastenwiederholrate.

In deinem Fall brauchst du nur das Paket python-uinput aus dem yaVDR-PPA nachzuinstallieren, das Skript holen

und den lircd_helper wie hier beschrieben anzupassen: [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe
lircd2uinput.py kannst du noch übergeben, wie es auf gedrückt gehaltene Tasten reagieren soll:

Hmm,

irgendwie hört sich das für mich nach "von hinten durch die Brust ins Auge" an. Aber es bringt schon mal ein bisschen Klarheit.

Das was ich jetzt verstanden habe ist folgendes:

So ist es:



Dein Vorschlag:


Ist es dann nicht einfach und zuverlässiger (weil kein patch) einfach den VDR direkt an den lircd zudocken, wie man das früher auch gemacht hat? Der VDR wird ja schon mit einer (wenn auch falschen) lirc-Config gestartet.

Oder ein noch besserer Ansatz, aber dafür musste ich mehr vom eventlircd verstehen:
Man macht den eventlircd heile, dass er mit den Events klar kommt.

Gruß
Thomas

Mein Vorschlag:

Quoted from "poggenpower"

Ist es dann nicht einfach und zuverlässiger (weil kein patch) einfach den VDR direkt an den lircd zudocken, wie man das früher auch gemacht hat? Der VDR wird ja schon mit einer (wenn auch falschen) lirc-Config gestartet.

Wieso falsche lircd-config?
Wenn du nur lircd nutzen willst, dann muss der VDR aber auf den Start von lircd warten. Meine Lösung ist für die nächste Version von yaVDR schon größtenteils in den Quellen und funktioniert bei mir und den anderen im yaVDR-Team, die noch lircd-Empfänger verwenden soweit ich gehört habe gut...

Quoted from "poggenpower"

Man macht den eventlircd heile, dass er mit den Events klar kommt.

Warum sollte man eventlircd fixen, wenn es nicht kaputt ist (aber wenn du da was basteln willst hält dich keiner davon ab )?

Quoted from "seahawk1986"

Wieso falsche lircd-config?

Weil die VDR konfiguriert ist, dass es lirc benutzen soll. Ich weiss nicht, ob das ein Überbleibsel ist, weil ich mal lirc über das WFE konfiguriert habe:

Aus dem Syslog:
Jan 3 17:23:50 poempel vdr: [2414] ERROR: lircd connection broken, trying to reconnect every 3.0 seconds

der VDR Prozess
vdr 1160 1 9 17:24 ? 00:00:19 /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 [...]

Wenn es ein Überbleibsel ist. Wie werde ich es wieder los? Habe schon die Templates durchgesehen, bin aber nicht fündig geworden.

Quoted from "seahawk1986"

Wenn du nur lircd nutzen willst, dann muss der VDR aber auf den Start von lircd warten.

Ahh O.K. das habe ich mittlerweile auch verstanden. Aber ich schätze ich habe da gerade eh ein Problem, dass VDR auf den Lircd wartet. s.o.

Quoted from "seahawk1986"

Meine Lösung ist für die nächste Version von yaVDR schon größtenteils in den Quellen und funktioniert bei mir und den anderen im yaVDR-Team, die noch lircd-Empfänger verwenden soweit ich gehört habe gut...

O.K. das hört sich doch auch gut an! Ein paar Verständnisfragen habe ich trotzdem noch s.u.

Quoted from "seahawk1986"

Zitat von »poggenpower«



Man macht den eventlircd heile, dass er mit den Events klar kommt.

Quoted from "seahawk1986"

Warum sollte man eventlircd fixen, wenn es nicht kaputt ist (aber wenn du da was basteln willst hält dich keiner davon ab )?

Nee, will ja eben nicht basteln. Nach ein wenig nachdenken, liegt das unterschiedliche Verhalten ja im LIRCD.
Was ich noch nicht verstehe sind zwei Dinge:

1. Unterschiedliche Events
Warum schickt der lircd unterschiedliche (Anzahl) an Events an die unterschiedlichen sockets

• /var/run/lirc/lircd-usb~hiddev0: alles im grünen Bereich
• /dev/input/event<X> : Events in drei unterschiedliche Varianten und die in unkontrollierter Dopplung.
  

Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.
Oder kann man dem lircd bei der Option -uinput beibringen die Events so zu schicken wie auf dem Standardsocket.
Ich will nicht die Arbeit an dem phython-wrapper schlecht machen, es geht mir drum, dass was an einer stelle schon richtig ist nicht an einer anderen Stelle noch mal zu korrigieren.

2. Drei Varianten
Laut den Traces, die ich gepostet, habe funktioniert der Eventlirc IMHO richtig, es gibt keine Dopplung der einzelnen Events mehr gibt. Nur scheint es drei Typen (Nummeriert 1,2,3) zu geben, die der Lircd ins Userland schickt. Hat jemand einen Tipp, warum es die drei unterschiedlichen Events gibt?
Würde der python-warpper das auch kompensieren oder auf welchen der drei Typene reagiert er?
Gibt es eine Beschreibung wie python-uinput funktioniert? und wo es sich die Events herholt und ausgibt.

Gruß
Thomas

Was das Thema lircd und uinput angeht : lircd schickt die uinput Tastendrücke irgendwo mitten in der Verarbeitungskette - ob man das jetzt einen Bug nennt oder gewünscht - ich nenne es mal Fehlverhalten, seahawkslsg setzt sich auf den lircd-Sockel von lircd und wandelt die dort ankommenden Tastendrücke nach uinput um damit es über eventlircd zusammengefasst werden kann. Und ja genau für diesen Fall ist seine Lösung gedacht.

Quoted from "poggenpower"

der VDR Prozess
vdr 1160 1 9 17:24 ? 00:00:19 /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 [...]
Wenn es ein Überbleibsel ist. Wie werde ich es wieder los?

Das ist kein Überbleibsel. Wenn du dir die Templates, die Upstart-Skripte (unter /etc/init/) und die udev-Regeln (/lib/udev/rules.d) durchsiehst merkst du, dass /var/run/lirc/lircd der Socket ist, auf dem Eventlircd dem VDR die gesammelten Eingabeevents übergibt. Lircd hat - wenn es über das WFE aktivert ist für Serielle Empfänger einen Socket, der als /var/run/lirc/lircd.<pid von lircd> angelegt wird, für USB-Lirc-Empfänger wird (in der /lib/udev/rules.d/98-lircd.rules) per udev-Regel der Start des /lib/udev/lircd_helper ausgelöst - ein Socket von so einem Lircd-Prozess, der von diesem Skript gestartet wurde heißt dann z.B. /var/run/lirc/lircd-usb~hiddev0

Quoted from "poggenpower"

Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.

Eventlircd sammelt wie der Name schon sagt Tastendrücke von Eventgeräten (/dev/input/event<X>) ein und gibt sie über einen Lircd-Socket wieder aus. Meine Bridge macht also nichts anderes als eventlircd ein sinnvoll verwertbares Eventgerät ohne Tastenpreller zur Verfügung zu stellen. Von gda gab es bereits einen Patch zu eventlircd, der dessen Repeat-Filter einstellbar gemacht hat - das Problem mit einem Nachlaufen der Fernbedienung bei länger gedrückt gehaltener Taste wurde dadurch aber eher noch verstärkt, daher mein Ansatz.

Quoted from "poggenpower"

Oder kann man dem lircd bei der Option -uinput beibringen die Events so zu schicken wie auf dem Standardsocket.

Kann man sicherlich, nur muss man es auch können - wie gesagt wenn sich jemand da um sinnvolle Änderungen verdient machen will nur zu...

Quoted from "poggenpower"

Nur scheint es drei Typen (Nummeriert 1,2,3) zu geben, die der Lircd ins Userland schickt.

Jein, bei Eventgeräten gibt es 0 = Taste losgelassen 1 = Taste gedrücht und 2 = wiederholter Tastendruck (siehst du bei evtest in deiner Ausgabe, dass es da prellt/eine Taste fälschlicherweise als gedrückt gehalten erkannt wird).

Quoted

Das wirft evtest heraus, bei einem klick auf "OK"

Source code

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Event: time 1325458096.603920, type 1 (Key), code 352 (Ok), value 1 Event: time 1325458096.603935, -------------- Report Sync ------------ Event: time 1325458096.847884, type 1 (Key), code 352 (Ok), value 2 Event: tiwei Prgramme weiter me 1325458096.847893, -------------- Report Sync ------------ Event: time 1325458096.887887, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458096.887894, -------------- Report Sync ------------ Event: time 1325458096.927884, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458096.927892, -------------- Report Sync ------------ Event: time 1325458096.967887, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458096.967894, -------------- Report Sync ------------ Event: time 1325458097.007883, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.007890, -------------- Report Sync ------------ Event: time 1325458097.047882, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.047889, -------------- Report Sync ------------ Event: time 1325458097.087885, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.087892, -------------- Report Sync ------------ Event: time 1325458097.127884, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.127892, -------------- Report Sync ------------ Event: time 1325458097.167887, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.167894, -------------- Report Sync ------------ Event: time 1325458097.207884, type 1 (Key), code 352 (Ok), value 2 Event: time 1325458097.207891, -------------- Report Sync ------------ Event: time 1325458097.240142, type 1 (Key), code 352 (Ok), value 0 Event: time 1325458097.240156, -------------- Report Sync -----------

-

Ich weiß nicht was du beobachtet hast aber das ist der Socket von Eventlircd und da zählt irw einfach nur hoch, was ja (falls das Einzeltastendrücke sein sollen) zeigt, dass es prellt:

Quoted

	Source code
1 2 3 4 5 6 7 8	root@poempel:~# irw 67 0 KEY_UP devinput 67 1 KEY_UP devinput 67 2 KEY_UP devinput 160 0 KEY_OK devinput 160 1 KEY_OK devinput 160 2 KEY_OK devinput [...]

Quoted from "poggenpower"

Könnte da eventlirc nicht einfach direkt von /dev/usb/hiddev0 Daten einsammeln.

Ganz ohne lircd dazwischen? Dann müsstest du einen auf deine FB/Empfängerkombination angepassten Treiber schreiben, damit eventlircd valide Tastenevents bekommt...

Quoted from "poggenpower"

Gibt es eine Beschreibung wie python-uinput funktioniert? und wo es sich die Events herholt und ausgibt.

python-uinput ist nur eine Python-Bibliothek, die es erlaubt ein Eventgerät zu erzeugen und darauf Tastendrücke auszugeben. Schau dir doch einfach mal den Code an (ist bei Python ja nicht schwer da ranzukommen . Mein Skript (das von einem Lircd-Sockel liest und dann mittels python-uinput die Events weitergibt) findest du bei GitHub: https://github.com/yavdr/yavdr-utils/tre…er/lircd2uinput

Hallo!

Vielen Dank für die vielen und sehr ausführlichen Antworten! Das gibt insbesondere seahawk!
Jetzt verstehe ich schon viel mehr und die lircd2uinput Lösung gefällt mir immer besser.

Zu mal ja auf dem lircd-Socket schon entprellte Events ankommen, sollte da ja nicht mehr viel schief gehen.

Danke
Thomas

P.S: ich werde von meinem Erfolg berichten

Jupp funktioniert alles wie es soll.
Leider wiederholt die FB bei einer gedrückten Taste über den Lirc-Socket die Events nicht, so dass gar kein automatisches Scrollen möglich ist.
Aber das ist jetzt wirklich eine Eigenart des samsung-Treibers.

Danke noch mal!

Gruß
Thomas

Hallo Mitstreiter,
hab mir für heute vorgenommen die Alternativlösung von seahawk1986 zu testen und hab brav apt-get upgrade und dist-upgrade gemacht und schau „irw“ und kein prellen – der Repeat-Filter sollte ja auf 2 stehen und mindestens 3 Einträge bringen - nix.

Ist die Lösung schon im Paket dabei ?

Nicht dass ich wüsste.. An den relevanten Paketen wurde noch nichts geändert.

So, ich habe ein paar Probleme in lircd2uinput.py behoben - wer das nutzt, sollte sich die aktuelle Version von Github holen: lircd2uinput.py und nach /usr/bin/lircd2uinput.py kopieren.

Neu hinzugekommen: die Lautstärketasten reagieren schneller und die Bedienung ist durch das Beheben von zwei kleinen Bugs noch einmal deutlich flüssiger geworden.

Super danke, da bin ich schon sehr gespannt, vor dem Wo werde ich aber leider nicht zum testen kommen.

Hi Seahawk,
loggt:


rennt prima soweit der kurztest zeigt, kann es sein das der erste druck auf vol ignoriert wird?
macht nix man muss ja eh mehrfach drücken

Danke
Ulf

Quoted from "ULF"

kann es sein das der erste druck auf vol ignoriert wird?

Ja, danke für den Hinweis (meine Fernbedienung feuert so schnell, das es mir nicht direkt aufgefallen ist). Ich muss mal schauen, wie ich das am besten löse, ohne die Tastenwiederholung für die Lautstärketasten aufzugeben.

Hi alle,

ich hatte das selbe Problem, wie hier von vielen beschrieben.
Fernbedienung ist ne Harmony One, Empfaenger ist ein Samsung USB.

Der Weg von Seahawk1986 funktioniert soweit prima! Es gab keinerlei Probleme. Scheint alles zu klappen!! Vielen Dank dafuer!!

Wg dem Zusammenspiel von lircd, eventlircd gab es hier ein gutes Diagramm..

Nochmal vielen Dank..
Gruss, blogga

'Nabend,

ich habe das gerade mit einem Atric-Empfänger und einer Hauppauge FB ausprobiert. Aber egal was ich in der "/etc/init/lircd2uinput.conf" für Optionen mit übergebe, es ist recht lahm. eventlircd habe ich natürlich neu gestartet und im syslog sieht man auch, dass das Skript mit den Parametern gestartet wurde.
Die Ausgaben von "irw" und "irw /var/run/lirc/lircd.$(pidof lircd) " sind deutlich schneller.

Gruß

Hast du auch den repeat-Filter von eventlircd ausgeschaltet?
In der /etc/init/eventlircd.conf "--repeat-filter" aus den Startargumenten entfernen und den Dienst oder Rechner neu starten.

Das hatte ich natürlich vergessen.

ABER, auch wenn ich es entferne wird es ehrlich gesagt nicht besser. Vielleicht verstehe ich die Optionen auch verkehrt!? Mit welchen Optionen sollte es denn auf jeden Fall schneller werden?

Womit startest du es denn aktuell?
Es gibt den "--max-gap", der legt die Zeitspanne zwischen den ersten Tastendrücken fest (Standard 300000 µs) - wenn man den herunterdreht, hat man vom Start weg eine höhere Tastenwiederholrate. Nach Ablauf der "--min-repeats" (Standard 2 Stück) beschleunigt die Fernbedienung in per "--acceleration" (Standard 0.25 - also vier Schritte) festgelegten Stufen, bis sie den "--min-gap" (Standard 150000 µs) erreicht hat.

Da der VDR und XBMC unterschiedliche eigene Repeat-Filter besitzen, muss man da einen Kompromiss finden, damit die Tasten in XBMC nicht prellen. Falls man direkt ein konstant schnelles Ansprechen haben will, sollte man --max-gap und --min-gap gleich setzen.Bei mir funktionieren sowohl im VDR als auch in XBMC folgende Einstellungen IMHO sehr brauchbar (mit Ausnutzung der Beschleunigungsfunktion):


Falls es noch flotter gehen soll, kannst du mal die entsprechenden Tasten in die Variable "self.specialkeys" (Zeile 98 des Skripts) aufnehmen also z.B. :

Mit deinen Optionen läuft das bei mir sehr träge. Um 10 Zeilen im OSD zu durchlaufen benötigt es ca. 5 Sekunden. Also viel zu lang. Auch Werte, die um den Faktor 10 kleiner sind, helfen nicht wirklich.

Mit der Änderung in "/usr/bin/lircd2uinput.py" geht's jetzt deutlich schneller. Jetzt muss ich noch passende Werte für "--max-gap" und "--min-gap" finden.