DigitainerII mit Scart nur schwarz/weiss

[ofenheizer]

Guten Abend,

so, habe mir nun zu Bastelzwecken auch mal nen DigitainerII (MD91888) gegönnt. Alle Karten raus und Netzwerkkarte rein (streamdev-client) und das Spezial-ISO installiert und alles läuft (X10-Fb geht auch).
Aber: Ich habe nur ein Bild in schwarz/weiss. Beim Booten ist noch alles "bunt" bis zu einem gewissen Zeitpunkt beim Laden. Da wird der blaue Fortschrittsbalken und der Rest farblos.

Hat jemand, der den DigitainerII am Scart-Anschluss betreibt, nen Tipp oder auch mal die Bios-Werte? Hab da auch schon etwas rumprobiert (RGB, CVBS).


Danke und Grüße
Markus

[manu]

hoi markus,

ist bei mir das aller gleiche! aber mit s-video stimmt die farbe.
meine mal irgendwo gelesen zu haben, dass am scart farben vertauscht sind.

gruß manu

[wbreu]

Servus Markus, servus Manu,

meine Erfahrungen zu dem Thema, alle Einstellungen im Bios durchgetestet, immer das gleiche Ergebnis:

Ab dem Zeitpunkt des Ladens des viafb-Moduls ändert sich die Farbe des Monitor/TV-Bildes in SW. Deshalb meine Vermutung es liegt am viafb-Modul und dessen Konfiguration.

Gruß
Wolfgang

[ofenheizer]

Servus Markus, servus Manu,

meine Erfahrungen zu dem Thema, alle Einstellungen im Bios durchgetestet, immer das gleiche Ergebnis:

Ab dem Zeitpunkt des Ladens des viafb-Moduls ändert sich die Farbe des Monitor/TV-Bildes in SW. Deshalb meine Vermutung es liegt am viafb-Modul und dessen Konfiguration.

Gruß
Wolfgang

Hallo Wolfgang,

danke für die Info. Heisst also vorerst den Fernseher über SVideo anzuschliessen bis sich da was ändert.

Gruss
Markus

[stb]

Hallo,

Farbe am Scart funktioniert wunderbar, allerdings nur, wenn man am Fernseher einen Anschluss nimmt, der kein RGB kann.

Gruß
Stephan

[ofenheizer]

Hallo,

Farbe am Scart funktioniert wunderbar, allerdings nur, wenn man am Fernseher einen Anschluss nimmt, der kein RGB kann.

Gruß
Stephan

Na das ist doch mal ne positive Aussage. Leider haben meine beiden Testgeräte hier in der WG nur jeweils einen Scartanschluss ... und dem Bild nach, können beide RGB  ;D

Gruss
Markus

[Schrauber]

Ich bin auch auf dieses Problem gestoßen, nachdem ich den Digitainer nun am TV habe.
Offenbar scheint es aber wirklich mit dem Treiber zusammenzuhängen. Das Bild wird schwarz/weiß mit leichtem Grünstich, genau wenn der Treiber geladen wird.
Hat da inzwischen jemand was neues dazu?

S-Video ist auch ne komische Geschichte. bei mir sieht das Bild dann grisselig aus. Sehr eigenartig.
Komischerweise sieht das Bild über Composite sehr gut aus. Eigentlich besser, als es bei Composite sein dürfte. Sehr scharf und kein Übersprechen der Farben.

[wbreu]

Hallo @all

unser Kollege Schrauber hat eine Lösung gefunden wie man auf dem Digitainer via Scart astreines RGB auf den SCART zaubert:

http://www.vdr-portal.de/board/thread.ph...r=0&page=3

Dazu braucht man das tool vt1622 das in den linux-viafb-Treibern zusätzlich drinnen ist.

Gruß
Wolfgang

[Schrauber]

Ähm jo.
Heute abend kommt ein Patch.
Nachteil der Geschichte: Dann geht nur noch RGB.
Sollte für einen produktiven VDR kein Thema sein. Aber irgendwie blöd ist es trotzdem. Besser wäre eigentlich, wenn man es dem Treiber als Parameter mitgeben könnte. Ich hab mal in den viafb-Treiber rein geschaut. Aber meine C-Kenntnisse reichen da bei weitem nicht aus. D.h. ich blick nicht durch.
Der Patch wird nur die Init-Tabelle ändern. Das krieg ich noch hin. Aber für mehr Erweiterungen reichts bei mir einfach nicht.
Sollte sich also hier einer finden, der sich mit Treiberprogrammierung auskennt, dann können wir uns gerne zusammentun.

Grüße

[wbreu]

