[VDR4Arch] Kein digitaldevices-dvb-driver mehr (Paket enthält nix)

  • - Digital Devices unterstützt Linux offiziell gar nicht mehr: Neubau VDR - Basis ASRock Q1900M und yaVDR


    - Seitens Digital Devices wurde mir zugesichert, dass bis Ende letzten Jahres erste Änderungen für die neuen Karten in den Kernel übertragen werden. Bisher ist nichts passiert.
    Mir wurde dabei ein im DVB-Umfeld sehr bekannter Kernelentwickler genannt, dessen Commits ich seitdem verstärkt beobachte.


    - Ich weiß von einem zweiten Kernelentwickler, der Ende Sommer 2014 mit den DD Treibern aufgegeben hat.

    Entschuldigung


    darauf bezog sich mein Kommentar. Ich bin nur deshalb so verstimmt, weil sich der Mensch bei mir nicht einmal per mail gemeldet hat und ständig mit Schmutz wirft.

  • Dazu jetzt mal was aus User-Sicht:


    Unbestreitbarer Fakt ist, dass die Treiber nicht im Upstream-Kernel sind.
    Ebenso, dass Copperhead uns Arch-User die ganze Zeit lang mit selbst gebauten Paketen versorgt hat - und das unentgeltlich. Da kann mir keiner erzählen, dass er das Hersteller-seitige Development sabotiert, weil er nix besseres zu tun hat als bei jedem Kernel-Update die Pakete neu zu bauen.
    Ich weiß von einem Ubuntu-User, dass der auch immer ein extra-Paket mit dem Treiber installieren muss (zuletzt nachgefragt vor ca. 1/2 Jahr).


    Also: Es ist nicht Digital Devices, die uns End-Usern den Treiber in benutzbarer Form zur Verfügung stellt, sondern das machen Distributoren und/oder erfahrene User. Das ist das, was für mich zählt.


    Als ich gestern das Paket gebaut habe, konnte ich auch sehen, wie viele Patches da noch auf den aus hg ausgecheckten Stand draufgespielt wurden. Ich glaube jetzt mal einfach, dass die alle unverzichtbar sind. Auch wenn das Development des Treibers bei Digital Devices stattfindet, sie kriegen es ja ganz offensichtlich nicht hin, den Code so weit fit zu machen, dass er upstream gehen kann.
    Und ich habe die Hardware jetzt auch schon eine ganze Weile und muss mir das schon die Ganze Zeit mit ansehen.

  • Dummschwätzer!


    Sorry, aber dieser Müll ist einfach nicht mehr zu ertragen.


    :fressehalten

  • :modon


    Bitte kühlen Kopf bewahren, jeder kann seine Meinung äußern auch wenn sie anderen nicht gefällt oder auch auf falschen Annahmen basieren, dann muss man eben aufklären.


    Regards
    fnu

    HowTo: APT pinning

  • easyVDR, gen2vdr, MLD, yaVDR (DKMS) liefern alle Treiberpakete für die Karten, ganz ohne Diskussion, ebenso unentgeltlich in Ihrer wertvollen Freizeit. Außerdem gibt es ein Treiber-Paket (src) für die Karten auf der Herstellerseite. Wie bei vielen anderen Treibern im Linux Umfeld, muss man eben auch mal selbst bauen, sowas gehört halt auch mal dazu.


    DigitalDevice nimmt sein Produktverantwortung auch für Linux sehr ernst, engagiert Profis für die Treiber-Entwicklung, -Pflege, unterstützt unsere kleine VDR Community aktiv nach Kräften und die netten Menschen von L4M/DD sind immer sehr hilfsbereit. Das wissen glaube ich sehr viele hier.


    Daher sind Post wie von "ratman" absolut unangebracht, DigitalDevices stellt Treiber zur Verfügung!


    Das diese wie u.a. auch die für die TechnoTrend S2-6400 eben noch nicht in Kernel Upstream enthalten sind, liegt nicht an DigitalDevices, sondern eher am Prinzip LinuxTV, was für die Treiber unter der DVB API verantwortlich zeichnet.


    Regards
    fnu

    HowTo: APT pinning

  • Das Problem ist, dass man die DVB-Treiber nicht mal einfach so ergänzend zu vorhandenen Treibern bauen kann.


    Bei den (meiner Erfahrung nach wenigen) anderen Kernel-Treibern, die man selber bauen muss, sind diese im Normalfall nur eine *Ergänzung* des vorhandenen Treiber-Satzes im Kernel.


    Im DVB-Bereich werden aber wichtige Module wie "dvb-core" von Treiber-Paketen komplett ersetzt. Auch andere Module werden zwischen Paketen inkompatibel verändert.


    Ich möchte in dem Zusammenhang mal an S2-6400 + Tbs 6984 erinnern. Ist ja schön das Treiber da sind, aber das hilft dem Benutzer in diesem Thread leider nicht. Nicht jeder (auch nicht jeder Distributor!) wird mal eben zum "Kernel-Hacker" nur um zwei Karten gleichzeitig nutzen zu können!


    Ich nutze zwar erst 9 Jahre ausschließlich Linux und habe nicht in jeden Bereich Einblick gehabt, aber bisher habe ich in keinem anderen Bereich soviel Fragmentation wie im DVB-Treiber-Bereich erlebt.


    easyVDR, gen2vdr, MLD, yaVDR (DKMS) liefern alle Treiberpakete für die Karten, ganz ohne Diskussion, ebenso unentgeltlich in Ihrer wertvollen Freizeit.


    Wie oft haben die denn neue Kernel? Ich glaube die Häufigkeit ist um Längen geringer als bei der Rolling-Release-Distribution Arch Linux.


  • Sorry, wer jetzt?


    Gegenfrage: Welche der folgenden Aussagen ist richtig?

    Also: Es ist nicht Digital Devices, die uns End-Usern den Treiber in benutzbarer Form zur Verfügung stellt, sondern das machen Distributoren und/oder erfahrene User. Das ist das, was für mich zählt.


    Als ich gestern das Paket gebaut habe, konnte ich auch sehen, wie viele Patches da noch auf den aus hg ausgecheckten Stand draufgespielt wurden. Ich glaube jetzt mal einfach, dass die alle unverzichtbar sind. Auch wenn das Development des Treibers bei Digital Devices stattfindet, sie kriegen es ja ganz offensichtlich nicht hin, den Code so weit fit zu machen, dass er upstream gehen kann.
    Und ich habe die Hardware jetzt auch schon eine ganze Weile und muss mir das schon die Ganze Zeit mit ansehen.


    Nur der letzte Satz ("Und ich habe...")!


    CU
    Oliver

  • Wie oft haben die denn neue Kernel? Ich glaube die Häufigkeit ist um Längen geringer als bei der Rolling-Release-Distribution Arch Linux.

    Und das ist die Schuld von DigitalDevices?


    Ich habe unter Ubuntu etwa alle drei Monate eine neue Kernelversion, welche in den Zwischenzeiten immer wieder auch noch gepflegt werden, ich höre mich nicht jammern und meine VDRs laufen genauso.


    Regards
    fnu

    HowTo: APT pinning

  • Indirekt ja.

    Da kann ich doch nur noch mit dem Kopf schütteln und Euch raten eben Karten zu kaufen deren Treiber im Kernel sind. Die richtig Auswahl der Hardware gehört auch in die Verantwortung eines Systembetreibers.


    An sich war ich ArchLinux sehr aufgeschlossen gegenüber, aber das was Ihr hier bringt ist echt zum Abgewöhnen. DD kann weder was für Eure persönliche Entscheidung für ArchLinux, noch dafür das sich häufig die DVB API ändert auch nicht das ArchLinux DKMS nicht im Griff hat.


    Regards
    fnu

    HowTo: APT pinning

  • Da kann ich doch nur noch mit dem Kopf schütteln und Euch raten eben Karten zu kaufen deren Treiber im Kernel sind. Die richtig Auswahl der Hardware gehört auch in die Verantwortung eines Systembetreibers.

    Das ist auch bereits geschehen.

    An sich war ich ArchLinux sehr aufgeschlossen gegenüber, aber das was Ihr hier bringt ist echt zum Abgewöhnen.

    Erstmal repräsentiere ich in keiner Weise Arch Linux. Es ist eine Entscheidung die ich getroffen habe, wenn jemand anderes die Treiber für Arch Linux bereitstellen möchte, biete ich auch gerne Starthilfe an.


    Ich möchte mich in Zukunft wieder auf den VDR konzentrieren und meine Skins für Skindesigner. Ich bin es einfach Leid an Treibern herumzuhacken um sie einigermaßen mit bereits vorhandenen Kernelmodulen koexistierend zu bekommen.



    Weil du aber Arch Linux ansprichst. Öffne doch mal einen Bug bei Arch Linux und bitte um den dddvb-Treiber. Ich bin mal gespannt, was die dir da erzählen. Ich sehe mich nämlich mit einem Großteil der Arch Developer auf einer Wellenlänge, was das angeht.

  • An sich war ich ArchLinux sehr aufgeschlossen gegenüber, aber das was Ihr hier bringt ist echt zum Abgewöhnen.

    Was die beiden hier von von sich geben hat nichts mit Archlinux zu tun.

    MSI H55M-E33 |Intel Core i3 530| 4 GB RAM | TT DVB-S2 6400 | Ubuntu 12.04 | Kernel-3.5.0-28 | VDR-2.2.0 | v4l-dvb| eigene Distri.
    ProLaint: Ubuntu Server 12.04.5 auf HP ProLiant ML330 G6, Xeon E5506 2.13-GHz, 16GB ECC DDR3, Digital Devices MaxS8, Samsung 840 EVO 120GB, 4x WD Red WD30EFRX 3TB in HP P410 Raid6, Zotac GT730 1GB

  • Was die beiden hier von von sich geben hat nichts mit Archlinux zu tun.

    Natürlich, wichtigstes Argument der Protagonisten für "die Schuld" von DigitalDevices am fehlenden Kerneltreiber ist ein Grundprinzip von ArchLinx, das Rolling-Upgrade.


    Wie oft haben die denn neue Kernel? Ich glaube die Häufigkeit ist um Längen geringer als bei der Rolling-Release-Distribution Arch Linux.


    Regards
    fnu

    HowTo: APT pinning

  • Bitte genau lesen, ich kritisiere gar nichts an ArchLinux, ich kritisiere Euch.


    DD kann weder was für Eure persönliche Entscheidung für ArchLinux, ...


    Regards
    fnu

    HowTo: APT pinning

  • Wie ich es dir bereits gesagt habe. Geh auf https://bugs.archlinux.org/ und fordere die Änderung am Kernel Paket Treiberänderungen. Ich weiß jetzt schon was dort als Antwort kommt.
    Wenn der entsprechende Entwickler gut gelaunt ist erklärt er dir vielleicht auch was monolithischer Kernel bedeutet.


    Ich möchte das jetzt auch nicht weiter in die Länge ziehen. Ich habe gesagt, was ich sagen wollte. Die einen sind meiner Meinung, die anderen nicht. Was solls... Man sieht sich in einem anderen Thread.

  • Das Problem ist, dass man die DVB-Treiber nicht mal einfach so ergänzend zu vorhandenen Treibern bauen kann.


    Bei den (meiner Erfahrung nach wenigen) anderen Kernel-Treibern, die man selber bauen muss, sind diese im Normalfall nur eine *Ergänzung* des vorhandenen Treiber-Satzes im Kernel.


    Das funktioniert nur, falls die Kerneltreiber alle notwendigen Basisfunktionen bereitstellen, die der externe Treiber braucht. Da dies nicht der Fall ist, werden...


    Quote


    Im DVB-Bereich werden aber wichtige Module wie "dvb-core" von Treiber-Paketen komplett ersetzt. Auch andere Module werden zwischen Paketen inkompatibel verändert.


    Ich möchte in dem Zusammenhang mal an S2-6400 + Tbs 6984 erinnern. Ist ja schön das Treiber da sind, aber das hilft dem Benutzer in diesem Thread leider nicht. Nicht jeder (auch nicht jeder Distributor!) wird mal eben zum "Kernel-Hacker" nur um zwei Karten gleichzeitig nutzen zu können!


    Ich habe dort skizziert, was gemacht werden müßte.


    Quote


    Ich nutze zwar erst 9 Jahre ausschließlich Linux und habe nicht in jeden Bereich Einblick gehabt, aber bisher habe ich in keinem anderen Bereich soviel Fragmentation wie im DVB-Treiber-Bereich erlebt.


    Liegt imho daran, dass kaum einer mehr Lust hat, sich den Trouble mit linux-media an zu tun.


    Quote

    Wie oft haben die denn neue Kernel? Ich glaube die Häufigkeit ist um Längen geringer als bei der Rolling-Release-Distribution Arch Linux.


    Jetzt lasst mal die Kirche im Dorf. Auf meinem - schnellen, aber bestimmt nicht furchtbar schnellen - System baut media_build_experimental in weniger als 2,5 Minuten. Da kann mir keiner erzählen, dass das Maintainen eines Pakets ein Riesenaufwand bedeutet. In dieser Zeit kann man nicht einmal einen Kaffee holen...


    Man darf auch nicht vergessen, dass man dadurch für alle Kernelversionen von 2.6.32 bis z.Zt. 3.18 immer die gleichen aktuellen Treiber zur Verfügung hat. Bugfixes gibt es i.d.R. sehr schnell. Das alles gibt es bei Kerneltreibern nicht.


    CU
    Oliver


  • Das funktioniert nur, falls die Kerneltreiber alle notwendigen Basisfunktionen bereitstellen, die der externe Treiber braucht. Da dies nicht der Fall ist, werden...


    Copperhead hat zeitweise die Treiber gegen das bestehende dvbcore gebaut. Ja, es wurden dafür Funktionen rausgeworfen, aber es hat sich nie jemand über fehlende Funktionen beschwert. Können also jetzt nicht so brennend wichtig sein. Außerdem kann man auch dafür sorgen, dass die Kerneltreiber die nötigen "Basisfunktionen" bereitstellen...


    Quote


    Liegt imho daran, dass kaum einer mehr Lust hat, sich den Trouble mit linux-media an zu tun.


    Welcher "Trouble"? DVBSky hat es schließlich auch geschafft die Treiber in den Kernel zu kriegen. Hier wird immer so hingestellt als wäre es gänzlich unmöglich einen Treiber in den Kernel zu kriegen. Das ist nachweißlich nicht so.


    Ich hätte aber ein Argument für die Hersteller, das für den Treiber im Kernel spricht: Eventuelle inkompatible Änderungen an der internen API werden, ohne das der Hersteller nochmal ran muss, üblicherweise für alle betroffenen Module direkt von den Kernel-Entwicklern umgesetzt.