Gibt es irgendwelche Neuigkeiten hinsichtlich der Bemühungen den Treiber in den Kernel zu bekommen?
Da laut https://git.kernel.org/cgit/li…07732890f96fd953a8953be2d meine Cine CT V6.1 vom Kerneltreiber unterstützt werden soll, habe ich mal den Kerneltreiber ausprobiert (Kernel 3.17.7). Der Treiber lädt auch, findet aber keine Tuner. media_build_experimental lädt die Frontendtreiber stv0367dd und tda18212dd. Letzterer fehlt im Kernel komplett und der Treiber stv0367 scheint für die DD-Karte auch nicht geeignet zu sein.
Verfolgt jemand die Mailingliste? Wurde schon versucht die Frontendtreiber in den Kernel zu bekommen?
Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren
-
-
Gibt es irgendwelche Neuigkeiten hinsichtlich der Bemühungen den Treiber in den Kernel zu bekommen?
Eher nicht. Alles nur Gerüchte. Nichts handfestes.
Angeblich arbeitet Mauro Carvahlo Chehab an den Digital Devices Treibern.
Dieser Patch von ihm hat mich auch entfernt an ein paar Sachen erinnert, die ich im dddvb-Paket von Digital Devices gesehen habe: http://lwn.net/Articles/628432/Der Treiber lädt auch, findet aber keine Tuner.
Da muss ich gestehen, dass das meine Schuld ist. Ich habe vor einigen Monaten die PCI-IDs im Kerneltreiber hinzugefügt. Jetzt lädt zwar der Treiber für die Bridge, sonst aber logischerweise nichts.
Verfolgt jemand die Mailingliste?
Ja, ich.
Wurde schon versucht die Frontendtreiber in den Kernel zu bekommen?
Es gab da mal einen Anlauf der im Sande verlaufen ist.
Es ist auch gar nicht das Problem von linux-media. Die Treiber von Digital Devices scheinen aber so "anders" zu sein, dass es da sehr viel Diskussionsbedarf gibt.
Deutlich schneller ans Ziel kommt man im Moment mit DVBSky. Dort ist die Treiberintegration so gut wie abgeschlossen.http://dvbsky.net/Products_T980C.html
http://dvbsky.net/Products_T9580.html
http://dvbsky.net/Products_T982.html -
Genau - ungetesteten Mist submitten, aber immer eine große Klappe.
-
Genau - ungetesteten Mist submitten, aber immer eine große Klappe.
Im Nachhinein rumjammern, das könnt ihr alle gut.
Und wie immer gilt. Wenn du es besser kannst, dann mach es.Mein eigentliches Ziel ist erreicht. Die Cine S2 V6.5 von einem Kollegen ist jetzt lauffähig.
-
Im Nachhinein rumjammern, das könnt ihr alle gut.
Und wie immer gilt. Wenn du es besser kannst, dann mach es.Hier Leuten, die wissen was sie tun und schon viele substanzielle Beitraege geliefert haben, irgendwas mit "rumjammern" und "dann mach es" an den Kopf zu werfen, empfinde ich einfach nur als unverschaemt! Insbesondere nachdem man selbst unheimlich stolz war, ein paar PCI-IDs in den Kernel bekommen zu haben, was sich jetzt auch noch (zumindest teilweise) als Fehler rausgestellt hat.
Und wenn man weiss, dass man irgendwelche Fehler in den Kernel gebracht hat, dann gehoert es sich ja wohl mindestens, den Committer und die Mailingliste darueber zu informieren, wenn man schon keinen Korrekturpatch zustande bringt...
Gruss,
S:oren -
irgendwas mit "rumjammern" und "dann mach es" an den Kopf zu werfen, empfinde ich einfach nur als unverschaemt!
Ich finde nicht, dass du dich da einmischen solltest. Du hast nicht alles mitbekommen und ich werde das hier auch nicht ausbreiten.
man selbst unheimlich stolz war, ein paar PCI-IDs in den Kernel bekommen zu haben
Ja, ich war unheimlich stolz. Das darf man wohl auch sein, wenn einem von Anfang an Steine in den Weg gelegt werden. Der Patch, der an die Linux-Media Mailingliste ging war hier im Portal über mehrere Wochen einsehbar, bevor ich ihn abgeschickt hatte. Da hat sich niemand gerührt.
als Fehler rausgestellt hat.
Es ist kein Fehler. Es tut, was es soll.
wenn man schon keinen Korrekturpatch zustande bringt...
Dazu sehe ich ebenfalls keinen Anlass.
Nur noch soviel zum Schluss:
An einem Punkt hat dann Antti Palosaari an dem DD-Treibern angefangen zu arbeiten (der entsprechende Branch dazu ist seit vielen Wochen unverändert), woraufhin ich mich mit ihm darauf abgestimmt hatte, nichts mehr an den Treibern zu tun. Solange ich nichts anderes von ihm höre, bleibt das auch dabei. -
Leute, beruhigt Euch mal wieder! Ob das Hinzufügen der PCI-ID ein Fehler war oder nicht, kann man auch sachlich diskutieren. Ich persönlich sehe darin keinen Fehler, da der Treiber wahrscheinlich funktionieren würde, wenn die entsprechenden Frontendtreiber vorhanden wären. Und selbst wenn nicht, ist es immerhin schon mal ein Schritt in die richtige Richtung. Ich warte numehr seit über 3 Jahren darauf, daß sich hier was tut.
Wenn alle Beteiligten ihre (persönlichen) Differenzen vergessen und stattdessen ihre Energie bündeln würden, wäre der Treiber wahrscheinlich schon längst im Kernel.Ich danke jedenfalls Copperhead für das Update zum aktuellen Stand und hoffe weiter, daß meine Karte irgendwann mal OOTB funktioniert.
-
Ja, ich war unheimlich stolz. Das darf man wohl auch sein, wenn einem von Anfang an Steine in den Weg gelegt werden. Der Patch, der an die Linux-Media Mailingliste ging war hier im Portal über mehrere Wochen einsehbar, bevor ich ihn abgeschickt hatte. Da hat sich niemand gerührt.
Es ist die Verantwortung desjenigen, der den Patch submitted, dass der Patch in Ordnung ist. Und es ist selbstverständlich auch seine Verantwortung, dadurch hervorgerufene Fehler zu korrigieren.So war es jedenfalls früher bei dvb. Da wurde verantwortungsvoll gearbeitet und getestet. Aber bei linux-media wird mittlerweile munter irgendwelches Zeug committed, was offenbar weder getestet ist noch verstanden wurde. Schuld daran ist letztendlich der Maintainer.
Genau diese Schlamperei ist der Grund, weshalb ich mit linux-media nichts (mehr) zu tun haben möchte.
CU
Oliver -
Ja, ich war unheimlich stolz. Das darf man wohl auch sein, wenn einem von Anfang an Steine in den Weg gelegt werden.
Nein, so ist das Leben.
Der Patch, der an die Linux-Media Mailingliste ging war hier im Portal über mehrere Wochen einsehbar, bevor ich ihn abgeschickt hatte. Da hat sich niemand gerührt.
Genau so funktioniert Kernel-Entwicklung nicht, Schweigen ist keine Zustimmung.
Es ist kein Fehler. Es tut, was es soll.
Ah ja, einen Treiber in den Kernel gebracht, der nicht funktioniert (weil er keine Tuner laedt). Und das "tut, was es soll". Das sind exakt die Sachen, die erfahrene Entwickler wie UFO zur Resignation gebracht haben. Und Deine Glaubwuerdigkeit als Kernel-Entwickler ist damit endgueltig bei Null!
Solange ich nichts anderes von ihm höre, bleibt das auch dabei.
Die entscheidende Passage (den Fehler zuzugeben und die Community darueber zu informieren) hast Du ja ganz "elegant" ignoriert. Aber weitere Diskussionen hierzu haben vermutlich wirklich keinen Sinn...
S:oren
-
da der Treiber wahrscheinlich funktionieren würde, wenn die entsprechenden Frontendtreiber vorhanden wären.
Ganz sicher nicht! Wenn der Bridge-Treiber die Frontend-Treiber nicht einbindet, werden sie auch nicht benutzt.
Gruss,
S:oren -
Es ist die Verantwortung desjenigen, der den Patch submitted, dass der Patch in Ordnung ist. Und es ist selbstverständlich auch seine Verantwortung, dadurch hervorgerufene Fehler zu korrigieren.Ist es denn ein Fehler? Ich stelle einfach mal die Behauptung in den Raum, dass die Bridge wohl auch für die neue Karte zuständig ist. Die Bridge verhält sich also wohl richtig. Der Rest (Frontendtreiber) fehlt halt noch. Er war nicht Teil des ersten Patches. Sollte vielleicht jemand auf den Weg bringen, der die entsprechende Karte auch besitzt.
Ich weiß nicht welche Absprachen im Hintergrund noch gelaufen sind. Vielleicht war ja ursprünglich geplant das die Frontendtreiber in Kürze folgen sollten.
Am Zustand hat das ganze aber nichts geändert. Es funktionieren jetzt immerhin ein paar mehr Karten mit Kernel-Treiber und die, die bisher nicht ohne Extra-Treiber funktioniert haben, funktionieren jetzt halt auch nicht.
Zitat
Genau diese Schlamperei ist der Grund, weshalb ich mit linux-media nichts (mehr) zu tun haben möchte.Letztenendes ist das aber (aktuell) der einzige Weg um Treiber in den Kernel zu bekommen. Und alles was nicht im Kernel ist artet letztlich in Arbeit für den Distributor aus, der dann werweißwo überall Treiber zusammensuchen muss.
Für mich ist das gerade einer der Gründe warum ich Linux gerne verwende. Treiber sind "einfach da".
Also hackt nicht auf jemandem rum der sich die Mühe macht die Kernel-Treiber wenigstens ein Stück weit voranzubringen sondern versucht lieber euren Teil dazu zu tun, dass die noch ausstehenden Fehler beseitigt werden.
-
Für mich ist das gerade einer der Gründe warum ich Linux gerne verwende. Treiber sind "einfach da".
Das kann man auch andersrum sehen, leider ist da auch viel alter Müll drin und der Kernel wird auch nicht kleiner ...
Ich weiß nicht was das Problem ist ein DKMS Paket zu installieren, man hat in der Regel wenig bis keinerlei Aktionen bei Kernel Aktualisierung. Man bekommt echte Updates, nicht wie so oft nur Pseudo-Updates im Kernel oder muss über Jahre mit einem Fehler im Kerneltreiber klar kommen, weil es halt so ist wie es ist ... siehe die diversen kleinen Fehler bei TT S2-3200 und S2-1600, tolle Treiber die "einfach da" waren ...
Regards
fnu -
Letztens war erst etwas in der Presse das einige sehr alte Kernel-Treiber rausgeflogen sind.
Die meisten Treiber sind außerdem als Module umgesetzt. Wer die Hardware nicht hat, hat keinen Nachteil dadurch, weil sie nicht geladen werden.
Ein DKMS-Paket fliegt einem spätestens um die Ohren wenn sich die kernelseitigen APIs verändern. Dann kann einem passieren das der Hersteller nachbessert. Es kann aber auch sein, dass der Hersteller die Hardware mittlerweile für "zu alt" hält und schon haben wir die bekannte "Windows-Situation". Neues Windows muss her weil der Support ausgelaufen ist und ein Großteil der Hardware gleich mit weil man keinen Treiber mehr bekommt.
-
Ist es denn ein Fehler?
Ja. Eine ID fügt man hinzu, wenn alle anderen Voraussetzungen erfüllt sind, d.h. der Frontendtreiber vorhanden und in ddbridge eingebunden ist. Alles andere ist Murks.Zitat
Ich stelle einfach mal die Behauptung in den Raum, dass die Bridge wohl auch für die neue Karte zuständig ist.
Es mag sein, dass der Bridge-Treiber irgendwann einmal dafür zuständig sein wird. Noch ist er es nicht, aber er gibt vor, es zu sein.Ich erinnere mich noch, wie einmal ein besch... Treiber irgendeiner exotischen (Sound??-)Karte behauptet hat, er wäre für sämtliche saa7146-Karten zuständig. Das Resultat war, dass keine saa7146-basierte DVB-Karte mehr funktioniert hat...
Aber egal, für mich ist hier EOD.
CU
Oliver -
Zitat: Genau diese Schlamperei ist der Grund, weshalb ich mit linux-media nichts (mehr) zu tun haben möchte.
Letztenendes ist das aber (aktuell) der einzige Weg um Treiber in den Kernel zu bekommen.
Ich hoffe mal, das war nicht so gemeint, Schlamperei sei der einzige Weg, Treiber in den Kernel zu bekommen!? Dazu wird es hoffentlich nie kommen...
Es ist wohl so, dass der (Haupt-)Maintainer von linux-media Schlampereien selten zurueckweist (dafuer habe ich etwas mehr Verstaendnis als UFO), manchmal auch explizite Hinweise auf Schlamperei ignoriert (wofuer ich auch kein Verstaendnis habe - ist in letzter Zeit aber besser geworden, denke ich). Um so wichtiger ist doch aber, dass der Patch-Autor keine Schlampereien begeht.
Also hackt nicht auf jemandem rum der sich die Mühe macht die Kernel-Treiber wenigstens ein Stück weit voranzubringen sondern versucht lieber euren Teil dazu zu tun, dass die noch ausstehenden Fehler beseitigt werden.
Ist es Rumhacken, wenn man darauf hinweist, dass ein Signed-off-by mit einer gewissen Verantwortung verbunden ist? Ist es heutzutage ueblich, irgendwas abzuzeichnen/freizugeben, was man nicht verstanden hat?
Was waere denn "mein Teil", den ich "zu tun" haette? Ich werde nie einen Treiber submitten fuer irgendeine Hardware, die ich nicht habe und nicht testen konnte.
Wenn jemand etwas lernen will und nach konkreter Unterstuetzung fragt, bin ich gerne zur Hilfe bereit. Mit selbstherrlichem Auftreten wird das aber nichts...Gruss,
S:oren -
Hab das grade mal auf meinem Wheezy System getestet.... rminstall /distclean vom media_build_experimental, reboot -> Karte weg. dkms Paket installiert, module werden gebaut, reboot -> Karte wieder da
Super Sache, danke dafür! -
und auch nur wenn du keine MaxS8 hast - dafür brauchts mind. 0.9.18beta2
Christian
-
Hallo zusammen,
zunächst "sorry" für's "ausgraben" der Thread-Leiche, das folgende passt aber wohl relativ gut hier rein und ist evtl. für den einen oder anderen hilfreich:
Nachdem ich meinen Server (mit Digital Devices Cine CT V6+DuoFlex CT2 - STV0367 und CXD2843 sowie einer KNC-ONE DVB-C Karte basierend auf SAA7146 und TDA10023) vor kurzem von Kernel 3.11.10 auf 4.4.2 Distributionsbedingt upgraden musste, wurd' es wieder Zeit für die Bastelei mit den Kernelmodulen für die DVB-Karten-Mischbestückung. Für 3.11.10 hatte ich seinerzeit einfach die notwendigen Sourcen aus dem Mainline-Kernel in das dddvb-Package eingearbeitet und konnte so wunderbar und stabil die Konstellation aus 3xDVB-C Tuner (STV0367+KNC-ONE) und 2xDVB-T (CXD2843) fahren. Mit dem Upgrade auf 4.4.2 ging das Einfügen zwar auch, war aber schon mit relativ viel Flickarbeit verbunden. "media_build_experimental" hatte ich in der Vergangenheit mal probiert, war aber aufgrund von Problemen beim Compilen auch nicht das Wahre. Beide Lösungen (dddvb+gebastel und media_build_experimental) resultieren ausserdem in vom Kernel abweichenden DVB APIs. Ich habe mich also mal rangesetzt und IMHO recht erfolgreich das dddvb-Package in den Kernel-Tree integriert.
Das Ergebnis ist auf GitHub unter https://github.com/herrnst/dddvb-linux-kernel zu finden.
Die Commits sind so zusammengesetzt, dass zunächst alle Anpassungen am DVB-Core angewendet werden (habe versucht, nach thematischen bzw. funktionalen Änderungen zu splitten), anschliessend die Frontends eingefügt werden und zum Schluss ddbridge auf aktuellen Stand zu bringen.
Orientiert habe ich mich dabei (dann doch) an media_build_experimental (wurde auch schon länger nicht mehr upgedated), vor allem am Script, welches dddvb in die Kernel-Sourcen einfügt (/experimental/add-drivers). dddvb/ddbridge in Version 0.9.22 kommt aus dem Digital Devices GIT. Ausserdem sind 1-2 der im Umlauf befindlichen DKMS-Patches eingearbeitet.
Bemerkungen:
- cxd2099 wurde in dddvb nur gering erweitert, es wurden nur die wirklich funktionalen Änderungen übernommen.
- Die DRXK und lnbh25-Frontends habe ich nicht aus dem dddvb-Package übernommen. ddbridge kompiliert fehlerfrei gegen die In-Kernel-Variante von DRXK (es scheint hier drei Varianten zu geben: Kernel, dddvb und eine Dritte resultierend aus einem der DKMS-Patches. Mangels Hardware kann ich leider nicht prüfen, ob der aktuelle Stand funktioniert). Die beiden lnbh25-Varianten weichen ebenfalls (für mich) erheblich voneinander ab, und die unterschiedlichen Signaturen von lnbh25_attach() erforderten eine Anpassung in ddbridge-core.c. Das wird aber garantiert nicht auf Anhieb funktionieren. "You have been warned!"
- tda18271c2dd unterscheidet sich nur in zusätzlichem Code, der aufgrund #ifdef..#endif sowieso nicht kompiliert wird - keine Änderungen übernommen.
- Aus den Frontends sowie aus ddbridge habe ich einigen unbenutzten Code entfernt, um Compiler-Warnungen abzudrehen.
Auf meinem Server läuft das "integrierte" Paket bislang fehlerfrei mit o.g. CineCTV6+DuoFlex CT2 und der KNC-One C (Streaming-Software ist TVHeadend) auf Kernel 4.4.3 (ja, weicht vom ursprünglich erwähnten 4.4.2 ab, die Integrationsarbeit habe ich aber direkt auf 4.4.3 begonnen, da zwischenzeitlich released).
Vielleicht hilft der gepatchte Kernel-Tree dem einen oder anderen. Interessant wäre, ob DRXK, LNBH25 und/oder CXD2099 (CI) Hardware funktioniert. Bitte aber als "as-is" verstehen, ich übernehme gerne korrigierende Patches, Hilfestellung o.ä. kann ich aber nur schlecht geben - ich hab' nur Puzzle-Teile zusammengesetzt
Entsprechend werde ich auch keine Versuche unternehmen, die Patchserie in Mainline unterzubringen, das überlasse ich den Autoren oder Freiwilligen, die den Code besser kennen, verstehen und Fragen beantworten können.Linux 4.4.3+dddvb-0.9.22: https://github.com/herrnst/ddd…commits/linux-4.4.y-dddvb
Linux 4.5-rc6+dddvb-0.9.22: https://github.com/herrnst/ddd…rnel/commits/master-dddvb (enthält zusätzlichen Buildfix für die Änderungen an dvb_register_device())(Commit-Hashes können/werden sich aufgrund Rebase/Force-Pushes ändern!)
HTH,
"nst"
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!