Beiträge von 7of9

    Also ich Habe diese Konfiguration mit einem easyvdr 0.8 und einer SuSE 11.2-64Bit am laufen. Die Distri ist eigentlich egal wenn der Kernel >= 2.6.28 ist. Der knackpunkt ist, du brauchst ein Firmwarefile namens dvb-usb-dw2102.fw. Dies ist nirgends erhaltlich und in keiner distri vorhanden.


    Um es zu erzeugen brauchst du die Datei usb_0064.SYS von der orginal cd
    und mit dem kommando


    dd if=usb_0064.SYS of=dvb-usb-dw2102.fw bs=1 count=8192 skip=83296


    kannst du es erstellen.


    Gruss Bernd

    (Der patch bei codeka.com), der korrekte weg wäre das 0036 device als HID device über input output reports anzusprechen, wozu nicht einmal ein Kernelmodul erforderlich ist, aber soweit ich mich an die entpoint Struktur erinnere, würde diese Methode auch bei dem VFD device funktionieren.


    In diesem Fall ist nur vorraussetzung daß das imon modul vor dem Hid modul geladen wird. Im zweifelsfall also" rmmod hiddevice; modprobe imon; modprobe hiddevice"


    Dies ist in der Tat der Weg, auf dem ich versucht habe das Modul zum Test zu ändern, bevor ich stinkesauer auf soundgraph wurde.


    Also, nicht aufgeben, es besteht immer Hoffnung!

    Sorry, ich will dich nicht entmutigen, aber du wirst wohl kaum eine Lösung finden.
    Die neuen VFD displays mit der id 0036 geben sich als (h)uman (i)nterface (d)evices zu erkennen. Damit muss der datentransfer ueber input-output reports erfolgen. Die gute Nachricht dabei ist, die Fernbedienung kriegst du out of the box zum laufen, betrachte sie einfach als tastatur und mouse, und passe lircd.conf dementsprechend an. (bei mir lirc.0.8.1).
    Die schlechte nachricht ist: Trotz patch der sourcen (und nein, einfach die ID 0036 aufnehmen reicht nicht.) läuft das display nicht. Selbst wenn der treiber gezwungen wird zu laden, Mit rmmod usbhid und gepatchten sourcen) es ist kein "output endpoint" mehr vorhanden. Das heist, die alte software kannst du vergessen.
    Also, Ich habe demendsprechende Linux Treiber fuer verschiedene Firmen schon geschrieben, und aufgrund meiner Erfahrung kann ich dir sagen, Die benötigte Software ist unkomplizierter als das Orginal, das die URB's von Hand zusammenstelllt, aber sie gibt es (noch) nicht.
    Da, wie du selbst schon festgestellt hasst, die Linux Unterstüttzung von Soundgraph sehr zu wunschen übrigläßt, war meine Lösung, das zusammengebaute Gerat als Windooze HTPC zu verkaufen.


    Fazit: Die benotigte Software ist relativ unkompliziert, aber da Soundgraph mich verärgert hat, wird die Software definitiv nicht von mir kommen, da ich die dementsprechende Büchse losgeworden bin.


    Mea Culpa!


    Bernd

    @ stolzi
    Zwar hat das nichts mit deinem Fehler zu tun, aber folgender tipp.
    Du arbeitest mit einer SuSE, da wird automatisch ein /dev/input/ir link erzeugt.
    also DEVICE=/dev/input/ir genuegt vollends.


    Zu deinem Fehler: Du verwendest vermutlich eine ältere SuSE. erst bei einer SuSE 10.2
    ist ein Kernel > 2.6.17 enthalten.
    Am einfachsten ist einen Kernel 2.6.18 oder groesser zu verwenden.
    (Das Ding gibt sich als Maus zu erkennen und ältere Kernel reagiern dann auf die Keyboardevents nicht)


    Gruss, Bernd

    baustelle
    'tschuldige, dies war kein vorwurf. es ist nur so dass diese fernbediening verbreiteter ist als der hid empfanger. ich habe z.b. 6 dieser fernbedienungen hier herumliegen. dazu gehoeren 2 hid empfanger 2 serielle empfanger und zwei andere empfanger.technisat liefert nämlich auch mit oem produkten (z.b. von technotrend) diese fernbedienung aus. ich wollte das nur klarstellen.


    GBruno
    Um es nochmal zu verdeutlichen.
    die anlernphase kommt immer dann, wenn eine ferbedienung erkannt wird, fuer die keine konfiguration vorhanden ist. Wenn deine fernbedienung funktioniert und trotzdem eine anlernphase erfolgt hasst du eben 2 fernbedienungen aktiviert.
    Da ich annehme das du nicht 2 parameter im remoteplugin vervendest (also z.b. -P remote -i /dev/input/ev... -l /var/run/lircd ... ) hasst du vermutlich den native lirc client des vdr am laufen.
    ueberpruef mal deinen vdr aufruf!
    Und komm mir nicht mit "das geht doch gar nicht". Ich habe bei einer kiste mit nexus gleichzeitig eine imon-pad und eine hauppauge fernbedienung am laufen.


    Und Verdammt noch mal, breches nicht immer ab, sondern suche welches device nicht konfiguriert ist. Es köennte ja auch einfach von der tastaur kommen, wenn du zb das softdevice oder xine plugin verwendest!!!!!!!!!!! Und dann willst du diese konfiguration!!!!!!


    Gruß Bernd

    Zitat

    Original von baustelle
    Das mit den .conf-Files ist so eine Sache, woher soll jemand denn wissen das die von Lirc kommende Datei nur für die serielle Schnittestelle gedacht ist, steht in den Kommentaren ja nicht drin! Außerdem wurde in einigen Foren (ob auch hier weiß ich nicht) explizit darauf hingewiesen das diese Version mit dem USB-Dongle funktioniert!


    Also an alle die die TTS35AI mit USB haben, nehmt die conf von 7of9


    An alle. VORSICHT, dies stimmt so nicht, dies trifft nur fuer den HID empfaenger zu


    der usb ir empfanger der z.b in diesem thread beschrieben wird
    [gelöst] Technotrend USB IR Empfänger
    mit der usb id 0x0b48:0x2003 ist kein hid device sondern verhaelt sich vielmehr ähnlich wie ein serieller empfänger.
    in diesem fall stimmt also die lircd.conf aus dem lirc!

    GBruno
    Also, der aufruf ist prinzipiell korrekt (-P remote -i ... fuer inputdevices, -P remote -l ...
    fuer lirc... . (Der remoteempfaenger der nexus s ist ein inputdevice).
    allerdings sollte, wenn du eine funktionierende remote.conf hasst, die anlernphase des vdr nicht meht stattfinden.
    Also: entweder ist deine remote.conf falsch (sie hat z.B nichts mit lirc zu tun, in deiner konfig ist lirc nicht noetig) ,
    Die Nexus sitzt nicht auf dev/input/event5 (Unwahrscheinlich da du "auto" getestet hast,
    dies funktioniert bei einer nexus immer)


    oder, am wahrscheinlichsten, du hasst keine keymap geladen.
    fuer die nexus muss mit av7110_loadkeys eine zur fernbedienung passende rc5 datei geladen werden, nachdem die nexus Kernelmodule geladen wurden.
    Hier in diesem thread habe ich einige configdateien hochgeladen.


    vdr und remote plugin mit TT-S2300 interner IR-Port


    Es sind u.a rc5 dateien fuer sämtliche hauppauge remotes drin.
    wenn du nicht als zweitkarte eine nova se2 drinhasst, gibt es eigentlich keine anderen fehlermöglichkeiten


    Nachtrag, ich habe zuerst deinen beitrag zu fluechtig gelesen.
    es gibt doch immer wieder fehler, die ich mir nicht vorstellen kann.


    also:
    1. plugin.remote.conf - Oh-ooh, - sie muss! remote.conf heisen
    2. /etc/vdr/plugins/remote.conf geht auch nicht out of the box, sie muss entweder im videoverzeichnis stehen oder du musst vdr mit der option -c /etc/vdr/plugins starten


    Allerdings sollte dies nicht zu einem Fehler fuehren da der vdr dann in der anlernphase eine korrekte remote.conf erstellen wuerde. Somit warst du entweder zu ungeduldig und hasst diese konfiguration einfach nicht ausgefuhrt, oder es ist eben keine keymap vorhanden. (s.o.)

    da hasst du wohl ein problem im initsystem.
    die files unter /dev/input werden in der reihenfolge vergeben, in der die inputdevices konfiguriert werden


    aber keine sorge, wenn du beim vdrstart die usbmodule entlaeds und anschleisend wieder laedst, sollte erstens der dongel erkannt werden und zweitens sich das device nicht mehr andern


    also z.b:
    rmmod usbhid
    rmmod ehci_hcd
    rmmod ohci_hcd
    rmmod uhci_hcd
    rmmod usbcore
    sleep 2
    modprobe usbhid


    sollte sich das device trotzdem noch aendern (du hasst z.B eine usb tastatur oder maus,die manchmal steckt und manchmal nicht) musst du eben das /proc/bus/input/devices file parsen und dann dynamisch einen link auf z.B /dev/input/ir anlegen (Weierfuehrende informationen sind mit man grep od er info sed zu erhalten :) )


    Im uebrigen ist die konfig datei im lirc vollkommen korrekt, sie ist jedoch fuer serielle emplanger. Bei mir sind ja auch zwei voellig unterschiedliche dateien drin .die .rc5 datei ist fuer av7110 enpfaenger und die lirc.conf fuer den hid empfaenger. Die fernbedienung liefert zwar immer den gleichen code, unterschiedliche empfaenger werten sie jedoch unterschiedlich aus. der hid empfanger ist dabei die beschissenste wahl, da er nicht alle codes der fernbedienung versteht und keinen repeat unterstuetzt. aber wie schon gesagt, er reicht trotzdem noch aus.

    falsches lircd.conf ? falscher socket?


    Ich fuehre es dir hier mal schritt für schritt vor


    also:
    bei mir sieht /proc/bus/input/devices folgendermassen aus


    I: Bus=0003 Vendor=147a Product=e02d Version=0005
    N: Name="USB IR Receiver USB IR Receiver"
    P: Phys=usb-0000:00:0b.0-4/input0
    S: Sysfs=/class/input/input8
    H: Handlers=kbd event7
    B: EV=10000b
    B: KEY=e080ffdf 1cfffff ffffffff fffffffe
    B: ABS=300 0


    jetzt starte ich lirc (zum test nicht als daemon, damit ich fehlermeldungen sehe) :


    lircd -p 666 -n -H dev/input -d /dev/input/event7 /etc/lircd.conf.technisat-usb-dongle
    und erhalte die ausgabe: lircd-0.8.0[4795]: lircd(userspace) ready (4795 ist nur die prozessid und ist zufällig)


    jetzt muss die fernbedienung in allen konsolen noch als normale usb-tastatur funktionieren


    wenn ich jetzt in einer anderen konsole irw starte
    bekomme ich folgende ausgabe:
    lircd-0.8.0[4795]: accepted new client on /var/run/lirc/lircd
    lircd-0.8.0[4795]: initializing '/dev/input/event7'
    (dies ist eine suse daher ist ist der lirc socket unter /var/run/lirc/lircd und nicht unter /dev/lircd wie bei dir)
    jetzt darf die fernbedienung nicht mehr als tastatur funktionieren, lirc hat sie sich jetzt gegrabscht (Sie soll schlieslich unabhängig von einer konsole funktionieren)


    in der konsole in der ich irw gestartet habe erhalte ich wenn ich tasten auf der fernbedienung druecke dann die folgende ausgabe
    0000000080010067 00 UP Technisat_USB_HID_Dongle
    000000008001006c 00 DOWN Technisat_USB_HID_Dongle
    000000008001006a 00 RIGHT Technisat_USB_HID_Dongle
    0000000080010069 00 LEFT Technisat_USB_HID_Dongle
    000000008001001c 00 OK Technisat_USB_HID_Dongle
    0000000080010032 00 MUTE Technisat_USB_HID_Dongle
    0000000080010002 00 1 Technisat_USB_HID_Dongle
    0000000080010003 00 2 Technisat_USB_HID_Dongle
    0000000080010004 00 3 Technisat_USB_HID_Dongle


    wenn ich irw jetzt abbreche erhalte ich in der konsole in der lircd gestartet wurde:
    lircd-0.8.0[4795]: removed client
    lircd-0.8.0[4795]: closing '/dev/input/event7'
    und die fernbedienung funktioniert wieder als usb tastatur.

    8.0 reicht völlig aus
    und wer sagt, das irrecord nicht funktioniert, es sagt doch nur dass es die pause zweischen dem autorepeat nicht erkennen kann, was auch schwer ist wenn kein autorepeat vorhanden ist. Schliesslich ist diese konfiguration auch mit irrecord entstanden.


    zum verwenden von irrecord mit dem dongle gibt es zwei Loesungen.
    1. RTFM
    2. Heisser Daumen :)

    1. p 666 heist zugriff fuer jeden user
    2. wass willst du mit irrecord?
    wie ware es mit irw? du hasst doch ein lirc konfigfile !


    Nachtrag zur info: Der fehler bei irrecord kommt daher dass der dongel kein autorepeat unterstuetzt.

    Soweit ich weiss ist 2.6.18 groesser als 2.6.17 ;)


    also wenn der dongle als usb keyboard erkannt wird - perfekt !


    jetzt musst du nur noch lirc mit dev/input treiber starten und schon passen die configfiles


    also z.B.
    lircd -p 666 -H dev/input -d /dev/input/event3
    (wenn event3 das device fuer den dongle ist.)


    zu den tasten:


    prog +/- und lautstarke+/- haben die gleichen codes wie die pfeiltasten und sind damit unbrauchbar
    die drei unbeschrifteten tasten ganz unten rechts sind ohne funktion.


    zusatzlich versteht der usb dongle leider auch die power taste und die taste ganz unten links nicht, deswegen verwende ich andere empfanger. Jedoch reicht es fuer einen vdr trotzdem voellig aus. in meiner konfig ist dann vol+/vol- auf den Tasten stop und txt


    Nachtrag: ja das verstehi ich als out of the box ! .-)
    Nicht out of the box sieht so aus:
    in den kernelsourcen den legacy usb bootprotokolltreiber so abzuändern dass er auf die usbid des dongels reagiert und die keyevents weiterleitet. dann den treiber in die initrd aufnehmen damit er vor dem standard hid modul geladen wird.

    Immer diese DAU`s :-;


    Fuer das susesystem muss natuerlich
    # Provides: lokales
    in
    # Provides: vdr
    geaendert werden wenn du die datei "vdr" nennst


    ausserdem musst du die aenderung ueber yast -> system -> runlevel-editor -> vdr aktivieren
    um sie in die interne datenbank aufnehmen
    oder gib in einer textconsole "insserv -d /etc/init.d/vdr" ein


    Die Start und kill links musst du nicht von hand anlegen, dies geschieht automatisch anhand der informationen im file.


    ausserdem empfehle ich die zeile
    /vdr/runvdr &
    in
    /vdr/runvdr > /var/log/vdr.log 2>&1 &
    zum test zu aendern. Dann hasst du ein logfile.


    zum lirc: dass kann gar nicht sein!!! (:-; ok, i'm kiddin') die einzige lirc version die unter suse 10.2 ohne probleme lauft, wenn sie kompiliert wird ist 8.0, und die ist eh schon vorhanden.
    dann ist der einzige unterschied dass bei SuSE die devicefiles unter /var/run/lirc/lircd statt unter /dev/lircd zu finden sind.


    Ich selbst verwende lirc 8.1 da ich die sourcen geäendert habe um die dynamische maus beschleunigung einer imon Pad fernbedienung zu implementiern. und 8.1 lauft definitiv nicht mit einer suse10,2 ohne den kernel neu zu kompilieren.


    also : obwohl lirc 8.0 unter suse 10.2 zu compilieren ist, was solls ? die seriellen treiber in suse 10.2 sind schon perfekt. und "-P remote -l /dev/lircd" wirst du ja wohl noch in "-P remote -l /var/run/lirc/lircd" aendern koennen


    Gruss
    Bernd

    Leider habe ich noch einen Fehler entdeckt
    /usr/local/sbin/lircd geht nicht
    im suse kernel ist lirc enthalten und vertraegt sich mit einem selbstkompilierten lirc nicht
    also entweder den kernel mit deaktiviertem lirc neu kompilieren und lirc module unter /lib/modules/2.6.18 ... loeschen, oder lirc von suse verwenden
    hier ein startscript das mit deinem vdr und suse lirc tun muesste


    #!/bin/sh
    # Start/stop vdr
    #
    ### BEGIN INIT INFO
    # Provides: lokales
    # Required-Start: $dvb $network $hal $cron $network $local_fs
    # Should-Start: $ALL
    # Required-Stop:
    # X-UnitedLinux-Should-Stop:
    # Default-Start: 3 5
    # Default-Stop: 0 1 2 6
    # Short-Description: lokale Dienste
    # Description: Mainly start multimedia funktions
    #
    ### END INIT INFO
    #
    # Shell functions sourced from /etc/rc.status:
    # rc_check check and set local and overall rc status
    # rc_status check and set local and overall rc status
    # rc_status -v ditto but be verbose in local rc status
    # rc_status -v -r ditto and clear the local rc status
    # rc_status -s display "skipped" and exit with status 3
    # rc_status -u display "unused" and exit with status 3
    # rc_failed set local and overall rc status to failed
    # rc_failed <num> set local and overall rc status to <num>
    # rc_reset clear local rc status (overall remains)
    # rc_exit exit appropriate to overall rc status
    # rc_active checks whether a service is activated by symlinks
    # rc_splash arg sets the boot splash screen to arg (if active)
    #
    . /etc/rc.status
    #
    case "$1" in
    start) echo -n "Starting vdr"
    setserial /dev/ttyS0 uart none
    /sbin/modprobe lirc_serial irq=4 io=0x3f8
    /usr/sbin/lircd -p 666 -H default
    /vdr/runvdr &
    echo "."
    ;;
    stop) echo -n "Stopping "
    /usr/bin/killall -q -KILL "runvdr"
    /usr/bin/killall -q -TERM "vdr"
    /usr/bin/killall -q -TERM "vdradmind.pl"
    killproc -TERM /usr/bin/irexec
    killproc -TERM /usr/sbin/lircmd
    killproc -TERM /usr/sbin/lircd
    /sbin/rmmod lirc_serial
    /sbin/rmmod lirc_dev
    echo "."
    ;;
    restart) echo -n "Restarting"
    $0 stop
    $0 start
    echo "."
    ;;
    *) echo "Usage: $0 start|stop|restart"
    exit 1
    ;;
    esac
    rc_exit

    UUps kleiner fehler bei mir:
    als script gehoeren noch ein paar escape sequenzen rein
    auserdem habt ihr vermutlich keinen pcscleser am laufen
    also die zeilen



    # Required-Start: $dvb $network $hal $cron $pcscd $network $local_fs
    # Should-Start: $ALL


    durch


    # Required-Start: \$dvb \$network \$hal \$cron \$network \$local_fs
    # Should-Start: \$ALL


    ersetzen

    2 Fehler:
    1. ich nehme an, default runlevel ist 5 und nicht 3
    2. so einfach ist ein startskript in suse nicht


    hier ein shellscript das ein korrektes initskript erzeugt und aktiviert (yast aufruf nicht mehr noetig) ersetze einfach einen der lokales aufrufe durch einen aufruf deines scripts



    #!/bin/sh
    #


    cat > /etc/init.d/lokales << EOF
    #!/bin/sh
    # Start/stop local services
    #
    ### BEGIN INIT INFO
    # Provides: lokales
    # Required-Start: $dvb $network $hal $cron $pcscd $network $local_fs
    # Should-Start: $ALL
    # Required-Stop:
    # X-UnitedLinux-Should-Stop:
    # Default-Start: 3 5
    # Default-Stop: 0 1 2 6
    # Short-Description: lokale Dienste
    # Description: Mainly start multimedia funktions
    #
    ### END INIT INFO
    #
    # Shell functions sourced from /etc/rc.status:
    # rc_check check and set local and overall rc status
    # rc_status check and set local and overall rc status
    # rc_status -v ditto but be verbose in local rc status
    # rc_status -v -r ditto and clear the local rc status
    # rc_status -s display "skipped" and exit with status 3
    # rc_status -u display "unused" and exit with status 3
    # rc_failed set local and overall rc status to failed
    # rc_failed <num> set local and overall rc status to <num>
    # rc_reset clear local rc status (overall remains)
    # rc_exit exit appropriate to overall rc status
    # rc_active checks whether a service is activated by symlinks
    # rc_splash arg sets the boot splash screen to arg (if active)
    #
    . /etc/rc.status
    #
    case "\$1" in
    start) echo -n "Starting "
    if [ -e /usr/local/sbin/lokales ] ; then
    /usr/local/sbin/lokales start
    fi
    if [ -e /home/data/sbin/lokales ] ; then
    /home/data/sbin/lokales start
    fi
    if [ -e /usr/local/vdr/scripts/init.d/lokales ] ; then
    /usr/local/vdr/scripts/init.d/lokales start
    fi
    echo "."
    ;;
    stop) echo -n "Stopping "
    if [ -e /usr/local/vdr/scripts/init.d/lokales ] ; then
    /usr/local/vdr/scripts/init.d/lokales stop
    fi
    if [ -e /home/data/sbin/lokales ] ; then
    /home/data/sbin/lokales stop
    fi
    if [ -e /usr/local/sbin/lokales ] ; then
    /usr/local/sbin/lokales stop
    fi
    echo "."
    ;;
    restart) echo -n "Restarting"
    \$0 stop
    \$0 start
    echo "."
    ;;
    *) echo "Usage: \$0 start|stop|restart"
    exit 1
    ;;
    esac
    rc_exit
    EOF


    chmod +x /etc/init.d/lokales


    insserv -d /etc/init.d/lokales


    /etc/init.d/lokales start

    Ich gehe davon aus dass die include pfade nicht stimmen.
    Die daten unter /usr/include/linux sind naemlich unbrauchbar, um einen vdr zu kompilieren


    Falls dvb treiber aus dem kernel verwendet werden sollen ist folgendes auszufuehren:
    im linux verzeichnis
    make oldconfig ; make prepare


    im parent directory der vdr sourcen falls der kernel nicht selbst kompiliert wurde.
    mkdir DVB
    ln -s /lib/modules/`uname -r`/source/include/linux DVB/linux


    wurde der kernel bereits kompiliert und installiert wurde stimmt der build link.
    dann geht: ln -s /lib/modules/`uname -r`/build/include/linux DVB/linux


    Wenn ich linuxtv treiber verwende mache ich das mit folgendem script:
    #!/bin/sh
    #V4L=v4l20060115
    #V4L=v4l20060717
    V4L=v4l20061209


    rm -Rf DVB
    mkdir DVB
    ln -s `pwd`/$V4L/linux/include/linux DVB/linux
    #ln -s /lib/modules/`uname -r`/build/include/linux DVB/linux


    cd $V4L
    make distclean
    make
    make install
    make clean
    cd ..


    noch ein tipp: wird lirc selbst kompiliert !!! muss !!! lirc im kernel deaktiviert werden


    als anhang : verschiedene lirc rc5 und remote.conf dateien von mir. (die Hauppauge daten sind dabei)

    Tja, normalerweise wurde ich euch ein RTFM an den Kopf werfen.
    Aber da der usb dongel einen Fehler hat,(Er benutzt die zwar die Klasse fur HID, jedoch die subklasse fuer mouse) hier ein paar Tipps.
    Er funktioniert erst bei Kerneln > 2.6.17 out of the box. ein patch von lirc ist jedoch unnötig


    Dateien und konfigurationen im anhang:


    lircd.conf.technisat-usb dongle: wie der name sagt,
    remote.conf.lirc.technisat_tts35ai : die dazu passende vdr remote.conf Datei


    falls Ihr wie ich jedich den remoteempfaenger einer hauppauge ff karte verwendet:
    technisat_tts35ai.rc5 : die passende rc5 datei fuer av7110-loadkeys
    remote.conf.rc5.technisat_tts35ai : die dazu passende remote.conf


    Und fuer ganz Faule: remote : dies ist ein skript, das auf einer opensuse 10.2 den ir_Empfanger automatisch konfiguriert