Possible removal of saa7146 and ttpci drivers from kernel tree

Zitat von Dr. Seltsam

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.

Ich hatte es zum Laufen, mit einem klon des analogtv Plugins namens 'ptv'-Plugin. Aber die Änderungen upstream zu bekommen war zu schwer und das ist dann eingeschlafen. VBI ist eine andere Baustelle, war aber damals sogar nutzbar.

Am Ende des Tages gibt es analoges Kabel-TV heute nicht mehr. Das darf gerne gehen. Niemand von uns wird das testen können.

Also, wenn ich die Expertenrunde richtig interpretiere, kann man zusammenfassend sagen:

Dasmit analog-TV, FF und VDR war nie so richtig praxistauglich.

Dann gibt es analoges Kabel-TV praktisch nicht mehr.

Und wenn man doch mal was digitalisieren will, sollte man zu einer gebrauchten PVR für ein paar Euro greifen, die gescheit funktioniert.

Das heisst, es wird sich wohl keiner beschweren, wenn die Analog-Funktionen auf den FFs nicht gehen sollten. (Zumindest eher nicht im VDR-Portal )

Zitat von Dr. Seltsam

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 war doch AVARDS mit dieser WSS-Geschichte. Der Begriff VBI dafür ist mir hingegen völlig ungeläufig.

Aber was hat das nun mit dem Analog-Video vom SAA7146 zu tun, das Signal kommt doch ausschließlich vom AV7110?

Wobei, wenn man die Beschreibung liest, könnte es schon sein dass es da Berührungspunkte gibt.

/dev/vbi? wird verwendet und in dem Patch von damals ist V4L2_BUF... mehrfach enthalten.

Das zu testen wäre dann aber kein Problem und sollte mit jeder Karte gehen, die Software dazu hab ich sogar noch drauf.

Leider hat kein einziger einer meiner Fernseher je darauf reagiert. Ich hatte aber irgendwie mit dem Oszilloskop sichergestellt, dass das Signal korrekt aus der FF raus kommt.

Zitat von c.h.

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.

Du musst "nur" den Kernel patchen und neu kompilieren.

Wenn ich das am laufen habe kann ich Schritte hier angeben.

Für diejenigen, die es selber versuchen wollen:

Der Kernel aus dem verlinkten GIT ist leider unbrauchbar.

Einfach clonen und bauen geht nicht! Build läuft nicht durch und ausserdem ist er veraltet.

Man wird wohl die Patches auf einen anderen Kernel anwenden müssen. Zumindest ist das die Lösung, die mir einfällt.

Nach dem ich das eben festgestellt habe, fange also auch ich bei dem Thema gerade nochmal von vorne an .

Zitat von c.h.

Das dvbsddevice-plugin kann ich auch mittesten.

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

Die Änderungen sind nur innerhalb des Treibers, am VDR sind keine Änderungen nötig.

Es sollte mit dem neuen Treiber einfach alles so funktionieren, wie bislang.

Prinzipiell ist das auch der ganze Test.

Also einfach mit dem VDR eine Weile das machen, was man immer macht und schauen, ob es Problem gibt.

Zitat von SHF

Der Kernel aus dem verlinkten GIT ist leider unbrauchbar.

Einfach clonen und bauen geht nicht! Build läuft nicht durch und ausserdem ist er veraltet.

Es geht doch.

Wahrscheinlich hatte ich mich irgendwo beim Anpassen der Anleitung vertippt.

Den richtigen branch "saa7146-clean" hatte ich zwar, aber da war wohl weiter vorne was schief gegangen.

Allerdings läuft der Kernel 6.3 rc2 der jetzt raus kommt, bei mir nicht gescheit (kein X und Grafikfehler auf der Konsole).

Keine Ahnung, was man da jetzt am besten versucht. Rebase auf die neueste Version? Auf eine ältere macht wohl keinen Sinn?

Ich mach für heute jedenfalls erstmal Schluss.

Die Patches auf einen anderen Kernel anzuwenden ist übrigens auch nicht so einfach, weil sich da ausgerechnet in den letzten 2 Jahren so viel geändert hat.

Kann man das nicht in media_build reinpatchen und dann für einen vorhandenen Kernel kompilieren?

Media_build hatte ich eigentlich schon abgeschrieben.

Wobei die echte letzte Aktualisierung kein Jahr alt ist.

Evtl. macht es doch Sinn das mal zu versuchen.

Das mit dem media_build war eine gute Idee. Ich habe mich bei dem von den TBS-Treiber bedient, da fehlte dann nicht mehr viel.

Anleitung für Tester kommt aber erst später.

Da eventuell noch Änderungen am Treiber nötig sind, mach das noch keinen Sinn weiter zu testen.

Inzwischen habe ich das soweit getestet und bei mir funktioniert alles inklusive WSS wie bisher.

Als ich jetzt das ganze Vorgehen zusammenschreiben wollte, klappt das mit dem Git von Linuxmedia leider nicht mehr.

Die Commits, die ich ausgecheckt hatte, gibt es einfach nicht mehr (not in tree).

Keine Ahnung was die da machen, damit hatte ich nicht gerechnet.

Wenn ich mit vertretbarem Aufwand eine reproduzierbare Möglichkeit finde den Treiber mit den Patches zu bauen, liefere ich die aber noch.

