Tevii 464 v4l-dvb-dkms_0~20110207

Möglich, dass der Patch vergessen wurde.
Hatte ich vor geraumer Zeit mal aus dem s2-liplianin extrahiert und steffen zur Verfügung gestellt.

Der Patch ist nicht vergessen, der Patch ist noch nicht drin. Wenn man sich das Paket genau anschaut sieht man das es jetzt einen anderen Namen hat. Das Paket in testing ist jetzt vom git , media_tree gebaut mit media_build. Das ist der erste erfolgreiche Versuch und sollte genügen um zu Testen ob ich auf dem richtigen Weg bin. Für das s2-liplianin hab ich auch noch nicht alle Patches integriert. Für erste Tests für zB die Tevii S2 480 sollte es aber erstmal reichen.

Wenn es soweit ist werde ich entweder hier mach Feedback fragen oder das Paket nach stable tun.

Heißt das, dass der Patch noch integriert wird bevor es in stable wandert oder muss ich dann gegebenenfalls wieder zum s2-liplianin wechseln?!?
Würde sehr gerne beim v4l-dvb bleiben, da mantis hier subjektiv irgendwie besser unterstützt wird..

kommt alles noch ... sollte heissen: "Ist noch in Arbeit"

Danke, das beruhigt mich..
und viel Erfolg mit dem GIT, steige bei linuxtv.org sowieso nicht mehr durch.. sprich was wird gepflegt, was liegt brach

Zitat

Original von BlueVIP
was wird gepflegt, was liegt brach

Mein Eindruck ist: Das schließt sich gegenseitig nicht aus.

Gruß
hepi

linuxtv: hg ist TOT (da ist nur noch schrott drin) es lebe git. Dort gibt es zwei stellen: media_tree und media_build. media_tree ist der source code, media_build ergänzt ein paar Skripte, Patches und Makefile, so das es im Prinzip wie vorher geht.

Mit git geht schon -> siehe Paket Das heisst das ist as-of-v2.6.38....

Dadadurch das ich jetzt mit dem Code etliche Kernel weiter bin, muss ich mir halt Patch für Patch zur Brust nehmen und nachschauen was noch geht/nötig ist und was nicht. Wenn die Mantis Patche noch nicht upstream sind ist neben der 464 auch die Mantis improvements noch nicht drin.

Hab da vollstes Vertrauen in dich/euch..
Das HG "brach liegt" und GIT "gepflegt" wird, war auch mein Eindruck.. aber es steht halt nirgends..
OT: Nur zum Verständnis: media_tree ist also quasi plain und man muss sämtliche Patches, die so im linux_media-Verteiler rumfliegen selber nachpatchen?? Und selbst da hat es die S464 nie hingeschafft..

Hi steffen_b,

wäre super wenn Du ne kurze Zusammenfassung zusammenstellen würdest, wie die GIT Treiber zu verwenden sind,... sobald Du da nen ausreichenden Durchblick hast. Ich selber verwende den Kernel 2.6.35.x und bin nicht so ganz auf dem letzten Stand was die dvb-Treiber betrifft und wo man was her bekommt.
Danke schon mal.

Claus

media_tree ist plain was in den nächsten Kernel kommt. media_build enthält die patches um die Treiber auch für ältere Kernel zu kompilieren. Sachen die niemand auf die Mailingliste geschickt haben, oder Sachen die dort hingeschickt wurden aber noch nicht angeschaut, oder nicht ACKed oder oder sind da nicht enthalten.

dvbloop-s2api_v3.patch
Sollte gehen (mit 2.6.32) bis zu welchem Kernel weiss ich nicht.

s464-support.patch
Muss ich ausprobieren.

stb0899_improve-tuning.patch
Avoid-unnecessary-data-copying-inside-dvb_dmx_swfilter_204-function.patch
Mantis-DMA-transfer-cleanup-fixes-data-corruption-and-a-race-improves-perfo
rmance.patch
Weiss nicht ob upstream.

stb0899_signal_strength_v3.patch
weiss nicht ob er geht.

tt-s2-double-fix.patch
Weiss nicht ob upstream.

Ich versuche zu helfen, bin aber kein Treiberentwickler. Von sofern übernehme ich manche Patches wenn ich positives Feedback bekomme. Lieber wäre mir plain was upstream ist darin zu haben, damit man das Feedback direckt an die mailingliste geben kann wenn es Probleme gibt.

