kann ich die SAT-Tuner deaktivieren (zugunsten Kanäle via von streamdev-client) und die Ausgabe trotzdem via dvbhddevice (S2-6400) machen?
Klar, das dvbhddevice-Plugin hat sogar eine Option --outputonly, damit die ungenutzten Tuner nicht 'im Weg' sind.
Gruss,
S:oren
Diese Funktionalität, einen definierten Entwicklungszustand sicher und mit wenig Aufwand (wieder)herstellen zu können, ist für mich eigentlich einer der Hauptgründe so ein System wie Git überhaupt zu verwenden.
Aber nicht fuer eine riesige Community wie bei Linux. Wieviele alte kaputte Zwischenstaende will man denn oeffentlich aufheben? Warum? Wer soll sich da durchfinden? Der Entwicklungsprozess ist in den Mailing-List-Archiven dokumentiert.
Das Prinzip der Git-Entwicklung ist gerade, in unabhaengigen Development-/Topic-Branches Fixes und Features zu entwickeln, Patches solange zu verbessern, umzusortieren und anzupassen, bis alle Reviewer zufrieden sind. Rebase ist das Hauptwerkzeug bei der Entwicklung, das ist der groesste Vorteil von Git gegenueber alten Versionskontrollsystemen wie cvs/svn/hg. Und man kann sich lokal beliebig viele Branches von welchen-Zwischstaenden-auch-immer hinlegen, sogar aus verschieden remote-Repos zusammen im selben lokalen git. Natuerlich hat Git auch sonst noch viele weitere Vorteile fuer grosse Projekte: Pull statt Push fuer Master-Repositories mit (implizitem) Review und der Moeglichkeit von Merge-Commits mit Zusatzinformationen, Bisect zum Debugging und anderes mehr.
Der einzelne Entwickler wird vermutlich seine Zwischenversionen privat aufheben, die Oeffentlichkeit ist sicher fuer eine Muellabfuhr dankbar. Wenn man das System nicht verstanden hat, muss man sich nicht unbedingt zuerst ueber Leute aufregen, die mehr Erfahrung und vielleicht auch Durchblick haben.
Gruss,
S:oren
Keine Ahnung was die da machen, ...
Was sie immer machen, rebasen. Immutable Trees gibt es nur unter ganz besonderen Umstaenden in Development-Repos.
Da sowohl Du, als auch das Wiki die Karten als identisch bezeichnet haben
Hab ich eben nicht. Meine Formulierung war
anscheinend baugleich
was eben (vermutlich) gleiche Hardware, aber andere IDs bedeutet.
Und wenn der "SAA716x TT-budget driver" nur an die PCI-ID 13c2:3010 bindet, das funktioniert (nur der zugehoerige Frontend-Treiber laesst sich nicht uebersetzen), warum sollte es mit der gleichen ID beim TBS-Treiber nicht gehen?
Aber meine Hilfe ist ja anscheinend sowieso nicht gefragt, andere glauben wieder mal, es besser zu wissen.
Gruss,
S:oren
<EOT>
Ich habe die "tbs-linux-drivers_v170330.zip" herunter geladen. Sie trägt das Datum des Downloads. Die Dateien im Archiv sind aber viel älter, teilweise von 2011.
Nun ja, das heruntergeladene Archiv hat immer das Datum des Downloads. Treiber-Dateien werden nie _alle_ fuer ein neues Release ueberarbeitet.
Und ich habe auch eine tbs-open-linux-drivers_v20221231.zip heruntergeladen, da sind teilweise Dateien mit Datum vom Februar drin, also offenbar nochmal neuer als das Datum im Archivnamen suggeriert.
Aber wenn Du lieber ueber Zeitstempel diskutieren und eben keinen neuen Thread eroeffnen willst, ich muss meine Hilfe nicht irgendjemandem aufdraengen.
Da die Karte TBS6922 anscheinend baugleich zur S2-4100 ist, sollten die Treiber von TBS auch fuer die S2-4100 funktionieren (jedenfalls steht das so im Treibercode von TBS).
Vorher aber bitte die Subsystem-ID vergleichen, ob es sich wirklich um eine TBS6922 handelt.
Wenn die nicht übereinstimmt, wird die Karte nie erkannt werden.
Schoen dass Du mir unterstellst, ich wuesste nicht, wovon ich rede. Ich habe im Code von TBS jedenfalls das gefunden (Ausschnitt):
static struct pci_device_id saa716x_budget_pci_table[] = {
MAKE_ENTRY(TURBOSIGHT_TBS6922, TBS6922, SAA7160, &saa716x_tbs6922_config),
MAKE_ENTRY(TECHNOTREND, TT4100, SAA7160, &saa716x_tbs6922_config),
{ }
};Der Treiber bindet explizit mit der selben Config fuer TBS6922 und fuer TT4100. Also wird die S2-4100 auch mit ihrer eigenen ID erkannt.
Danke fuer nichts,
S:oren
habe ich gemacht, funktioniert auch nicht. Zu alt.
Zu alt kann ich mir nicht vorstellen, was ich heruntergeladen hatte war ~4 Wochen alt.
Mach am besten ein neues Thema auf.
Das ist doch alles genau das, was ich oben geschrieben habe. Mein saa716x-Treiber unterstuetzt die S2-4100 nicht, was nicht an der SAA7160-Bridge liegt, sondern an der nicht vorhandenen Unterstuetzung fuer die verwendeten Frontends in Mainline. Egal wie lange Du verschiedene Kernel ausprobierst, in der jetzigen Form wird mein saa716x-Treiber nicht mit Deiner S2-4100 funktionieren -> Zeitverschwendung.
Von Technotrend (wer auch immer heutzutage unter diesem Namen auftritt) gibt es diesen Fork des saa716x-Treibers ("SAA716x TT-budget driver") mit dem closed-source-Frontend-Modul tt_s2_4100_drv. Weil es keine oeffentlichen Sourcen dazu gibt, kann man dieses Modul nicht fuer neuere Kernel oder andere Prozessorarchitekturen kompilieren. Und dann kann man vielleicht einen Basistreiber fuer die SAA7160-PCIe-Bridge laden, einen DVB-Datenstrom wird man ohne Frontend-Treiber nicht aus der S2-4100 herausbekommen. Ich empfehle: Finger weg! (Oder halt bei alten Kerneln bleiben, fuer die es diese Binaermodule gibt.)
Da die Karte TBS6922 anscheinend baugleich zur S2-4100 ist, sollten die Treiber von TBS auch fuer die S2-4100 funktionieren (jedenfalls steht das so im Treibercode von TBS). Ich kenne mich mit den TBS-Treibern nicht naeher aus und will keinen Support dafuer leisten. Aber dort gibt es auf den ersten Blick auch Sourcecode fuer Tuner und Demod der Karte (tas2101, av201x). Also die TBS-Treiber fuer die S2-4100 zu verwenden sieht mir nach der vielversprechendsten Loesung aus, wenn man neuere Kernel verwenden will. Versuch macht 'kluch'.
Mehr kann ich hier auch nicht helfen. Und nun bitte nicht weiter diesen Thread mit S2-4100-Diskussionen zumuellen. Das hat nichts mit dem Bauen meines saa716x-Treibers unter 22.04 zu tun.
Gruss,
S:oren
Kernel 4.4 (weiter unten im Thread) ist ja auch schon recht alt, und es ist der Mist mit dem closed-source-Modul. Ich wuerde moeglichst die Finger davon lassen...
Das Problem ist dabei nicht die SAA7160-Bridge, sondern das closed-source Frontend-Modul.
Soweit, so schlecht. Aber:
Anscheinend unterstuetzt der Treiber fuer die TBS6922 auch die (baugleiche?) S2-4100. Von TBS scheint es auch passende Frontend-Treiber (tas2101, av201x) zu geben. Also vielleicht mal damit probieren...
Gruss,
S:oren
PS: Sorry, ist ja alles off-topic hier...
Der saa716x-Treiber, um den es hier geht, hat keinen Support fuer eine S2-4100.
Anscheinend hat ein "Konstantin Dimitrov" einen "SAA716x TT-budget driver" fuer so eine Karte gebaut. Das ist aber ein ganz anderer Treiber.
Gruss,
S:oren
es fehlt ein Modul "tt_s2_4100_drv"
So ein Modul ist kein (und war nie) Bestandteil des saa716x-Treibers.
Gruss,
S:oren
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
.
Der Du dann bist!?
Komplett ohne Ironie: Viel Glueck, Spass, und vor allem Erfolg damit.
Gruss,
S:oren
Woher nimmst du das, dass die FF-Treiber nicht zurück kommen? Hat Hans doch explizit geschrieben.
Richtig, er hat explizit geschrieben "av7110 stays in staging for now", was man in dem Pull-Request auch direkt sehen kann.
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
Du schätzt den Aufwand für die Umstellung DVB > V4L also bedeutend grösser / invasiver ein als VB1 > VB2?
Mindestens 20fach, vermutlich deutlich mehr. Haengt ja auch ein neues Ausgabeplugin dran. Die Versprechungen von V4L2, dass alles kompatibel ist, scheinen ja nicht so recht zu stimmen, bei der grossen Anzahl verschiedener softhddevices. Das selbe nochmal fuer die enigma2-Leute, da kenne ich mich aber nicht aus.
Wesentlich mehr Leute werden es aber nicht werden, so realistisch muss man sein.
Vielleicht reicht ja _eine_ Frage wie bei Budget-Karten. Ob es nur reicht, wenn sie von einem grossen Distributor kommt, keine Ahnung.
Ansonsten: Wer es noch nicht gemerkt hat, ich mache das alles nicht fuer mich. Wer von den Treibern profitieren will, kann ja wohl mindestens mal sein Interesse aeussern. Und nicht immer nur: "Ich wuerde ja gerne, kann aber nicht programmieren...", darum geht es nicht.
Anscheinend haben die Entscheidungsträger bei linux-media nicht wirklich Ahnung, was DVB angeht.
Fuer Mauro trifft das meines Erachtens voll und ganz zu. Hans gibt sich ja zumindest Muehe, vielleicht kommt man mit ihm bei linux-media wieder zu einer Arbeitsweise, wie sie in allen anderen Kernel-Subsystemen ueblich ist. Wieviel er jetzt und in Zukunft hier zu sagen hat, kann ich nicht einschaetzen. Dass er sich jetzt auch um DVB kuemmert, ist fuer mich jedenfalls ein sehr gutes Zeichen. Vielleicht arbeitet er ja mit der Community, statt gegen sie. Ich habe jedenfalls nichts gesehen, was dagegen spricht.
Gruss,
S:oren
Ich hatte das so verstanden das die Idee war im Idealfall mehrere Leute zu mobilisieren, die noch saa7146 DVB Karten nutzen, um zu verhindern, dass die entsprechenden Treiber gelöscht werden.
Genau.
Mit dem Hintergedanken, dass eine Anpassung dieser Treiber eben nicht sinnvoll ist, wenn die Treiber ohnehin auf der "Abschussliste" stehen.
Auch richtig.
Mittlerweile scheint ein pauschales Löschen abgewendet zu sein
Fuer ein Kernel-Release, hoffentlich, was FF-Karten betrifft. Fuer Budget-Karten ist ja eine langfristigere Unterstuetzung zugesagt.
Im letzten rc5 sind jedenfalls alle Treiber noch drin. Sollte sich nichts ändern, sind die FFs also auch noch mit Kernel 6.2 unterstützt.
Da habe ich als FF-Nutzer also aktuell eigentlich keinen Grund zu meckern.
Wenn ihr damit zufrieden seid, dass FF-Treiber ab linux-6.3 (oder 6.4?) nicht mehr da sind, dann sollten wir die Diskussionen hier sofort beenden. Wie schon so oft geschrieben, und ich meine das wirklich so: ich habe kein Problem damit, wenn SD-FF-Treiber und DVB-API entfernt werden. Dann gibt es von mir auch keine Anpassungen an dem HD-FF-Treiber mehr. Wenn das jedem klar ist und alle damit zufrieden: prima. Die ganze Schreiberei hier kostet mich schon wieder richtig viel Zeit, die ich eigentlich nicht spendieren wollte.
es geht faktisch nur noch darum was in welchem Zustand und mit welchen Anpassungen behalten werden soll.
Genau. Meine Frage an die Community.
Die vb2-Anpassungen finde ich richtig und notwendig, wuerde ich machen, wenn dadurch die bisherigen Treiber mit dem bestehenden API beibehalten werden. Wenn nicht, bin ich aus der Nummer 'raus. Kein Problem fuer mich.
Wenn jemand anders neue Treiber mit anderem API bauen moechte, von mir aus gerne. Ist nur ein wirklich gut gemeinter Hinweis: Mit "eigentlich habe ich keine Ahnung, aber so schwierig kann es nicht sein" wird man nicht einen neuen Treiber in ein paar Wochen programmieren, testen, und in den Kernel aufgenommen bekommen. Und den dafuer erforderlichen Aufwand (auch von Kernel-Maintainern) faende ich dann auch nicht angemessen, fuer derartig in die Jahre gekommene Hardware. Nur meine persoenliche unbedeutende Meinung.
Wäre es an der Stelle nicht deutlich sinnvoller wenn du dich ab dem Punkt selber in die Diskussion einschaltest?
Der Punkt ist doch: Es gibt ueberhaupt keine Diskussion um FF-Treiber bisher. Sollte jemand eine starten: Ich habe nun schon mehrfach angeboten, mich an einer solchen zu beteiligen, wenn mich jemand dazu einlaedt.
Es ist absolut normal, auf einer Mailingliste Leute mit anzuschreiben, die bisher zu der diskutierten Frage irgendwas beigetragen haben. Warum man sich hier nicht traut, kann ich nicht nachvollziehen. Aber vorher braucht es erstmal eine Diskussion.
Wenn ich Sören richtig verstanden habe (ansonsten bitte ich gerne um Korrektur!) dann geht es ihm genau darum, daß er nicht alleine den „Vortänzer“ für alle machen will, und ohne Unterstützung von Dritten auf der ML als Einzelkämpfer gegen die bekannten „Windmühlen“ anrennen mag.
Genau. Ich werde nicht nochmal eine Diskussion um die FF-Treiber starten.
Es werden IMHO Stimmen gesucht, die genau dort für den Verbleib der Treiber die virtuelle Hand heben, und Bedarf und Interesse signalisieren. Ein Anfang hat ja bereits erste Wirkung gezeigt.
Richtig, fuer Budget-Karten hat eine einfache Anfrage gereicht, und Hans macht sogar die erforderlichen Anpassungen selber. Vielleicht waere es fuer Full-Featured-Karten genau so, wenn mal jemand fragt. Vielleicht ist ja die offizielle "Arbeitsverweigerung" von linux-media in Bezug zum av7110 ("Cleanup patches for the drivers here won't be accepted.") nur ein Versehen.
Gruss,
S:oren
Diesen Umstellungsaufwand versuche ich gerade abzuschätzen und ob es machbar wäre. Allein um sinnvoll argumentieren zu können.
Argumentiere so, und Du hast den Job. Und wir alle keinen Treiber mehr.
Steht irgendwo, welcher Treiber für welche Karten gut ist, bzw. was der jeweilige Treiber für eine Aufgabe hat.
Ich wuerde (in dem Zusammenhang hier) in drivers/staging/media/deprecated/saa7146/*/Kconfig nachschauen. Wie allgemeinverstaendlich das ist, keine Ahnung.
Ey, Leute. Ihr macht mir echt "Spass".
Was müsste ich denn noch nachfragen, wenn es auch um die FF-Karten gehen soll?
Ob auch die Treiber fuer Full-Featured-Karten bleiben koennen, weil diese Karten noch im Einsatz sind!?
Nochmal - ich bin der volle DAU, was Kerneltreiber anbelangt, auch bzgl. DVB-Treibern und deren Zusammenspiel.
Ich habe schon ganz oben und danach noch mehrfach geschrieben, dass es dann neben saa7146 um die ttpci und av7110-Treiber geht.
Keine Ahnung, wie ich es noch anders erklaeren soll...
Da werden wir und auf der Stelle drehen, fürchte ich.
Ohne ein konkretes Angebot, wird es schwierig jemanden von diesem zu überzeugen.
Zumal mir auch der Hintergrund fehlt um da sinnvoll argumentieren zu können.
Ich denke, mein Angebot ist sehr konkret. Ja, es muesste jemand auf linux-media vorstellen, wenn die Community es annehmen will. Und mich gerne auf Cc: setzen fuer 'sinnvolles Argumentieren', technisch!
Immerhin ist schon mal angekommen, das Karten noch genutzt werden.
Ich habe nur gesehen (in dem Entfernungs-Patch-Thread), dass explizit nach Budget-Karten gefragt wurde, was auch prompt akzeptiert wurde. Was im Umkehrschluss aber auch heisst, Full-Featured-Karten koennen weg. Oder habe ich etwas uebersehen?
Wenn man nach den Headern sucht finde ich auch nur diese (video.h und audio.h in include/linux/dvb/ ).
Dann noch die osd.h, obwohl die oben nicht erwähnt wurde.
Sind das nur die 3 Dateien um die es geht, oder habe ich was übersehen?
Diese drei, ja. Net habe ich nie im Einsatz irgendwo gesehen. Der Rest wird ja von den hunderten Budget-Karten auch benutzt.
Was davon wäre denn unbedingt erforderlich weil nicht mit der V4L2 api möglich?
osd, hab ich nichts zu gesehen, wurde hier auch schon mal erwähnt.
Beim Rest war mir auf die Schnelle nichts aufgefallen, das man nicht irgendwie hinbiegen könnte.
'Irgendwie hinbiegen' waere vielleicht moeglich, bei OSD wuesste ich allerdings spontan nicht, wie das gehen koennte, vielleicht gibt es aber custom-Aufrufe. Audio und Video sind so extrem einfach im DVB-API, dass eine Umstellung auf V4L2 einen immens groesseren Aufwand bedeuten wuerde. Und wozu? Die beiden/drei Include-Dateien los zu werden? Weil die warum genau so unglaublich weh tun?
Wenn jemand so eine Umstellung programmieren will, bedeutet das einen neuen Treiber und neue Ausgabeplugins. Ziemlich viel Aufwand dafuer, dass man dann mit kaffeine Videos auf FF-Karten abspielen kann, was Mauros Lieblingsargument, aber bestimmt keine irgendwie sinnvolle Anwendung ist. Und man haette dann in jedem Fall einen Mix von DVB- und V4L2-API, weil DMX- und Frontend-APIs als Teil von DVB sicher bestehen bleiben muessen, bei hunderten Treibern und Karten, die es nutzen (CA ist ja auch noch da und irgendwie unbeliebt geworden, aber nur ein Randthema).
Ich kann nicht verstehen, warum man das simple DVB-Output-API mit Macht auf V4L2 umstellen will. API-Vereinheitlichung waere ein Argument. Dann aber mit Compat-Libraries und fuer das ganze DVB-API. So ergibt das keinen Sinn und sieht fuer mich nach reiner Schikane aus.
Aber heh, wenn jemand so eine Komplettumstellung programmieren moechte, statt die bestehenden Sachen zu behalten, wo jahrzehntelange Arbeit drin steckt, mir soll alles recht sein.
Gruss,
S:oren