Hallo schrauber,

eine Möglichkeit wäre ja auch, mit zwei unterschiedlichen Modulvarianten der viafb.ko zu arbeiten.

Modul A = normale Version mit S-Video und Chinch
Modul B = angepasste Version für RGB über den Scartausgang

Das jeweilige Modul bräuchte nur einkopiert werden und danach ein depmod mit Reboot das sollte reichen.

Die andere Variante wäre mit dem vt1622 und den jeweiligen Codes (Eingaben) danch den RGB im laufenden Betrieb umzustellen. Hätte halt den Charme dass man dann den Originalsource nicht patchen müsste.

Mal schauen was da geht.

Gruß
Wolfgang

[Schrauber]

Jo, an zwei Module hatte ich auch schon gedacht. Das geht klarerweise immer.
Da dürft Ihr Euch was ausdenken ;-)
Ich bin ja nicht mehr auf EasyVDR. Ich hab den VDR inzwischen unter Archlinux. Nicht, weil EasyVDR schlecht gewesen wäre. Das auf keinen Fall. Arch ist mir einfach übersichtlicher und vor allem schneller, weil schlanker. Hab halt nur das unbedingt nötige drauf. Egal, das ist hier nicht das Thema.

Die Möglichkeit über das vt1622-Tool ist halt eine rein manuelle. Ist halt auch irgendwie nervig, wenn man immer erst von Hand umstellen muss. Zum Testen ist es klarerweise ideal.
Oder hast Du eine Möglichkeit gefunden, dem vt1622 per Parameter mitzugeben, was es tun soll?

[Schrauber]

So, hier nun der Patch. Siehe hier:
http://www.vdr-portal.de/board/thread.ph...post621899

[wbreu]

Hallo Schrauber,

also dem vt1622 Parameter mitzugeben kann man vergessen. Hab mal die Sourcen gesichtet => keine Chance.

Bleibt also nur Variante 1 mit den geänderten Sourcen des viafb-Moduls und neukompilieren, ich dokumentier das mal was notwendig ist, dann gehts auch ohne Patch.

Also die linux-viafb-treiber liegen normalerweise in /usr/src und sind mit dem kpatch in den Kernel gelinkt (d.h. siehe Readme make kpatch-link).
Das ist normalerweise in easyVDR schon gemacht.

Vorher unbedingt das Modul viafb.k unter /lib/modules/2.6.18.3/extra wegsichern. Kann später wieder mit einkopieren und dem Befehl depmod -ae eingebunden werden, falls man wieder S-Video oder Chinch braucht.

1. Dann gehts los mit den Anpassungen:
1.1 cd /usr/src/linux-viafb
1.1 Befehl make clean => auf der Konsole

