Posts by S:oren

xblades wrote:

Zumindest für dvbsddevice hab ich das patchen können

Was wäre das für ein Patch?

Danke,

S:oren

Probleme im Mietshaus habe auch erlebt, siehe oben. Im Eigenheim erwarte ich sowas nicht.

Wieviel Flexibilitaet man sich wuenscht, ist Geschmacksache, denke ich. Mancher mag vielleicht keinen Splitter-Verhau im Keller, wo die ganze Wand mit Kabeln zugepflastert ist. Moeglichkeiten gibt es wie immer viele. Und der Trend geht momentan ja eher weg von Koax-Verkabelung.

Man sollte nur keine

Angelosarikis wrote:

(T-Stücke hinter der Dose?)

verwenden, sondern richtige Durchgangsdosen, wenn man mehrere an einem Strang haben will.

Ähm, was hat diese Antwort mit meiner Frage zu tun?

PmK findet eine Strangverkabelung kompliziert, ich nicht. Es kann gegenueber einer Sternverkabelung mit Splitter im Keller nur einfacher werden.

Angelosarikis wrote:

mit einem Kabel von einem Raum in den nächsten zu gehen, scheint attraktiv, da der Verkabelungs-Aufwand gering ist und damit günstiger.

Somit stimme ich der Idee von Angelosarikis zu, will es aber nicht uneingeschraenkt empfehlen, weil ich es selbst so fuer SAT-Unicable nicht im Einsatz habe.

Wieviele Dosen man an welche Wand nagelt und ob man hinter der Dose (welcher Art auch immer) weitere Splitter installiert, ist davon komplett unabhaengig...

PmK wrote:

Ich denke von Raum zu Raum Kabel ziehen mit Splitter in jeder Dose erhöht auf jedenfall mal die Komplexität.

Warum nicht Durchgangs- und Enddosen passend installieren? Die Durchgangsdosen enthalten die Splitter quasi schon, spart ggf. 'ne Menge Kabel und Verlegeaufwand, mit einem Splitter im Keller kann man ggf. mehrere Straenge aufbauen.

Funktioniert das nur in der Theorie und hat jemand damit schlechte Erfahrungen? Bei Kabelfernsehanlagen gab es ja manchmal Probleme, wenn der Nachbar meinte, auf die Dosen noch zusaetzliche Kabel klemmen zu muessen. Im eigenen Haus passiert das ja eher nicht...

Gruss,

S:oren

nobanzai wrote:

Das Budget-Modul lässt sich allerdings nach wie vor nicht übersetzen - das brauche ich aber auch nicht.

Ich habe den Build fuer budget und hybrid im 4.12er Branch gefixt, sollte jetzt gehen.

Gruss,

S:oren

Es gibt keinen einfachen Weg, den Treiber ohne komplette Kernel-Sourcen zu bauen, da auch die Kernel-Header gepatcht werden muessen.

Wer sich da ausgefeilte Skripte oder dkms-Pakete oder was-auch-immer bauen will, darf das natuerlich gerne machen, muss aber mit jeder neuen Kernel-Version damit rechnen, dass man da wieder etwas anpassen muss. Da das Herunterladen der Kernel-Sourcen + Patchen + Bauen der Module keine 10 Minuten dauert (wenn man es nicht zum ersten Mal macht), wird man m.E. die Zeit nie wieder einsparen, die man die Entwicklung solcher Spezial-Loesungen steckt. Wer aber Spass daran hat, soll es meinetwegen gerne machen. Ich kann und moechte dafuer jedenfalls keinen Support leisten, ich selbst nutze sowieso keine Distro-Kernel auf meinen VDR- und Treiber-Entwicklungs-Rechnern. Aber auch da soll jeder nehmen, was ihm/ihr gefaellt.

Nach den Problembeschreibungen, die ich so bisher bekommen habe, haben jedenfalls viele Leute schon deutlich mehr Zeit in die Fehlersuche gesteckt, als das Herunterladen und Patchen der kompletten Kernel-Sourcen gedauert haette. Die meisten Distro-Kernel werden sowieso exakt passende Modul-Versionen fordern, evt. sogar signierte Module. Wie das bei SuSE aussieht, weiss ich allerdings nicht. Die letzte von mir genutzte SuSE-Version war 9.3 ...

Gruss,

S:oren

kamel5 wrote:

Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

Koennte man so sagen, exakt 95 Patches...

nobanzai wrote:

Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war.

Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.

Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.

Gruss,

S:oren

Freut mich, dass es hier eine relativ einfache Loesung gibt.

Gruss,

S:oren

Es ist natuerlich immer eine gute Idee, "meinen Original-Kernel" aus dem Repo zu testen, wenn es Probleme mit dem Treiber gibt. Leider hat jede Distri da so ihre eigenen Tuecken.

Mittelfristig sollte ich wahrscheinlich das request_mem_region/ioremap in das neuere devm_ioremap aendern. Es waere mir allerdings neu, wenn es "oldstyle" nicht mehr funktioniert.

