Beiträge von TEN

    Es sagt dmesg | grep -i dvb:
    Registered IR keymap rc-dvbsky
    input: cx23885 IR (DVBSKY T982) as /devices/pci0000:00/0000:00:04.0/0000:02:00.0/rc/rc0/input5
    rc0: cx23885 IR (DVBSKY T982) as /devices/pci0000:00/0000:00:04.0/0000:02:00.0/rc/rc0


    gelöst - Fernbedienung (lirc) funktioniert nicht mehr nach Treiberinstallation für Mystique SaTiX-S2 Sky Express DUAL verweist auf inkompatible Versionen der lirc_serial.ko als mögliche Ursache, weshalb die Fernbedienung nicht erkannt wird.


    ir-keytable und sudo evtest kann ich erst prüfen, wenn ich an der Maschine bin.

    So langsam gehen mir die Ideen aus.Genau so, wie du es gemacht hast, habe ich es auch gemacht. Bei mir sind danach alle *.ko unter /lib/modules/3.13.0-39-generic/updates/dkms, keine weitere Struktur. Diesmal hattest du aber den 39er Kernel gebootet, oder ? Mein Skript baut nur für den gebooteten Kernel.

    Klar bin ich im -39, daher hatte mich ja beim dkms remove die Meldung bzgl. -36 irritiert: "Status: Before uninstall, this module version was ACTIVE on this kernel." (...der ja schon -39 war)
    Hätte mir höchstens noch vorstellen können, daß sich etwas mit dem zuerst aktiven DKMS für VirtualBox verhakt hat.
    Nach erneuten dkms remove fielen mir dann allerdings Meldungen folgender Art auf...


    # sudo dkms install "dvbsky_v4l/14.6.19"
    Creating symlink /var/lib/dkms/dvbsky_v4l/14.6.19/source ->
    /usr/src/dvbsky_v4l-14.6.19


    DKMS: add completed.


    Kernel preparation unnecessary for this kernel. Skipping...


    Building module:
    cleaning build area.....
    'make' all VER=3.13.0-39-generic...
    [...]
    si4713-i2c.ko:
    Running module version sanity check.
    Error! Module version 0.0.1 for si4713-i2c.ko
    is not newer than what is already found in kernel 3.13.0-39-generic (0.0.1).
    You may override by specifying --force.


    ... und veranlassten mich, cx2341x in /etc/modprobe.d zu blacklisten sowie cx23885.ko und tda18271.ko manuell aus /home/user/media_build-bst-13/v4l nach /lib/modules/3.13.0-39-generic/updates/dkms zu kopieren.


    And finally, nach weiterem sudo depmod && sudo reboot: :]


    # ls -l /dev/dvb
    total 0
    drwxr-xr-x 2 root root 120 Nov 21 21:11 adapter0
    drwxr-xr-x 2 root root 120 Nov 21 21:11 adapter1


    Vielen Dank für Dein DKMS und vor allem Deine umfangreiche Unterstützung zu jeder Zeit!
    (Inkl. Geduld mit den langen Kompilierzeiten meiner N54L - diese Maschine wird nachher zwecks VDR-Lasttest damit bestraft, parallel Priest und Glimmer Man aufnehmen zu müssen ;)).


    Fernbedienungsfragen habe ich ausgelagert in Mystique TeCaBiX / DVBSky LIRC - sogar inkl. Transmitter (irsend) ?

    nein, das sieht gut aus, "--all" löscht alles, was von dkms installiert wurde von allen vorhanden Kernel Versionen. Jetzt hast du wieder den Stand von vor dem Test.


    Vielleicht wäre es jetzt ganz gut, nochmals nach Herstelleranleitung zu installieren (rm vom Kernel media Verzeichnis nicht vergessen, wegen der doppelten Modules ins verschiedenen Pfaden) und es erst danach nochmals mit dkms zu versuchen. Nur um sicherzustellen, dass bei dir nicht noch was Altes irgendwo rum liegt.


    tar xzvf media_build-bst-13-140619.tar.gz
    cd media_build-bst-13
    patch <Makefile1.diff
    cd v4l
    patch <Makefile2.diff
    cd ..
    sudo make_dkms.sh


    Nach einer halben Stunde Kompilierzeit war leider keine cx23885.ko (aus media_build-bst-13/v4l) in /lib/modules/3.13.0-39-generic/updates/dkms - muß darunter noch ein Verzeichnisbaum (manuell) erstellt werden?

    Irgendwas passte da jedenfalls nicht zusammen - DKMS hatte wohl irgendeinem Relikt trotz vorangegangenem make distclean die vorige statt der gestarteten Kernelversion entnommen (dkms uninstall allerdings griff nach -39, erst dkms remove versucht sich an -36!):


    # uname -r
    3.13.0-39-generic


    # sudo dkms remove "dvbsky_v4l/14.6.19" --all
    [sudo] password for user:


    -------- Uninstall Beginning --------
    Module: dvbsky_v4l
    Version: 14.6.19
    Kernel: 3.13.0-36-generic (x86_64)
    -------------------------------------


    Status: Before uninstall, this module version was ACTIVE on this kernel.

    Ich gehe mal davon aus, du hast den aktuellen von der DVBSky Seite (140619). Das kann gut sein, dass sich da noch was mit ursprünglichen sudo make KDIR26=... nicht verträgt. Ist unter /lib/modules/$(uname -r)/updates/kernel/drivers/media überhaupt was drin ?

    Da liegt alles, was dann auch als weiteres Exemplar im dkms-Unterverzeichnis landen sollte.


    Vor sudo dkms remove "dvbsky_v4l/14.6.19" --all müht sich erst einmal das ursprünglich gestartete dkms uninstall weiterhin äußerst zäh für
    *.ko:
    - Uninstallation
    - Deleting from: /lib/modules/3.13.0-39-generic/
    rmdir: failed to remove ‘’: No such file or directory
    - Original module
    - No original module was found for this module on this kernel.
    - Use the dkms install command to reinstall any previous module version.


    Nach dkms remove steht einem erneuten Entpacken des media_build-bst-13-140619.tar.gz sowie Anwendung Deiner Patches darauf und auf den Kernel -39 wohl nichts entgegen, oder sollte man noch irgendwo Symlinks abräumen müssen?

    Mache sicherheitshalber noch einen sudo dkms remove "dvbsky_v4l/14.6.19" --all, dann ist wirklich alles wieder weg.

    Evtl. verirrt er sich aber (wie die "2 named"-Meldungen anzudeuten scheinen) noch zu den erhaltengebliebenen /lib/modules/3.13.0-39-generic/updates (ohne ./dkms) aus dem ursprünglichen sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install ?
    Kann man letzteren (KDIR26-)Pfad gefahrlos abräumen (ggf. gefolgt von evtl. notwendigem sudo depmod -a) ?

    Zitat

    Welchen mediabuild tree nimmst du ?

    Auch den media_build-bst-13, sonst hätten Deine Patches ja nicht gepasst.

    Falls du den -39er Kernel schon installiert hast, musst du nach dem booten sudo dkms install "dvbsky_v4l/14.6.19" ausführen und nochmals booten.

    Das habe ich nach den anstehenden Aufnahmen gemacht, allerdings wie schon beim manuellen Durchlauf ist /dev/dvb danach anders als im Kernel -36 leer und es endet DKMS mit:


    Interessanterweise enthält dmesg nun:

    Erneuter Aufruf bringt "Module dvbsky_v4l/14.6.19 already installed on kernel 3.13.0-39-generic/x86_64".


    Ein uninstall läuft ewig, ich probiere es danach nochmal mit Umleitung in eine Logdatei, denn evtl. hatten ja die vorangegangenen Versuche mit den erst zuletzt als Attachment funktionierenden Skripten irgendetwas zerlegt, das sich darin zeigen könnte.

    Um dies aus dem nun enger gefassten Thread http://www.vdr-portal.de/board…rten/p1219921-dvbsky-dkms auszukoppeln:


    Die IR-Fernbedienung der Tunerkarte DVBSky T982 (AKA Mystique TeCaBiX) konnte ich mit irrecord in diese /etc/lirc/lircd.conf samplen:


    Hat dazu passend jemand eine mit den DVBSky-Karten unter Ubuntu lauffähige /etc/lirc/hardware.conf (und evtl. Mapping auf die Kernel-Tasten wie KEY_UP etc.) ?
    Bedeutet die 3-polige Klinkensteckerausführung evtl. sogar, daß es sich um einen sendefähigen LIRC-Transceiver und nicht nur Empfänger handelt?

    Danke, jetzt ist er durchgelaufen. Hat nun natürlich noch Relikte vom ursprünglichen make install auf dem Kernel -36 (mal sehen wie's mit -39 und Nachfolgern wird), aber scheint alles zu passen:


    Running module version sanity check.
    - Original module
    - Multiple same named modules!
    - 2 named gspca_stk014.ko in /lib/modules/3.13.0-36-generic/
    - Installation
    - Installing to /lib/modules/3.13.0-36-generic/updates/dkms/


    depmod.....


    DKMS: install completed.


    Hat schon jemand die LIRC-Einbindung und etwaiges irsend ausgetüftelt?

    Hallo TEN,


    die Firmware ist nicht mit dabei, die muss man einmalig nach der DVBSky Anleitung installieren. Die ändert sich ja auch durch den Kernelupdate nicht. Es sowieso einfacher ggf. Fehler zu finden, wenn man zuerst mal nach Hersteller Anleitung installiert und dann testet, ob damit alles geht. Dann ist die Firmware auch gleich mit drauf.

    Klar hatte ich die erst einmal so installiert, dann nur die vielen rm -f auf Firmware-Dateien unterhalb media_build-bst-13 des make distclean bemerkt.


    Zitat

    Die cx23885.ko vom Original Kernel stört nicht, da zuerst im ../updates/... Verzeichnis nach den Modulen gesucht (und gefunden) wird.

    Das hatte bei -36 so geklappt, bei -39 dann nicht - werde ich aber nach Durchlauf Deiner DKMS-Lösung auch auf -39 nochmals testen.

    Zitat

    Die Patches aus den Code Blöcken gehen wirklich nicht, da sind Leerzeilen verschwunden. Ich habe sie durch angehängte Dateien ersetzt, die müssten jetzt funktionieren.

    Vielen Dank! Läuft nun durch bis
    make[1]: Leaving directory `/home/user/media_build-bst-13/v4l'
    ./DKMS.sh: line 26: warning: here-document at line 6 delimited by end-of-file (wanted `EOF')
    dirname: missing operand


    Die dkms.conf scheint aber erstellt worden zu sein, endend auf:
    dkms install -m dvbsky_v4l -v 14.6.19

    ersten make unter 3.13.0.36 gemacht. Das merkt sich der mediabuild tree unter v4l/.version und ignoriert deinen Parameter. Um das los zu werden, brauchst du einen make distclean.

    Danke, die hatte ich tatsächlich nicht gesehen.
    Packt make nach Deinen Patches die ganzen Firmwares wieder aus und schiebt auch die cx23885.ko des jeweils originalen Kernels wieder beiseite?

    Zitat

    Mein DKMS Vorschlag hat bei mir beim letzten Kernelupdate funktioniert. Die Treiber wurden für die neue Version automatisch beim apt-get dist-upgrade gebaut und richtig nach /lib/modules/3.13.0-39-generic/updates/dkms installiert. Nach dem reboot lief die S952 ohne manuellem Eingriff.

    Brauchen die Patches einen besonderen Parameter?
    ~/media_build-bst-13$ patch <Makefile.patch
    patching file Makefile
    patch: **** malformed patch at line 4: endif
    (bzw. bei "else" in v4l)

    Übergangslösung [...] bis die S952 direkt vom Kernel unterstützt wird. Besser den media_build Tree von DVBSky in DKMS bringen, als bei jedem Kernupdate die Treiber wieder von Hand bauen.

    Letzteres hatte ich im seit wenigen Wochen ausgelieferten Kernel versucht, musste dazu aber media_build-bst-13 neu aus dem Tarball erstellen, sonst wurde auch nach Boot in den aktuellen Kernel -39 von sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install
    weiter nur nach /lib/modules/3.13.0-36-generic installiert.
    Leider wird nach dem Reboot nicht die Version aus updates verwendet, sondern die mit dem Kernel gelieferte vorgezogen, so daß dann /dev/dvb leer bleibt:
    286852 Okt 28 15:26 3.13.0-39-generic/kernel/drivers/media/pci/cx23885/cx23885.ko
    294040 Nov 8 10:34 3.13.0-39-generic/updates/kernel/drivers/media/pci/cx23885/cx23885.ko
    Lässt sich sicher wieder manuell verbiegen, zunächst bin ich aber beim vorigen Kernel -36 geblieben, da ich meist nur per ssh aus der Ferne auf diesen VDR komme.


    Immerhin konnte ich die Fernbedienung der T982 in diese /etc/lirc/lircd.conf samplen, aus gleichem Grund aber noch nicht testen:

    Hat jemand eine mit den DVBSky-Karten unter Ubuntu lauffähige /etc/lirc/hardware.conf dazu (und evtl. Mapping auf die Kernel-Tasten wie KEY_UP etc.) ?
    Bedeutet die 3-polige Klinkensteckerausführung evtl. sogar, daß es sich um einen sendefähigen LIRC-Transceiver und nicht nur Empfänger handelt?

    Wieder einmal muß ich einen LIRC-Empfänger (v.a. für VDR) und LIRC-Sender (sog. Blaster) für verschiedenste Geräte (z.T. auf 433 MHz verlängert, von Rolläden über Verstärker bis zu RGB-LED-Beleuchtung) aufsetzen, so daß er räumlich vom PC getrennt Daten über (W)LAN-Port 8765 austauscht.


    Alte 586er-Mainboards inkl. RS232C können das noch ganz gut mit einfachster serieller Beschaltung, aber unzeitgemäßem Strom- und Platzbedarf (den man inzwischen auch der dbox2 attestieren muß, so sehr sie sich mit QAM256 müht).


    MCEUSB-Transceiver (IR-Sendediode selbst nachzurüsten) z.B. an Pogoplugs enttäuschen in der Sendereichweite und Störfestigkeit des Empfangs:
    Zahlreiche gängige Lichtquellen und auch in der Nähe befindliche Monitore sättigen allzu schnell den Empfänger (dann dauerleuchtende LED),
    Signale im Raw-Mode zu samplen und wiederzugeben scheint auch nicht ihre Stärke,
    und die Sende-LEDs wollen direkt auf ihre Empfänger geklebt werden (oder konnte schon jemand quer durch große Räume reichende IR-Booster dafür entwickeln?) - wie auch der IgorPlug oder FTDI-basierte http://www.irblaster.info/usb_blaster.html.


    http://www.irtrans.de/de/shop/lan.php etc. ist ziemlich hochpreisig, offenbar ohne lcdproc für VFDs ausreichend zu unterstützen: http://www.irtrans.de/forum/viewtopic.php?f=17&t=475


    USB IR Toy V3 scheint noch im Entstehen und ebenso wie der http://www.irdroid.com/usb-infrared-transmitter/ weiterhin nur auf Umwegen mit LIRC nutzbar.
    Kann jemand den http://www.irdroid.com/irdroid-usb-ir-transceiver/ oder http://www.usbuirt.com/order.htm (leider US$70 mit Versand) als funktionierend mit LIRC bestätigen (ab welcher Version) ?


    Was verwendet Ihr in solchen Fällen, vorzugsweise direkt von LIRC und seinen in Standardkernel gewanderten Bestandteilen vollständig unterstützt?

    noch ein Pilot. Derzeit ist man bemüht, Planungssicherheit für die Frequenzen zu erreichen. Das betrifft das zur Freigabe stehende 700Mhz Band
    Da ist jetzt die Politik gefragt ... für den 15.10.2014 vorgesehene Zuordnungsentscheidung der Ministerpräsidentenkonferenz ist Voraussetzung

    Genau da gilt es jetzt Einfluss zu nehmen, damit die verbraucherfeindliche Verschlüsselei und damit oft ein faktisches VDR-Verbot nicht endgültig zementiert wird.
    Warum sollte die Allgemeinheit diese Bereiche ausgerechnet einer elitär teuren "geschlossenen Gesellschaft" ohne angemessene Vergütung zur Verfügung stellen und damit ihren eigenen Ausschluss "sichern" ?

    Zitat von Golem

    mit und ohne Verschlüsselung ... im Kanal 42 von den Senderstandorten ... jeweils 50 kW ERP ...
    Geplant sind Programmangebote mit und ohne DRM.

    Das darf doch nicht noch länger und nun sogar terrestrisch erlaubt werden, ohne wenigstens höchste Preise (vgl. UMTS-Auktion) dafür einzufordern, daß die Öffentlichkeit zwecks Verschlüsselei zugunsten kleiner Gruppen von wichtigen Kanälen ausgesperrt wird.
    Siehe schon Kämpft um Eure VDRs!

    Hast du nach dem Update neu gestartet, sprich liefert uname -r den richtigen Kernel?

    Klar, Ubuntus 3.13.0-36-generic, auf dessen Standard3bär fiel der neue Kernel deshalb ja zurück (vgl. schon DVBSky T9580 DVB-T/T2/C and DVB-S2 Dual PCIe für die Vorversion).
    Nehme an, daß DVBskys Makefile&Co. auch insoweit unausgegoren sind, da nur dieses den Kernelwechsel nicht mitbekommt (und "make clean" einige Firmwares löscht und danach erst recht nicht kompiliert).
    Darum poste ich es, denn der nächste Kernel&Kunde kommen bestimmt und stehen dann auch vor dem Problem aus dieser out-of-tree-Entwicklung.
    Ein rm -r ...; tar xf des aufbewahrten Archivs sind dann ja schnell erledigt, und auch make install funktioniert dank Deiner Hilfe zum o.g. obskuren Parameter KDIR26.
    Hoffen wir, daß engagierte Käufer & Importeure wie in http://www.amazon.de/review/R1ISNY3CFR54W dem Hersteller auf die Sprünge helfen, damit auch die langwierigen Makes ohne DKMS bald durch Aufnahme in den Standardkernel der Vergangenheit angehören.

    müsste ... wohl doch eher folgender Befehl werden:
    sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install


    ... DKMS ist auch am Paketmanager vorbei, dafür halt recht komfortabel.


    Nach durchaus häufigen Kernel-Updates behauptet make weiterhin z.B. seit 2014-10-04 auch für -36 (deren Standardtreiber dann wieder funktionsunfähig übernimmt):
    "Kernel build directory is /lib/modules/3.13.0-35-generic/build"


    Da nach "make clean" make nur mit Error 2 endet, muß das Build-Verzeichnis gelöscht, neu angelegt und eine geschlagene Viertelstunde lang alles nochmals kompiliert werden.

    Oh, nee das ist nicht gut. Es sollte /lib/modules/3.13.0-35-generic/updates/kernel/drivers/media/pci/cx25821/cx25821.ko werden.
    Am besten nochmal rückgängig machen.

    Na ja, manuell rauslöschen bestenfalls, denn komfortabler scheint das ja nicht vorgesehen.

    Zitat

    müsste es wohl doch eher folgener Befehl werden:

    Code
    sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install

    Danke, das passte dann auch unter Ubuntu 14.04 LTS! :)

    Zitat

    DKMS ist auch am Paketmanager vorbei, dafür halt recht komfortabel.

    Halt immerhin zumindest bei Debian-Derivaten etwa für VirtualBox einigermaßen "offiziell".

    Zitat

    EDIT: Richtig so war das: Mystique SaTiX-S2 Sky PCIE alle die Treiber suchen können dies mal testen


    EDIT2: Das Problem mit cx2341 in i2c bzw. common ist dadurch entstanden, dass cx2341.c von media/i2c nach media/common verschoben wurde. Deine mitgelieferten Module sind nach dem Commit gebaut, das Treibepaket von dvbsky ist allerdings von einem Stand davor abgeleitet. Depmod sollte das aber auflösen können, auch wenn die Module sich in verschiedenen Ordnerstruktuen befinden.
    Wenn modinfo cx2341x danach immer noch nicht das richtig liefert, noch mal ein "sudo depmod -a" ausführen (auch wenn das make media-install eigentlich schon machen sollte).

    Doch, vielen Dank nochmal, klappt wie oben!
    Rudimentär und eher Beta scheint der Treiber allerdings schon; so wird die Empfangsqualität nicht reported (unmöglicher festgeklopfter Wert, siehe Attachment) und wenn das Signal mal wegbleibt oder auch einfach zu oft umgeschaltet wurde, stoppt der Stream auf den meisten "Transpondern" und berappelt sich die Karte eigentlich erst nach einem Neustart.
    Auf die Stabilität im Dauerbetrieb bin ich also gespannt.
    (Doppeltuner-Empfang von 2*DVB-C scheint ja auch noch eine offene Baustelle.)