Possible removal of saa7146 and ttpci drivers from kernel tree

  • Das mit der Ahnung der Leute von linux-media ist so eine Sache. Auch dass die fraglichen DVB-Karten einen Marktanteil > 50 % hatten, ist so eine Sache, und hängt IMHO damit zusammen. Wenn ich es richtig sehe, gilt das mit dem Marktanteil nur für Europa, die meisten der linux-media Entwickler sind aber keine Europäer. Und anderswo, vor allem in USA, sind DVB-Karten nicht so sehr verbreitet - und wenn, dann nicht die meisten der hier diskutierten. Daher denke ich, dass Hans als Niederländer da schnell drauf eingegangen ist, weil er eben Europäer ist und DVB kennen wird. Und dass genau deswegen die anderen eher unwillig sind, weil sie das Zeug weder kennen noch nutzen.

    Das mit dem "großen Distributor" mag sein, wobei das ja erkennbar ein privates Statement war und nicht eine Meinung des Distributors widerspiegelte.


    Aber was machen wir nun?


    Sollen wir einfach in der Mailingliste sowas schreiben wie

    "What about the drivers for the full featured DVB cards like the <replace here>? Are you planning to also keep them, or will they get removed in the near future? There are some users in Germany, that would have to replace their DVB cards or even their motherboard in order to get back a working DVB environment."


    CC an Sören und evtl. SHF?

  • S:oren: Danke für die Geduld.

    Ich hatte den Kern des Problems übersehen, obwohl er eigentlich offensichtlich ist :wand .

    Das selbe nochmal fuer die enigma2-Leute, da kenne ich mich aber nicht aus.

    Da die an den FFs eher nicht interessiert sind, wird es irgend ein Teil von der API sein, was raus fliegen würde.

    Ich schätze deren closedsource-Trieber bauen daraus auf? Ist aber letztlich egal ...


    Die brauchen also einen Kernel, der mit diesen 3 Header-Dateien gebaut wurde. Gleiches gilt auch für die FFs.

    Das heisst einfach im Nachhinein die Treiber bauen, wie das bei vielen Budget-Karten üblich ist, geht also nicht.

    Eigentlich logisch, ich hatte es nur schlicht nicht realisiert.


    Für die SAA7146 Budget-Karten wäre DKMS eine Option, für die FF aber nicht. (Zumindest, wenn man den Decoder und das OSD nutzen will.)


    Eine Möglichkeit das zu umgehen, also ohne jedes mal den Kernel neu zu kompilieren, gibt es wohl nicht?



    Wenn ich es richtig sehe, gilt das mit dem Marktanteil nur für Europa

    Meine Schätzung bezog sich auf alle insgesamt verkauften DVB-Karten mit PCI.

    Grundlage ist meine persönliche Marktbeobachtung/Erinnerung, also primär Deutschland.

    Da die Produkte aber meist Europaweit vertrieben wurden, sollte es auch für Europa passen, denke ich.

    Anfangs haben doch eigentlich alle nur umgelabelte TT-Karten verkauft, oder täusche ich mich da? Selbst die grossen Marken wie Hauppauge. Da müssen ziemliche Mengen verkauft worden sein.


    Den DVB-Markt in Übersee (zB. Australien) kann ich nicht einschätzen.

    USB, PCIe usw. Karten sind natürlich nicht eingeschlossen.

    die meisten der linux-media Entwickler sind aber keine Europäer. Und anderswo, vor allem in USA, sind DVB-Karten nicht so sehr verbreitet

    In den USA, Brasilien und Japan gibt es kein DVB.

    Und wenn das Linuxtv-Wiki stimmt, gibt es mit deren Standards (ATSC, ISDB) gibt es keine einzige Karte mit SAA7146.


    Ausser bei DVB-Karten ist der SAA7146 anscheinend völlig bedeutungslos.


    Aber was machen wir nun?

    Ich werde jedenfalls werde bezgl. FF noch mal nachfragen. Und auch auf die spezielle Problematik eingehen, nachdem ich sie verstanden habe.

    Wenn der FF-Treiber aus dem Kernel fliegt wird es nämlich nervig.

    Vor dem WE wird das aber nichts, fürs englisch schreiben brauche ich eine ruhige Minute.


    Sollen wir einfach in der Mailingliste sowas schreiben wie

    [...]

    Keine Ahnung was da Sinn macht.


    Was soll eigentlich mit den Budget-Karten mit Analogteil passieren? Das sind viele der DVB-C Karten.

    Wenn ich es richtig interpretiere, haben die auch die gleichen Abhängigkeiten, wie die reinen Analogkarten.


    Evtl generell anfragen, was denn mit dem Treiber geplant ist. In dem Zuge dann noch die FF und die o.g. DVB-C Bugets ansprechen, ob die beiden auch bleiben?

    Die Liste habe ich derzeit übrigens abonniert, sollte es also mit bekommen, wenn sich was tut.

    Gruss
    SHF


  • [...]

    Ich werde jedenfalls werde bezgl. FF noch mal nachfragen. Und auch auf die spezielle Problematik eingehen, nachdem ich sie verstanden habe.

    Wenn der FF-Treiber aus dem Kernel fliegt wird es nämlich nervig.

    [...]

    Dann halten wir mal die Füße still.

    Ggf. wenn in der Liste Fragen zur Nutzung aufkommen, können wir uns ja einschalten.

    Danke derweil.

  • Nach viel lesen und nachdenken bin ich zu dem Schluss gekommen, dass es keinen Sinn macht noch einmal genau das zu fordern, was schon x mal gefordert wurde und nie durchgegangen ist.


    Mir ist aber eine Idee für einen Kompromiss gekommen, der so ähnlich auch schon bei anderen Treibern angewendet wurde.

    Wenn das durch geht, können die FFs im Kernel bleiben und es muss bis auf Kleinigkeiten nichts geändert werden. Auch der API-Teil würde drin bleiben, eigentlich ist es alles nur Kosmetik ;D .


    Eine Lösung für die HD-FF bedeutet das zwar nicht, allerdings erhält es die Chance einer Aufnahme.

    Wenn S:oren gute Arbeit beim SAA7146-Treiber leistet (wovon ich ausgehe) steigen Chancen gegenüber jetzt sogar deutlich, denke ich.


    S:oren

    Der Vorschlag wird 99% deiner Forderung erfüllen, sollte er angenommen werden.

    - die Community ueberzeugt linux-media, dass die FF-Karten benutzt werden und die Treiber inkl. DVB-API vollstaendig in mainline bleiben

    - linux-media erkennt das offiziell an

    Das ist meiner Meinung nach, das Beste, was wir momentan noch raus holen können.

    Sollte es trotzdem für Dich nicht in Frage kommen, warte bitte bis sich die Gegenseite geäussert hat. Ich würde deren Reaktion gerne sehen.

    Gruss
    SHF


  • Der Vorschlag wird 99% deiner Forderung erfüllen, sollte er angenommen werden.

    Ueberhaupt nicht. Wenn das DVB-API nicht mehr Userspace-API ist, sondern ein privater Header, dann ist das Unfug. Es waere auf jeden Fall auch eine Anpassung der Output-Plugins noetig, die ganze Idee einer einheitlichen und standardisierten Treiberschnittstelle (DVB-API) ist damit tot.

    Warum man nun unbedingt dafuer streiten will, ohne Not, kann ich nicht nachvollziehen.


    Aber auch egal, da ja nun die tatsaechliche Absicht ans Licht gekommen ist, den av7110 heimlich zu entfernen ("I have not really been involved in the move of av7110 to staging,..."). Man unterschreibt also Patches, die anscheinend untergeschoben sind. Grossartige Arbeitsweise. Und die FF-Treiber kommen, nach jetzigem Stand, eben nicht wieder zurueck. Was daran "Great news" sind, kann ich auch nicht nachvollziehen.


    Aber wie schon mehrfach hier geschrieben, mir auch recht, ich bin dann 'raus...


    Gruss,

    S:oren

  • Aber auch egal, da ja nun die tatsaechliche Absicht ans Licht gekommen ist, den av7110 heimlich zu entfernen ("I have not really been involved in the move of av7110 to staging,..."). Man unterschreibt also Patches, die anscheinend untergeschoben sind. Grossartige Arbeitsweise. Und die FF-Treiber kommen, nach jetzigem Stand, eben nicht wieder zurueck. Was daran "Great news" sind, kann ich auch nicht nachvollziehen.

    Woher nimmst du das, dass die FF-Treiber nicht zurück kommen? Hat Hans doch explizit geschrieben.

    Auch dass da was heimlich untergeschoben wurde, kann ich eigentlich nicht erkennen. Das ist halt an Hans vorbei gegangen, weil er ja offenbar nicht immer bei allem beteiligt ist.

  • Es waere auf jeden Fall auch eine Anpassung der Output-Plugins noetig,

    Peanuts.

    Das übernehme ich gerne.

    die ganze Idee einer einheitlichen und standardisierten Treiberschnittstelle (DVB-API) ist damit tot.

    Es gib doch nur die 2 Treiber und 2 Plugins.

    Aber auch egal, da ja nun die tatsaechliche Absicht ans Licht gekommen ist, den av7110 heimlich zu entfernen ("I have not really been involved in the move of av7110 to staging,...").

    Hans ist da nicht Zuständig, das ist Chefsache!

    Code
    But this is something where Mauro (CC-ed) needs to give his thoughts as well.

    Das hatte ich schon eine Weile vermutet.



    Warum man nun unbedingt dafuer streiten will, ohne Not, kann ich nicht nachvollziehen.

    Ich habe das vorgeschlagen, werde mich im weiteren da aber raus halten.

    Wenn dir der Name nicht zusagt, mach bei Zeiten einen Gegenvorschlag.

    DVB_FF_API oder wie auch immer.


    Mit irgendeinem Kompromissvorschlag müssen wir aber kommen, sonst gibt es nie Ruhe.

    Mit der Änderung würden auch die ganzen .rst Dateien verschwinden, durch die der Treiber unangenehm auffällt.

    Eine einmalige, winzige Anpassung der Plugins halte ich dafür für vertretbar.


    Die DVB-API ist Chefsache und die 3 Dateien scheinen ganz oben auf dessen Abschussliste zu stehen. (warum auch immer)

    Private APIs hingegen sind Teil des Treibers, für deren Inhalt ist primär Maintainer vom Treiber zuständig ;D .


    Neue Treiber, die den fraglichen API-Teil nutzen wird es ohnehin nie geben, zumindest offiziell. Das hat die letzten 10 Jahre nicht geklappt, warum sollte es das in der Zukunft?
    Die einzige Chance, die ich sehe ist, das auf dem kleinen Dienstweg durch zu kriegen.

    Gruss
    SHF


  • Wenn dir der Name nicht zusagt, mach bei Zeiten einen Gegenvorschlag.

    Ich habe alles geschrieben, was ich dazu zu sagen habe.


    Eine einmalige, winzige Anpassung der Plugins halte ich dafür für vertretbar.

    Bin mal gespannt, was die ganzen Distris dazu sagen, wenn ihr Quellcode der Plugins nicht mehr kompiliert. Ich habe da eine Vermutung: Kaputt, kann weg.

    Mir ging es immer um die User, die nicht alles selber bauen, sondern alles komplett fertig und funktionsfaehig zentral bekommen wollen. Wenn man alles noch funktionsfaehige wegwerfen und von vorne anfangen will, von mir aus.


    Die einzige Chance, die ich sehe ist, das auf dem kleinen Dienstweg durch zu kriegen.

    Private APIs hingegen sind Teil des Treibers, für deren Inhalt ist primär Maintainer vom Treiber zuständig ;D .

    Der Du dann bist!?

    Komplett ohne Ironie: Viel Glueck, Spass, und vor allem Erfolg damit.


    Gruss,

    S:oren

  • Ich hab deine Forderungen mal weitergeleitet.

    Mal sehen ...


    Deine Forderungen sind schön und gut, wenn das aber dazu führt, dass der Treiber am Ende doch ganz raus fliegt, ist keinem geholfen.


    Ehe das passiert, sollte man IMHO aber doch besser in den Sauren Apfel beissen, die Plugins rechtzeitig anpassen und die Maintainer der Pakete informieren und hoffen dass das klappt.

    Gruss
    SHF


  • Vielleicht haben wir Glück und können die DVB-API doch komplett retten.

    Daumen drücken, dass es klappt!


    On Mittwoch, 8. Februar 2023 09:42:35 CET Mauro Carvalho Chehab wrote:

    [...]

    >

    > The av7110 is in staging for two reasons:

    > - It is the only in-kernel driver that (partially) uses the

    > full-featured DVB API;

    > - Several IOCTLs used there are deprecated. See, for instance,

    > AUDIO_BILINGUAL_CHANNEL_SELECT documentation:

    >

    > " This ioctl is obsolete. Do not use in new drivers. It has been replaced

    > by the V4L2 ``V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK`` control

    > for MPEG decoders controlled through V4L2. "

    >

    > - the full-featured DVB API were never fully/properly documented. We did an

    > effort to document what it was possible, but there are still documentation

    > gaps.

    > - there are some parts of the full-featured API that aren't used on av7110,

    > which makes hard to have them documented. I guess those bits are used only

    > on some DVB settop boxes.

    > - there's a goal to use MC and V4L2 API for several of the features there.

    > However, as this didn't actually happen, I guess we can consider such

    > API as av7110-specific API when the time comes to move it from staging.

    >

    > Now, before moving av7110 out of staging, the API should be clearly

    > documented (and/or the unused parts of the API should be removed).

    >

    > So, for now, I'm ok to move saa7146 out of "deprecated" part, but

    > we should keep av7110 in staging (and all parts of saa7146 that

    > may depend on av7110) while we don't fix the API documentation.

    >

    > Thanks,

    > Mauro

    Gruss
    SHF


  • Auch wenn die Änderungen primär die FFs betreffen sollten, wäre es schön, wenn es noch ein paar Leute mit Budget-Karten testen könnten.


    Zumindest, ob es da im normalen DVB-Betrieb keine Probleme gibt.

    Nur um sicher zu gehen, die Änderungen sind recht tiefgreifend, da weiß man nie.



    Hans Verkuil sucht speziell noch jemanden mit einer FF-Karte mit Analogteil zum testen. Da gibt es wohl irgend eine Spezialität.

    Eigentlich kann damit nur diese Siemens DVB-C Karte mit Analogmodul gemeint sein. Zumindest ist das die einzige FF, die irgendwas mit analog zu tun hat, soviel ich weiß.

    Gerne auch so eine Karte selber, dann würde er das testen übernehmen.

    Gruss
    SHF


  • Hi,

    Ich müsste lange suchen, dann finde ich eine DVB-C 2.3 FF-SD. Hatte die als billigen Tuner genutzt. PC wird schon schwer mit PCI, aber auch noch möglich. Am Kabelanschluss scheitere ich aber (zum Glück). Eine 1.5 mit AVBoard hab ich für Sat auch noch, aber analog hat die ja nicht.

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Oh, die DVB-C 2.3 FF sollte auch gehen.

    Ich wusste gar nicht, dass die auch Analog empfangen kann.

    Bei den DVB-C Karten hab ich nicht wirklich Ahnung, da ich den Kabelanschluss (zum Glück) vor Anschaffung eines VDR losgeworden bin.


    Wenn Du das testen möchtest, wäre natürlich super. Ein Videosignal sollte ja eigentlich reichen.

    Helfen kann ich dabei aber leider nicht. Ich bin ehrlich gesagt, nicht mal sicher, ob die Analog-Funktion im Zusammenhang mit dem VDR jemals wirklich nutzbar war.


    Eine DVB-S 1.5 habe selber und bin gerade dabei den Kernel zu bauen (mit testen wird es heute aber wohl nichts mehr ;) ).

    Aber je mehr es versuchen, um so besser.

    Gruss
    SHF


  • Hallo zusammen,


    im Dezember habe ich mich bereit erklärt folgende Karten zu testen:

    • TechnoTrend DVB-S (rev 1.3)
    • TechnoTrend DVB-S (rev 1.5)
    • Hauppauge NOVA-S
    • Technotrend S2-1600
    • Technotrend S2-3200

    Nun habe ich leider keine Erfahrung, wie man den neuen Treiber in ein bestehendes System hineinpatcht.

    Kann jemand von euch ein kleines Howto schreiben, wie man in diesem Fall vorgehen muss.


    Als Basis würde ich dann Ubuntu 18.04 / 20.04 oder 22.04 mit yaVDR 0.7 einsetzen.


    Das dvbsddevice-plugin kann ich auch mittesten.

    Kann es hier Probleme mit dem VDR geben, wenn der neue Treiber andere Befehle verwendet?


    Vielen Dank für eure Hilfe!


    Schöne Grüße

    Christian

  • Oh, die DVB-C 2.3 FF sollte auch gehen.

    Ich wusste gar nicht, dass die auch Analog empfangen kann.

    AFAIR, die Fujitsu-Siemens DVB-C zusammen mit dem optionalen Analog-Modul war die einzige FF, die analoges TV empfangen konnte. Aber irgendwo war bei der Benutzung ein Haken, weswegen das kaum jemand damals benutzt hat. Außerdem musste die Kodierung per CPU erledigt wegen, noch mit dem analogtv (?) Plugin, aus dem erst später das pvrinput Plugin entstand. Das gab damals jede Menge Probleme mit stotternder Wiedergabe, bis ein großzügiger Ringbuffer eingebaut wurde.

  • Boah, Alter... ist das lange her. Wir waren noch jung 8)

    Ich meine mich zu erinnern, dass nie jemand das analogtv-Plugin mit den analogen Teilen der FF-Karten zum Laufen gekriegt hatte. Neben der FuSi hatte wohl auch die Technotrend 2300 irgendeine Art analogen Teil, der aber nur nutzbar war, wenn man das analoge Signal direkt an den Ausgang durchgeroutet hat. Und eventuell kamen die Analogteile bei der Tonausgabe, sofern nicht per SPDIF realisiert, zum Einsatz.

    Das was Hans Verkuil zum Analogteil getestet haben möchte war nach erstem Überfliegen VBI-Code. Ich kann mich nicht erinnern, dass der für vdr je genutzt wurde. Oder erfolgte darüber doch die 16:9-Umschaltung?

    Das ist einfach alles zu lange her.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hallo,

    Dann bin ich raus. Einen Analogteil hat die 2300 nicht und wie gesagt ich habe eh kein DVB-C mehr.

    Wenn die Karte jmd möchte zum Test such ich sie und versende die.

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!