Vielleicht findet sich ja noch eine einfache Erklaerung. Ansonsten ist leider 'git bisect' angesagt...

Gruss,

S:oren

Sieht erstmal nicht verkehrt aus. Nur dass "SAA716x Core" eben nicht geladen ist.

Der Speicher ist im Prinzip da und nicht anderweitig belegt.

Ich habe im Moment keine weitere Idee...

Gruss,

S:oren

S:oren wrote:

Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

Steht in /proc/iomem etwas dazu? Bei mir sieht das so aus:

kamel5 wrote:

Kann das an zu alter Hardware liegen?

Eher nicht. Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

kamel5 wrote:

Was nutzt Du da für eine Hardware-Basis?

Immer noch die.

Gruss,

S:oren

kamel5 wrote:

Deshalb die Frage in die Runde, funktioniert bei Jemanden die TT6400 in Verbindung mit Kernel 5.1.x.

Laeuft bei mir mit 5.1.6.

kamel5 wrote:

BAR0 Request failed

Hier klappt schon das allererste Mappen des PCIe-Speichers nicht. Da wird noch nichts Karten-spezifisches gemacht.

Im Moment keine Ahnung, was da nicht klappt.

Gruss,

S:oren

kls wrote:

Nicht Skins, sondern OSD-Implementierungen.

Ja, nur das ergibt Sinn. Wie ist dann aber

kls wrote:

in SkinFlatPlus die Funktion MaxPixmapSize implementieren und einen beliebigen Wert, der für deine Zwecke groß genug ist, zurückgeben

zu verstehen?

kls wrote:

Wenn keiner was dagegen hat kann ich gerne diese Änderung machen

Zumindest von mir wird es da keinen Einspruch geben.

Gruss,

S:oren

Mein Verstaendnis mal zusammengefasst:

Der Raspi hat ein Problem mit surfaces grosser als 2048x2048 bei hardware-beschleunigtem OSD. Bei der simpelst moeglichen Implementierung im Ausgabedevice duerfen dann Pixmaps auch nicht groesser sein. Daraufhin legt der vdr-Core willkuerlich diese Aufloesung als Obergrenze fuer sein Software-OSD fest. Skins duerfen diese Grenze aber aendern!?

Nun reichen 2048x2048 nicht mal mehr fuer die sichtbare Bildschirmaufloesung. Dann legt man wieder willkuerlich 4096x4096 fest, unabhaengig von den tatsaechlich vorhandenen Ressourcen im System, womit weder den eventuellen Erfordernissen im Ausgabedevice (die meisten nutzen die Software-Implementierung, die nur durch den vorhandenen Hauptspeicher begrenzt ist, und nur fuer die gilt dieser Wert), noch den Wuenschen eines Skin gedient ist.

Bin ich der Einzige, der das absurd findet?

Gruss,

S:oren

OleS wrote:

und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches

Auf den ersten Blick ist das, was unter linux-4.15.0/ liegt, dann identisch zu dem (und genauso "kaputt"), was ich oben mit dem

S:oren wrote:

tar xjf /usr/src/linux-source-4.15.0.tar.bz2

ausgepackt hatte. Aber wie immer gibt es mehr als einen Weg zum Ziel.

Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...

Gruss,

S:oren

S:oren wrote:

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Anscheinend ist bei Ubuntu alles anders, ich "liebe" diese Distribution. Jedenfalls sehe ich auch, dass eine installierte Ubuntu-linux-source in Version 4.15.0-48.51 sich selbst als 4.15.18 bezeichnet. Gruselig.

Folgendes Vorgehen

ergibt zumindest mal saa716x-Module, die sich unter einem Kernel 4.15.0-48-generic laden lassen.

Leider (oder zum Glück?) habe ich keinen Ubuntu-Rechner mit S2-6400. Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste...

Gruss,

S:oren

Es ist fuer mich schwer nachzuvollziehen, welche Sourcen Du genau wie installiert hast.

Fakt ist, die Module sagen (auch die neu generierte config), es waere ein Kernel 4.15.18. Das wird dann auch so sein.

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Ich weiss auch nicht, wie man bei Ubuntu die Kernel-Sourcen richtig installiert, da muss es aber doch Anleitungen geben!? Falls sonst niemand eine Idee hat, kann ich das heute Abend (?) mal ausprobieren...

Gruss,

S:oren

Luwex wrote:

und dann eben von Hand zurück ändern.

Das wird nicht helfen. Es hilft nur, nicht nur die richtige config, sondern auch die richtigen Sourcen zu verwenden...

Du hast den Treiber anscheinend mit einem Stable-Kernel 4.15.18 gebaut, und noch den Distro-Kernel 4.15.0-48-generic laufen.

Ich kann nur immer wieder den Hinweis wiederholen, die 2 verschiedenen Wege zum Bauen und Nutzen des Treibers (Mainline/Stable- oder Distro-Kernel) nicht zu vermischen...

Gruss,

S:oren