Beiträge von nst

    Ich verstehe nicht, warum DD die Integration in den Kernel nicht selbst vorantreibt.

    Tja, frag' das bei DD an. Wenn sie wollten, würden bzw. könnten sie das tun, entweder indem sie jemanden beauftragen oder einstellen, der sich Vollzeit mit dem Treiberstack und dem DVB Subsystem ausseinandersetzt und in sinnvoller Weise das Zeugs, was in dddvb drin ist, für jedermann verfügbar macht - dann wär die dddvb Krücke gar nicht notwendig. Aber mindestens rjkm, der AFAIK damals(tm) sogar LinuxDVB mit entworfen und gepusht hat, hat Null Interesse, das anzupacken (einer der Gründe möglicherweise der Maintainer). Davon ab würde das ganze noch 'ne ganz andere Zugkraft mitbringen, würde da jemand vom Hersteller committen, verglichen mit irgendeinem Privat-Individuum... Aber es ist, wie es ist.


    Hint: Hauppauge baut auch ordentliche Multituner-TV-Karten, und da wird sich aktiv im Kernel drum gekümmert...

    Es wird nur die Cine erkannt.


    Die CI+2 Tuner wird offenbar nicht erkannt - zumindest nicht vom VDR - in LSPCI taucht sie auf.

    Code
    01:00.0 Multimedia controller: Digital Devices GmbH Device 0013

    Davon ausgehend, dass "debian stable" auf "stretch" hinausläuft: Laut Paketlisten gibts in stretch-backports 'nen vergleichsweise umfangreichen Blumenstrauss an Kernel-Images >= 4.14 (inkl. 4.16). Davon einen installieren, reboot, Karte sollte laufen, und es gibt weiterhin Updates via stretch-backports.

    Der_Pit Dein GLK-Board ist laut den Postings und Deiner Sig genau dieses hier, korrekt? Kannst Du mir kurzfristig mal die genauen Device IDs durchgeben? ('lspci', dann nochmal ein lspci auf die Bus-ID vom VGA Controller (wahrscheinlich 00:02.0): 'lspci -vvn -s00:02.0' <- den Output brauch ich) Hintergrund: Intel fixt das Problem grade und sammelt im Bug Report Infos von betroffener Hardware, und die würd' ich vom J4105 da mal mit einkippen.

    Hat sich eigentlich jemand inzwischen dieses Board zugelegt?

    *meld*


    Das Intel DRM (i915) Kernelmodul hat derzeit noch ein Problemchen mit dem HDMI-Port (kein Bild am TV/AV-Receiver beim Wechsel auf 1080p50/60), Workaround (Kernel-Images + Anleitung) für Ubuntu 18 gibts hier. Zu TV-Karten kann ich nix sagen, das Ding ist bei mir Kodi-Client (FYI, 4K HEVC-10bit bei 60FPS mit aktuellem Kodi 18 GIT Build via VAAPI funktioniert wunderbar, Deinterlacing - VAAPI-MCDI - mit 1080i/H264 oder 576i/MPEG2 bei LiveTV ist super, wüsste nicht, wo die NVIDIA-Karte, die vorher für den Zweck im Einsatz war, irgendwas besser gemacht haben sollte...).

    Für alle, die ngene-mässig noch irgendwas testen wollen: Via http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17/ gibts jetzt fertige Ubuntu Kernel .deb's, da ist alles drin (ggf. vorher auf kompatible nvidia-Binblobs/DKMS-Packages achten). Honker, da von Dir kein Feedback mehr kam - bitte am einfachsten dem Kernel-Team von Proxmox auf die Füße treten, dass die 4.17er Images bereitstellen, sofern mit media_build, media-build-dkms usw. immernoch Probleme bestehen.

    Welche Vorteile hätte ich, wenn ich meine MaxS8 gegen eine MaxSX8 tauschen würde?

    Den Gedankengang würde ich an Deiner Stelle streichen, solange Deine mxl5xx-basierte MaxS8 tut, was sie soll und keine DVB-S2X Transponder am Himmel auftauchen. Vor allem aber implementieren die Boards die Demod/Tuner-Treiber, die bei anderen Karten (u.a. MaxS8=mxl5xx, CineS2v7=stv0910+stv6111) als I2C-Client mit eigenen Treibern implementiert sind, in FPGA. Bedeutet: Jedes Update, jeder Bugfix erfordert mindestens einen FPGA Flash-Vorgang, und wenn Datenstrukturen verändert werden, passende Änderungen im (dd)Bridge-Code (anstatt eben einen Zweizeiler im I2C-Client-Treiber zu hinterlegen). Und obendrein ist jeder der Willkür der FPGA-Code-Entwickler ausgeliefert...


    Aber die Zeit wird zeigen, wie gut (oder nicht) das Modell funktioniert. Eventuell wird auch einfach der I2C-Bus aufgemacht und es fällt ein StiD135 Demodulator Treiber vom Himmel (der scheint auf den Boards aufgelötet zu sein).

    Das 4.18er Merge Window steht vor der Tür, für DD-Karten gibts eigentlich nur einen wirklich spannenden Change:

    Anders als in dddvb-0.9.33 aus dem DD GitHub Repository ist es allerdings nicht zwingend erforderlich, die FPGA-Firmware der CineS2V7/OctopusCIS2 Karten umzuflashen. Der Treiber erkennt, wenn nicht die aktuellste v1.7 im FPGA vorhanden ist und aktiviert dann die High-Bandwidth-Transponder-Unterstützung im stv0910-Demod-Treiber nicht und die Karten laufen wie gehabt. Erst wenn die Karte die passende Firmware enthält, wird die Unterstützung aktiviert bzw. der Demod entsprechend anders konfiguriert.


    Apropos FPGA-Firmware: Das Update-Thema wird für das 4.19er Window noch mal verstärkt beackert, damit das endlich auch mit dem Kernel-Treiber funktioniert.

    Hab' hier schon 'ne Custom EDID und eigene ModeLines (von der Altinstallation mit NVIDIA GT610/GF119 übernommen; die brauchte ich seinerzeit für saubere 23,976FPS), das hilft dem Teil derzeit nicht. Mal schauen, was aus dem Issue wird, evtl. ist das auch ein Firmware-Issue und braucht ein passendes Update von ASRock.


    Von dem Problem abgesehen läuft das Teil derzeit echt ordentlich und mit anständiger Performance.

    FYI: https://bugs.freedesktop.org/show_bug.cgi?id=105887


    Das J5005-ITX hat (wenig überraschend) mit Kernel 4.15 (4.15.0-20-generic aus Bionic) und 4.17rc4 dasselbe Problem. Aus eigener Beobachtung: Wenn Bild da ist, kann man problemlos "runterschalten" (also z.B. von 1920x1080@50 auf 1920x1080@24), "raufschalten" sorgt in 39 von 40 Fällen aber für "No signal" am AVR (getestet mit Kodi).


    Offtopic/Hint: Mit 'nem BluRay-Laufwerk am ersten ASMedia SATA-Port friert das OS (mehrere Distros mit mehreren Kernelversionen getestet) beim Bootvorgang während des HW-Probings sehr zuverlässig ein. Workaround: Laufwerk an den Intel SATA Ports und stattdessen zweite Platte an ASMedia. Phänomen ist mit zwei Boards aufgetreten (das erste hatte ich wegen Verdacht auf Defekt umgetauscht). Kann das (Problem mit optischem Laufwerk an ASMedia SATA) evtl. noch wer bestätigen?

    Da ich wieder alles gelöscht hatte, muss ich es komplette neu machen.


    Jetzt scheitert aber ein "./build_all.sh ../dddvb-linux-kernel/"


    Code
    ...
    ./scripts/make_kconfig.pl /lib/modules/4.15.15-1-pve/build /lib/modules/4.15.15-1-pve/build 1 1
    Preparing to compile for kernel version 4.15.15
    File not found: /lib/modules/4.15.15-1-pve/build/.config at ./scripts/make_kconfig.pl line 33, <IN> line 4.
    Makefile:382: die Regel für Ziel „stagingconfig" scheiterte

    SIeht mir irgendwie nach fehlenden Kernel-Headern aus.

    Du hast vermutlich irgendwie 'ne Mischung aus den Kernelmodulen von Deinem Proxmox Kernelimage-Paket und dem Zeugs aus media_tree/media_build gebastelt, speziell die videobuf2-Module, möglicherweise Dupletten in /lib/modules/kernelversion/kernel/, und es werden die alten Module geladen, die dann natürlich nicht zum neuen dvb-core aus media_tree passen. Du könntest nochmal versuchen, alles, was "media.ko", "videodev.ko" und "videobuf2*.ko" heisst, einfach zu löschen und dann in media_build nochmal "make install ; depmod -a" ausführen. Dann nochmal /lib/modules/kernelversion/ durchkämmen, dass die Module wieder da sind, und dann nochmal "modprobe ngene" bzw. "modprobe ddbridge".

    Das Flex-CI läuft im Moment an der Octopus-Bridge, der Versuch direkt an einer Cine S2 folgt.

    Funktioniert das Ding jetzt an der ngene-Karte? Hint: In eigenen Tests habe ich diverse Male festgestellt, dass das CI gerne mal das gesteckte ACL@One4All CAM total unmotiviert "ausgewürgt" hat und dann bis zum Neuladen des ngene-Treibers keine Reaktion mehr auf dem CAM-Slot gezeigt hat. Versprich' Dir davon also bitte nicht zuviel.


    bekomme bei Proxmox nur die Header, nicht die kompletten Sourcen. Kann es daran liegen?


    Während des Builds "beschwert" er sich auch

    Das funktioniert bei dem ganzen "normalen" Ubuntu und Debian Zeugs auch ohne installierte Kernel-Sourcen, daran wird es nicht liegen. Die Meldung kannst Du ignorieren. Wenn die Damen und Herren Proxmox nichts aussergewöhnliches paketiert haben, sollte das "eigentlich" funktionieren. Poste bitte die ganzen modinfo's (siehe ein paar Posts früher). Ich könnte mir vorstellen, dass die Herrschaften irgendwas aus dem media/ Bereich fest in das Kernel-Image reincompiled haben, und dann kannst Du das Thema mit media_build usw. vergessen.

    Du hast leider Deinen Kernellog-Auszug um möglicherweise wichtige Teile erleichtert, daher Raterunde: Wenn Du jetzt was Aktuelles aus media_tree per media_build installiert hast, kommt bei Dir wohl der cxd2099 Treiber aus staging aufgrund Prioritäten ins Gehege (zumindest sieht Dein Kernellog-Fragment etwas danach aus). Ergo:

    Code
    ### Backup machen!
    # rm -rf /lib/modules/<kver>/kernel/drivers/staging/media/
    # depmod -a
    # reboot

    Und dann schau mal, ob Du caX/secX Devicenodes findest.