Zitat von SHF

Keine Ahnung was die da machen, ...

Was sie immer machen, rebasen. Immutable Trees gibt es nur unter ganz besonderen Umstaenden in Development-Repos.

Ich hatte halt damit gerechnet, dass zumindest auf die hochgeladenen Zustände vom Server "archiviert" werden. So dass man zumindest eine Weile darauf zurückgreifen kann.

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.

Zum Glück hatte ich meine lokale Kopie noch nicht gelöscht.

Das war übrigens nicht die erste Merkwürdigkeit.

Zwischen dem, was man mit git bekommt und dem, was das Webinterface anzeigt, gibt es auch so einige Diskrepanzen.

Zitat von SHF

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

So eine Kleinigkeit regt mich nicht wirklich auf. Ich war nur etwas überrascht, das, bei allem was das System so tolles kann, ausgerechnet diese vermeintliche Trivialität nicht funktioniert hat.

Etwas ärgerlich ist eigentlich nur, dass es jetzt wieder Zeit gekostet hat, sonst wäre das Paket zum testen schon letzte Woche fertig gewesen.

Dass die Zwischenstände nicht archiviert werden ist halt so, weil man das nicht macht.

Der Erklärung, kann ich aber nicht ganz folgen.

Zumindest bis die Änderungen im Kernel gelandet und von einer größeren Menge getestet wurden, können einige ausgewählte Zwischenstände durchaus interessant werden. Speziell wenn später Probleme auftreten, die man beim Testen nicht hatte.

Für die Entwickler brächte das auch den Vorteil eines zusätzlichen Backups, um das man sich nicht kümmern muss.

Und da man eh einen Server dafür laufen hat, kann der auch die ganze Verwaltung übernehmen. Inklusive löschen nach 2 Jahren oder so.

Aber vielleicht denke ich hier auch einfach zu praktisch ....

Für die, die es auch mal selber probieren wollen, habe ich mein verwendetes Mediabuild in eine (hoffentlich) benutzerfreundliches Format gebracht.

Funktionieren soll es ab Kernel 4.14 aufwärts. Mindestens aber ab 5.10, mit dem habe ich es versucht.

Funktionell sollten am Treiber keine Änderungen passiert sein und die Karten einfach ihren Dienst tun, wie bisher.

Es wäre schön, wenn sich ein paar Tester finden, die es mit mehreren Karten gleichzeitig versuchen könnten. Das konnte ich hier nicht.

Zunächst ein eventuell hilfreicher Link zu dem Thema.

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
Da ich keine zusätzlichen Pakete installieren musste, bitte dort nochmal schauen, falls was fehlen sollte.

Für Debian / Ubuntu ist zumindest das folgende an Paketen notwendig:

sudo apt-get build-dep linux linux-image-$(uname -r)

Kurzanleitung:

Die folgenden Dateien herunterladen:

patch_neu.zip aus diesem Beitrag

https://github.com/torvalds/linux/archive/refs/tags/v6.3-rc2.zip

https://github.com/tbsdtv/media_build/archive/4fd76794ab87353ed38e0e3291c9610c4876c841.zip

Ein Verzeichnis erstellen und alles darin entpacken.

mv media_build-4fd76794ab87353ed38e0e3291c9610c4876c841 media_build

Die folgenden 3 Verzeichnisse sollten jetzt vorhanden sein:

linux-6.3-rc2 media_build patch_neu

Kernel patchen:

cd linux-6.3-rc2
patch -p1 < ../patch_neu/saa7146_vb2.diff

cd ..

Wer will, kann den Kernel 6.3-rc2 hier auch direkt bauen und verwenden. Anleitungen zum Kernelbau gibt es im Netz, Details siehe dort.

Bei mir war der aber nicht vernünftig zum laufen zu bewegen, vermutlich wegen der Nvidia Grafikkarte.

Mediabuild:

Baut die Treiber für den aktuellen Kernel.

Eine Warnung vorab:

Dieses Mediabuild ist von mir nur für diesen Test funktionsfähig gemacht worden!

Problematisches ist einfach deaktiviert, USB-DVB-Adaper gehen z.B. nicht!

Nach abgeschlossenen Tests bitte den alten Zustand wieder herstellen.

(Das betroffene Kernel-Paket erneut installieren oder entfernen.)

cp ./patch_neu/backports/* ./media_build/backports/


cd media_build
make dir DIR=../linux-6.3-rc2
cp ../patch_neu/.config ./v4l/.config
make -j4 

Module installieren:

Der Befehl installiert nach : /lib/modules/_kernelversion_/updates

sudo make install

Nach einem Reboot sollten dann automatisch die neuen Treiber benutzt werden.

Sollte es irgendwo haken oder etwas unklar sein, bitte fragen...

Die Änderungen habe es inzwischen in den Kernel geschafft:

kernel/git/stable/linux.git - Linux kernel stable tree

Mit Version 6.4 werden die saa7146-Karten also auf VB2 umgestellt sein.

Es bleiben also noch etwa 6 Wochen Fehler zu finden, bevor das passiert!

Falls jemand die USB-Treibern brauchen sollte, lässt sich das auch machen, denke ich.

Da wird eine Headerdatei nicht gefunden, das sollte eigentlich leicht behoben sein.