clausmuus: suche ich heute abend mal zusammen.

Ein wenig zur Geschichte was passiert ist:
http://www.linuxtv.org/wiki/index.php/News_Archive (siehe Eintrag vom 9.1.)

Dann gibt es eine gute Seite hier: http://www.linuxtv.org/wiki/in…ll_V4L-DVB_Device_Drivers

Die Kurzform ist:
- git checkout des media_tree (kompletter kernel git tree)
- git checkout des media_build (kleiner git tree der patches und Skripte enthält)
- benutzen des media_build um den media verzeichnisbaum aus ersterem git rauszukopieren (make tar)
- benutzen des tar files von eben, um es im media_build wieder auszupacken
- dann hat man etwas was in etwa dem entspricht was vorher im hg war, d.h. man kann jetzt bauen.

Abkürzung:
- nur media_build auschecken
- ./build.sh laufen lassen.

Auf http://linuxtv.org/downloads/drivers/ gibt es quasi das was make tar macht zum Download. ./build.sh läd das letzte file von dort herunter, und packt es aus. Ist für den durchschnittlichen Benutzer deutlich einfacher weil:

$ du -hs media_tree/
917M media_tree/

Vorteil mit dem media_tree checkout ist, das man sich per git dann nur die letzten Änderungen ziehen kann.

Hier wirds ungenau ... :
Wenn dann im media_build wie auch immer die Sourcen der Treiber vorhanden sind, und man make ausführt (macht build.sh auch) werden die patches für den jeweiligen Kernel applied (in media_build liegen backport patches bereit bis runter zu kernel 2.6.31) und die Treiber gebaut.

Was mache ich ?
Ich habe ein git checkout des media_tree gemacht, make tar , make untar im media_build. Das Ergebnis benutze ich als Basis für das erstellen des dkms. Um das dkms etwas flexibler zu halten, habe ich die Patches aus dem backports Verzeichnis des media_build in mein dkms getan, und auseinandergeflöht so das ich ein dkms Patch-Match Eintrag in der dkms.conf für das Paket generiert bekomme (Patch Match matcht die Kernelversion gegen diesen Ausdruck und entscheidet ob der Patch hier angewendet werden soll oder nicht) - das müsste es eigentlich möglich machen das Paket von Kernel 2.6.32 bis 2.6.38 zu benutzen und die notwendigen Patches werden von dkms bestimmt.

Zum dkms erstellen, pflege ich für mich ein Skript, was ich inklusive der verwendeten Patches hier:
https://bugs.yavdr.com/project…show/trunk/misc/make-dkms
eingecheckt habe. Das Skript basiert im Original auf einem Script von Martin Pitt, ich habe es mir auf meine Bedürnisse angepasst, und habe inzwischen ein paar Änderungen von Frederik Kriewitz übernommen (patch-match, ein bugfix beim erstellen des dkms.conf und kleinere andere Sachen)

Fallstricke:
Im der neuen Version des Treibers liegen jetzt auch die Treiber für lirc bzw dessen Weiterentwicklung rc-core . Das führt dazu das Treiber daraus mit dem installierten lirc potentiell nicht mehr zusammenarbeiten oder das es Treiber für die Hardware gibt die für das Gerät geladen werden, welche keine Lirc Treiber mehr sind. Das betrifft die gängigste Hardware: imon, mceusb und alle DVB IR Treiber sind aufs neue Framework portiert. Die ganzen rc-core Treiber sind input/event devices, nicht lirc. Die Zukunft sieht wohl so aus das lirc früher oder später obsolete wird, oder nur noch für Ausnahmen verwendet wird.

Für Leute die die dkms Pakete aus testing-vdr verwenden: ES IST NICHT HILFREICH ! testing-vdr ist in diesem Fall mehr oder weniger meine Werkbank, und es kann sein das die Pakete nicht funktionieren bis ich mal wieder Lust habe daran zu arbeiten. Wenn es etwas funktionierendes gibt, kommt das Paket frühzeitig nach stable-vdr.

Hoffe das gibt einen besseren Einblick.

Danke!
Dahab ich ja erst mal was zum lesen und abarbeiten
Ich werd mich dann wohl erst ende nächster Woche zurückmelden und berichten ob ich nun klaar sehe.

Claus