2. Die Datei via_vt1622a.h in /usr/src/linux-viafb/linux/drivers/video/cle266 ändern, die Zeile 350 /* TV regs suchen:
    Zeile 351  Code ( 0x04, 0x00, 0x00, ...) ändern in ( 0x04, 0x00, 0x22, ...)
    dann abspeichern

3. cd /usr/src/linux-viafb

4. make

5. make install

6. Reboot machen und natürlich sollte jetzt am Scartausgang des Digi der TV via Scartkabel verbunden sein.

Jetzt gibts astreines RGB, meiner Meinung nach absolut sauber, vergleichbar mit einem AV-Board einer FF.



Manuel kann man das auch testen, wenn man das tool vt1622 kompiliert.
Das geht so:

1. cd /usr/src/linux-viafb/utils 
2. make (das wars schon)

Wenn man jetz auf der Konsole vt1622 eingibt kommt das Hilfsprogramm und fragt ab:

C
02
0x22
q
q

wären dann die Eingaben um das Register auf RGB-Ausgabe am Scartausgang des Digis umzuschalten.

Gruß
Wolfgang

[Schrauber]

Hallo wbreu,

die tv3.h muss nicht geändert werden. Wenn ich das richtig im Source interpretiere, dann kommt die nur beim VT1621 zu Einsatz. Und der kann eh kein RGB. Für den VT1622 ist nur die vt1622a.h da. Die zu ändern reicht also.

Oder hast Du da andere Erkenntnisse?

Grüße

[wbreu]

Hallo schrauber,

ich habe da gestern abend noch ein bisschen rumgespielt und bei mir hat er erst umgeschaltet als ich auch diese Änderung eingearbeitet habe.

Dann neu compiliert und viafb.ko eingebunden.

Mal schauen was andere für Ergebnisse haben ???

Gruß
Wolfgang

[Schrauber]

Eigenartig. Bei mir reicht die Änderung im vt1622a.h

Was einen Schalter angeht:
In den Includes stehen ja im Prinzip die kompletten Init-Tabellen für verschiedene Modi. Man müsste die eigentlich um einen zusätzlichen Modus erweitern. Eben RGB. Und das ganze so verdrahten, das er die neue Init-Tabelle nimmt, wenn man z.B. TVon=2 mitgibt oder sowas. Quasi TVon=1 (wie bisher) für CVBS und S-Video. Und TVon=2 dann für RGB. Zu machen muss das ja eigentlich sein. Gibt ja schließlich noch mehr Parameter. Aber wahrscheinlich wären die Änderungen recht umfangreich.
Und ich blick nicht ganz, wie der die Init-Tabellen da verwurschtelt. Aber bei C in Linux-Treiber hatte ich nie nen Durchblick. Auch mangels Zeit. C auf Mikrocontrollern ist mir irgendwie einfacher. Das mach ich ständig.

[wbreu]

So habe nochmal neue Sourcen gezogen und nur die vt1622a.h geändert.

Das reicht, danke für den Hinweis.

Gruß
Wolfgang

[Schrauber]

Anscheinend will Morone nochmal schauen, ob sich im Treiber was machen lässt, wegen einem Kernelparameter. Vielleicht kriegen wir es blad perfekt ;-)

Oh, der Digitainer stellt sich irgendwie immer mehr als idealer VDR heraus.

[Alextronic]

Hallo,

ich bin gestern wiedermal gescheitert den Kernel neu aufzusetzen und konnte somit auch das Modul "fiafb.ko" nicht neu kompilieren.. Bevor ich jetzt meine bessere Hälfte gänzlich verärgere  ... wäre jemand so freundlich und sendete mir das fertige auf RGB gepatchte Modul (HW: Digitainer II).

Danke!

Gruß
Alex

[Alextronic]

Hallo!

Ginge das Austauschen der Datei "viafb.ko" überhaupt, also ohne zu compilieren und natürlich vorausgesetzt die HW stimmt überein? 

Gruß
Alex

[Schrauber]

Ja, das ginge. Aber nur, wenn das Modul mit dem passenden Kernel kompiliert wurde.
Ich kann Dir da nicht weiter helfen, weil ich inzwischen auf Archlinux mit Kernel 2.6.21 bin. EasyVDR hat m.W. noch Kernel 2.6.18.

[tekbaron]

Einen wunderschönen guten tag,

Hat zufällig schon jemand das viafb.ko fertig zum download ?, son grüner VDR ist nicht wirklich hübsch ;(

Ich mühe mich ab das ding zu übersetzen bekomme aber leider immer nur diese Meldungen.

Code:

easyVDR:/usr/src/linux-viafb# make
make -C /lib/modules/2.6.18.3/build SUBDIRS=/usr/src/linux-viafb/linux/drivers/video/cle266 CONFIG_FB_CLE266=m modules
make[1]: Entering directory `/usr/src/linux-2.6.18.3'
  CC [M]  /usr/src/linux-viafb/linux/drivers/video/cle266/via_fbobj.o
  CC [M]  /usr/src/linux-viafb/linux/drivers/video/cle266/via_fbaccel.o
  CC [M]  /usr/src/linux-viafb/linux/drivers/video/cle266/via_i2c.o
  LD [M]  /usr/src/linux-viafb/linux/drivers/video/cle266/viafb.o
  Building modules, stage 2.
  MODPOST
/bin/sh: line 1: scripts/mod/modpost: Datei oder Verzeichnis nicht gefunden
make[2]: *** [__modpost] Fehler 127
make[1]: *** [modules] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.18.3'
make: *** [viafb] Fehler 2
easyVDR:/usr/src/linux-viafb#

[wbreu]

Servus tekbaron,

hast du die Kernlesourcen ancompiliert mit "make" und dann abgebrochen.

Das ist unbedingt notwendig um weitere Treiber dagegenzubauen!?

Gruß
Wolfgang

[tekbaron]

Ahhh da währe ich jetzt ums verrecken nicht drauf gekommen, werd ich gleich mal testen.

THX

[prudentis]

@wbreu,

sinnvoller wäre es, wenn mann ein:

Code:

make oldconfig && make prepare && make scripts

macht, anstelle abrechen des Kompilierens.

Da mann sonst, wenn mann wirklich mal den Kernel Kompilieren will, erst ein "make clean" machen muss, sonst Kompiliert er dort weiter wo mann abgebrochen hat !

UND WER DENKT SCHON DARAN WAS GESTERN WAR 


lg prudentis