Posts by jogek

    stimmt da was nicht?


    main -> precise -> vdr-epg-daemon -> 0.1.1-1-0yavdr0~precise
    stable-vdr -> precise -> vdr-plugin-epg2vdr -> 0.0.6-1yavdr2~precise
    testing-vdr -> precise -> vdr-plugin-epg2vdr -> 0.1.1-0yavdr0~precise


    passen main und stable überhaupt zusammen?


    Vielen Dank an den/die Entwickler von epgd und epg2vdr sowie yavdr


    Josef

    Hallo,


    zuerst mal mit modinfo ngene überprüfen, welcher Treiber geladen wird. Falls

    Code
    /lib/modules/3.2.0-38-generic/kernel/drivers/media/dvb/ngene/ngene.ko
    und nicht
    /lib/modules/3.2.0-38-generic/extra/ngene.ko
    
    
    P.S. ich habe Kernel 3.2.0-38


    Bei mir ergibt modinfo ngene


    Für den Fall, dass der Kernel Treiber geladen wird, zuerst den Kernel Treiber "blacklisten":
    Datei blacklist-ngene.conf mit der Zeile
    blacklist ngene
    unter /etc/modprobe.d/ anlegen und System neu starten. Nochmals mit modinfo ngene überprüfen, modprobe ngene, depmod -a und Neustart.
    Mehr weiss ich erst mal auch nicht


    Gruß Jogek

    s_mario


    Activy ist im Originalzustand, plane aber später Umbau mit Asus P5KPL-AM oder einem passenden ASROCK Modell.


    Ich habe inzwischen den ganzen Activy auseinander genommen und dabei festgestellt, dass vom IR-Tochterboard ein Kabel nach vorne neben das LCD-Display geführt ist. Dort ist mit Heisskleber ein IR-Sensor befestigt, mit drei Anschlusskabeln, von denen zwei unter der Isolierung keinen Kontakt mit dem Sensor hatten. Ich löte die Kabel jetzt wieder an und hoffe, dass die FB jetzt funktioniert.


    Das IR-Tochterboard ist über USB-Kabel mit dem Motherboard verbunden; ist es trotzden richtig, das keiner der PS2-Anschlüsse zwischen CPU und Rückwand direkt neben dem Netzteil mit dem Tochterboard verbunden ist? Gibt es kein Layout vom Motherboard mit Eintragungen was mit wem verbunden wird?


    Herzlichen Dank erstmal!

    gda


    zunächst an dich und deine Mitstreiter im yavdr-Projekt einen herzlichen Dank für eure vorzügliche Arbeit.


    Zum meinem Problem mit graphlcd:
    ihr benutzt sowohl beim plugin wie auch bei den graphlcd-tools die Version 0.2.0-pre1. In den graphlcd-tools (in /etc/graphlcd.conf und graphlcd-base) habe ich keinen Hinweis auf das Futaba dm140 gefunden. Ich habe deshalb die Version 0.1.6 von graphlcd-base genommen, welches den dm140 Treiber enthält und versucht, das dazu passende vdr-plugin-graphlcd zu kompilieren.


    Denkfehler???


    Zudem scheinen die Versionen 0.2.0 und 0.1.6 unterschiedliche Funktionalitäten zu haben, von denen ich nicht weiss, ob sie vom Futaba-Display unterstützt werden.


    Was meinen (geringen) Informationsstand angeht, bezog sich das auf globbers Wiki bzgl. der Activy 570.

    Hallo,


    ich bin ebenfalls Besitzer einer Activy 570 und betreibe sie mit CT-VDR7 und Yavdr. LCD-Anzeige funktioniert mit lcdproc und vdr-plugin-lcdproc. Sowohl unter Debian wie auch unter Ubuntu karmic laufen auch graphlcd-base. Leider ist es mir bislang nicht gelungen, das vdr-plugin-graphlcd unter Ubuntu zu kompilieren. Falls jemand interesse hat, kann ich ihn über meinen Stand informieren.
    Leider ist es mir bislang nicht gelungen, die mitgelieferte Fernbedienung ans "Laufen" zu bekommen. Mit Interesse habe ich unter


    http://www.vdr-wiki.de/wiki/index.php/Scaleo_E/Evi/Activy5xx


    gelesen, dass zum Funtionieren der Fernbedienung - da bei der Activy 5xx die FB nun mal Tastatursignale sendet - man eine Verbindung zwischen dem Keyboardanschluss und dem IR-Tochterboard herstellen muss.


    Eine solche Verbindung gibt es bei mir nicht. Vielleicht kann mir jemand ein Bild und die Information schicken, wo und zwischen welchen Steckerkontakten eine Verbind hergestellt werden muss.

    wastl


    Codeänderung


    Code
    if((short)vendor==(short)(device_info.vendor) && (short)product==(short)(device_info.product)


    funktioniert!


    Deklariert man die Variablen vendor und product als signed short (wie in hiddev_devinfo definiert)


    Code
    signed short vendor = 0x1509;
    signed short product = 0x925d;


    funktionierts auch ohne die Änderung


    powarman


    Danke, muss mich erst wieder an das casting in C gewöhnen.


    Grüße Josef

    wastl


    kann leider erst heute abend testen, aber:


    in hiddev_devinfo sind vendor und product als s16 (signed short) definiert. Warum aber werden beide unterschiedlich


    vendor: 1509
    product: ffff925d


    zurückgegeben?

    ich habe mir heute das git
    git clone git://projects.vdr-developer.org/vdr-plugin-graphlcd.git
    heruntergeladen.
    In /etc/graphlcd.conf steht:


    vendor: 0x1509,
    product: 0x925d

    hiddev_devinfo in dm140gink.c gibt
    vendor: 1509
    product: ffff925d


    zurück. Ändert man in graphlcd.conf product zu 0xffff925d funktioniert der Aufruf von lcdtestpattern in tools/


    weiter bin ich noch niocht!