Digitainer mit 0,5RC1 und Scart-RGB?

[john]

Hallo Schrauber,

vielen Dank für die Info.

Ich hoffe, Du meinst auch Artefakte. Im Sinne von den typischen MPEG-Blockmustern

Ja, die meine ich.

Es ist davon auszugehen, das die Artefakte bereits im Ausgangsmaterial vorhanden sind.

Ja, das glaube ich auch!

Weiterhin kann es auch sein, das der Grund Dein TV-Gerät ist

Schätze, damit hast du recht. Ist ein BenQ 3250 32 Zoll LCD.

Hatte auch noch vor ein VDR mit Radeon 9250 incl DVI Out am BenQ testhalber zu betreiben (Der BenQ hat DVI, mit XP ein Sahnebild bei voller nativer Auflösung ohne jegliche Skalierung durch den BenQ). Mal sehen ob das noch was bringt.

Aber noch mal ne Frage zur Videomodeumschaltung. Habe bei laufenden VDR über OSD-Konsole das Register für SVideo gesetzt. Habe dann eine Ausgabe über SVideo. Bild klar besser als CVBS. Wenn ich dann eine Aufzeichnung wiedergebe schaltet der VDR wieder auf RGB und CVBS um, so wie viafb wohl gepatcht ist. Wäre das nicht der Fall, wenn man dem viafb per Parameter den Videomodus mitgeben könnte und weißt du ob da schon jemand dran ist?

Wäre dann ne saubere Sache. Oder ist es sinnvoll das über ein Plugin zu lösen. Dann könnte es sich jeder selber einstellen.

Klar ist das Bild bei RGB-Ansteuerung am besten. Bei Action oder Horrorfilmen mit hohem Anteil dunkler Filmszenen stört es mich aber schon, immer diese Blockartefakte zu sehen. Da ist das Bild zur Zeit über SVideo der Kompromiss zwischen Bildschärfe und Blockdarstellung bei dunklen Szenen.

Werd mir mal ein Komponentenkabel zusammenlöten und alternativ nen VDR mit Radeon via DVI am Panel betreiben.

John

[Schrauber]

Wie gesagt, ich glaube nicht, das Komponente etwas bringt. Allerdings, wenn es tatsächlich so ist, das Dein TV bei RGB-Einspeisung die Filter umgeht und bei Komponente nicht, dann könnte es wieder was bringen.
Bei manchen TV-Geräten kann man die Filterkonfiguration auch für jeden Modus einzeln festlegen. Oder auch für jeden Eingang.
Also am besten nochmal die Menüs des TV durchforsten. Bei unserem Philips z.B. kann man die Filterkonfiguration und Bildeinstellungen für jeden Eingang einzeln festlegen. Bei anderen Geräten geht sowas pro Modus. Bei unserem gibts auch einen speziellen Artefaktfilter. Wenn man nun einen Eingang erwischt, wo man den Artefaktfilter abgeschaltet hat, dann sieht man das.

Was die Umschalterei angeht:
Der Patch für den viafb stammt ja von mir.
Es ist so, das der viafb feste Paramtertabellen verwendet. Ich hab einfach in der Parametertabelle für 720x576noscale das Register für den Modus auf RGB geändert. Fertig. Besser wäre natürlich, wenn man dem viafb per Modulparameter den gewünschten Modus mitteilen könnte. Für diese Änderung reichen aber meine C-Kenntnisse nicht aus. Deswegen die einfachere Variante.

Das der Modus zurückgesetzt wird, wenn Du z.B. MPlayer startest oder so ist klar. Dabei wird der Videomodus neu initialisiert. Somit wird wieder die originale Inittabelle aus dem viafb geladen und Deine Änderungen an den Registern einfach überschrieben.

An der Modusübergabe direkt ans viafb-Modul ist anscheinend niemand dran. Wie gesagt, ich selber kanns nicht. Ich hatte mal in die Sourcen reingeschaut. Aber musste dann passen.

[john]

Danke,

werd mal meine TV-Menus untersuchen. C ist bei mir auch schon lange her (ca 10 Jahre), unter Linux noch nie, aber ich werd mal mein Glück versuchen. Bin gerade dabei mein erstes Plugin zu erstellen. Mal sehen, ob da was brauchbares rauskommt!

John

[Gummibaer]

Moin,

ich habe folgenden merkwürdigen Effekt bei meinem Digitainer.
Wenn ich den Digitainer mit dem Power On Knopf starte, erhalte
ich ein deutlich dunkleres Digitainer Startlogo und die
Konsolenmeldungen sind ebenfalls deutlich dunkler.
Sobald der VDR startet und auf Terminal 10 umgeschaltet wird,
verschwindet das Bild völlig, der Ton funktioniert.
Auch auf den Konsolen 1 - 4 ist keine Ausgabe mehr vorhanden.
Nach dem Affengriff (CTR-ALT-DEL) erscheinenen das Digitainer
und die Konsolenausgabe in normaler Helligkeit und das Fernseh-
bild wird in guter Qualität ausgegeben.
Umschalten auf ALT F1 - ALT F4 und ALT F10 funktioniert ebenfalls.

Die Scart Verkabelung ist wie folgt:

- vom Digitainer über den Digitalreceiver zum Fernseher, einem
  17 Jahre alten Löwe 50Hz Röhrenfernseher

Installiert habe ich die folgenden Pakete bzw. Distributionen

- easyVDR_042_bp_144_digitainer.iso   
- digi-setup-beta3.tar.bz2
- digitainer-setup.sh

Dieses Verhalten ist unabhängig von der Bios Einstellung für
TVout.
Hat vielleicht irgendwer Tipps, wie ich mit der Fehlersuche
weitermachen kann?
Per ssh ergibt sich nach dem CTRL-ALT-DEL reboot folgende
fbset Ausgabe:


easyVDR:~# fbset -i

mode "720x576-50"
    # D: 28.000 MHz, H: 31.250 kHz, V: 50.000 Hz
    geometry 720 576 720 1152 32
    timings 35714 32 8 46 0 136 3
    bcast true
    rgba 8/16,8/8,8/0,8/24
endmode

Frame buffer device information:
    Name        : UNICHROME
    Address    : 0xe4000000
    Size        : 33288192
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 0
    YPanStep    : 1
    YWrapStep  : 0
    LineLength  : 2880
    MMIO Address: 0xe8000000
    MMIO Size  : 16777216
    Accelerator : Unknown (77)

[Gummibaer]

Im Rahmen meiner Fehlersuche habe ich
die Registerinhalte des VT1622A mittels
- /usr/src/linux-viafb/utils/vt1622
ausgelesen und dabei folgende Unterschiede
zwischen Power On (kein TV Bild) und Reboot
(TV Bild oK) festgestellt.


TVRegs      0x65  0x66  0x67
----------------------------
Power on    0x00  0x80  0x81
Reboot      0x82  0x00  0x00

CRTCRegs    0x0c  0x34  0x4d 
-----------------------------
Power On    0x80  0x0c  0x00
Reboot        0x00  0x00  0x04

Die dmesg unterscheiden sich im Gut- und Schlechtfall
übrigens nicht.
Außerdem ist mir aufgefallen, daß in
- /etc/init.d/RCStart
Zeile 303
- (execute /etc/init.d/udev-mtab start) &
statt
- (execute /etc/init.d/udev.mtab start) &
lauten muss.
Ausserdem existiert das in
- /etc/init.d/RCStart
aufgerufene Startskript
- /etc/init.d/discover
nicht.
Dies hat mit dem geschilderten Fehler zwar nichts zu
tun, ich wollte es nur der Vollstaendigkeit halber
erwaehnen.


Wo kann man eigentlich Datenblaetter fuer den VT1622A und
die uebrigen Komponenten des VIA Chipsatzes bekommen?
Ich habe weder bei VIA noch per Google welche gefunden.

Noch eine kleine Korrektur:
Ich habe das
- easyVDR 0.5_RC1.iso
mit den Patches
- digi-setup-beta3.tar.bz2
- digitainer-setup.sh
und nicht wie im vorigen Posting geschrieben das
-easyVDR_042_bp_144_digitainer.iso
installiert.

[japio]

Hallo gummibaer,

Die erfahrung dass der digitainer 2 erst nach einem reset richtig bild gibt hab ich auch schon gemacht.

als ich dann ein reset schalter angeschlossen hab am motherboard und diese sofort nach einschalten gedrueckt hab war bild in ordnung.
Vieleicht hilft dass?
Ich muechte auch dass er normal funzt und nicht erst nach einen reset.

Gruss,
Jaap

[Gummibaer]

Mir ist aufgefallen, daß im Startskript
- /etc/init.d/RCStart
einige Skripte, unter anderem das Laden der Module, in einer
Subshell im Hintergrund passiert, vermutlich um den Bootvor-
gang zu beschleunigen.
Ich werde nachher das Startskript entsprechend ändern und
schauen, ob der Fehler weg ist.
Beim Untersuchen des viafb Sourcecode ist mir ausserdem
aufgefallen, das der Chip nur teilweise initialisiert wird.

[Gummibaer]

Ich werde nachher das Startskript entsprechend ändern und
schauen, ob der Fehler weg ist.

Der Fehler ist immer noch da und das Booten dauert deutlich laenger.
Durch das langsamere Booten weiss ich nun auch, wann genau beim Kaltstart
das Bild verschwindet.
Sobald das viafb Modul geladen wird, registriert es sich als Framebuffer Device
mittels der entsprechenden Kernelfunktion
- register_framebuffer
In den dmesg erscheint daraufhin noch die Meldung
- Console: switching to colour frame buffer device 90x36
und das wars dann beim Kaltstart.
Das Fehlerverhalten bleibt uebrigens auch beim Auskommentieren der startvdr Befehls.
Dies bestaerkt mich in der Vermutung, daß der Chip nicht korrekt initialisiert wird.

[Gummibaer]

Im Rahmen meiner Fehlersuche habe ich auch den viafb Treiber untersucht.
Bisher habe ich beispielsweise die section mismatch Warnings ausgebaut.
Ein potentieller Fehler in der getMemory Funktion ist durch das entfernte
__initdata Attribut des memory Parameters dadurch schon entfernt.
Das Anmelden des viafb Devices beim Framebuffer Subsystem des Kernels
werde ich an das Ende der pci_probe Routine verschieben, damit der VT1622
durch die setmode Routine komplett initialisiert ist, bevor das Framebuffer
Subsystem des Kernels darauf zugreift.
Vielleicht löst das ja auch mein Problem. Ich werde erst heute Abend oder Morgen
zum Testen kommen.
Wenn Interesse besteht, kann ich bei der Gelegenheit versuchen, eine Umschaltung
zwichen der gepatchten und ungepatchten Version durch den Parameter TVon = 3
einzubauen.

[Gummibaer]

Ich wollte nur mal einen kurzen Zwischenbericht geben.
Mittlerweile habe ich alle Warnungen aus dem viafb Treiber ausgebaut
und ihn an die geänderte API des 2.6.22 Kernels angepasst(via_fb_write
und via_fb_read).
Ich habe auch die Reihenfolge der Initialisierung und der Anmeldung am
Framebuffer Subsystem geändert.
Leider alles ohne Erfolg.
Mittlerweile bin ich der Meinung, daß es ich um ein BIOS oder Hardware Problem
handelt, und zwar aus folgendem Grund:

- Kaltstart
- F11 , Passwort am8888egh
- Biosmenüs sind relativ dunkel
- keine Äderung vornehmen und BIOS verlassen
- Rechner startet neu
- Konsole kommt mit der richtigen Helligkeit, Bild ist OK

Das heißt, ohne daß irgendwelche Betriebssystem Software ausgeführt wird,
verändert zweimaliges Starten das Verhalten des Grafikchips.
Entweder initialisiert das BIOS den Chipsatz nicht vernünftig oder der Hardware Reset oder
das Power Sequencing läuft nicht vernünftig.
Ich tippe auf ein Hardware Problem.
Da mir momentan nichts mehr einfällt, werde ich mir halt angewöhnen, den Digitainer nach dem Einschalten über die Tastatur mittels CTRL-ALT-DEL zu rebboten.

[japio]

Hallo Gummibaer,

Ich hab auch vermutung dass da im bios oder hardware wass schief laeuft.

Ich werd mal versuchen dass powergood signal vom netzteil zu verzoegern, oder reset anzuhalten, damit ein automatisches einschalten functioniert.

Allerdings kommen solche probleme mit der original soft (wi***ws) nicht vor.

Also muss es doch moeglich sein die chips richtich zu initialisieren.

Vielleicht der grafik chip und nicht der TV chip?

Gruss,
Jaap

[Gummibaer]

Ja, diese Vermutung habe ich auch schon gehabt, daß durch die Programmierung des eigentlichen
Grafikchips die fehlerhafte BIOS Programmierung ausgebügel werden könnte.
Ich hab noch nicht herausbekommen, ob und in welchem Maße der Linux Kernel dort entsprechende Initialisierungen vornimmt.
Da der VT1622 per I2C bzw. Registerzugriffe programmiert wird, der viafb Treiber sich aber als PCI  Device anmeldet, vermute ich, daß dies der eigentliche CLE266 Chip ist. Und dieser Chip wird zumindest teilweise durch den viafb Treiber mit initialisiert.
Leider findet man auf der VIA Homepage nur mehr oder minder belanglose Informationen.
Vielleicht lässen sich aus dem Source Code des Grafiktreibers von VIA noch einige Hinweise heraus finden.
Ich werde das Problem erstmal durch Reboot lösen, nicht schön aber es geht.
Vielleicht werde ich mit dem eigentlichen Treiber weitermachen, wenn ich mehr Zeit habe.
   

[Schrauber]

Hallo,

das ist sehr dubios.

Ich hab auch einen Digi 2. Allerdings den, den es später als Restposten gab.
Solche Probleme kenn ich gar nicht.
Ich hab ne Zeit lang EasyVDR drauf gehabt. Damals noch die 4er Reihe. Das ging ohne Probleme.
Jetzt läuft mein Digi unter Archlinux. Ebenfalls hab ich die beschriebenen Probleme nicht.

Wann wird bei der aktuellen EasyVDR das viafb-Modul denn geladen?
Ich hab es bisher immer direkt in der Kernel-Commandline mitgegeben. Das hat immer funktioniert.
Im Bios hab ich RGB-SDTV eingestellt. Wobei die Einstellung nur Auswirkungen hat, bis viafb geladen wird.

[Gummibaer]

Moin,

ich habe sowohl versucht den viafb Treiber in der Kernelkommandozeile zu booten, als auch,
wie vom /etc/init.d/RCStart Skript vorgesehen, mittels /etc/module-init-tools.
Im BIOS habe ich auch alle Kombinationen der TVOut Einstellung durchprobiert.
Gestern hatte ich noch den verkürzten Power On Self Test disabled, in der Hoffnung,
das der Chipsatz eventuell dadurch später vom BIOS initialisiert wird.
Ergebnis war, das ich das BIOS per JBAT1 Jumper resetten musste, weil der DIGITAINER
mit dem Startlogo stehen bleibt.
Ich werde heute abend versuchen, die /boot/grub/menu.lst so zu verändern, daß der Rechner bootet,
und grub dann einen Reboot und Neustart des eigentlichen Kernels durchführt.
Laut grub Doku sollte das über die Einträge defaut saved, savedefault und reboot funktionieren.
Denn wie schon geschrieben, reicht es beim Starten über F11 ins BIOS zu gehen und dieses ohne Änderungen
wieder zu verlassen.
Der Chip benötigt anscheinend einen Reboot.
Dies war übrigens nicht immer so, dieser Effekt ist mir aufgefallen, nachdem ich das Scartkabel nicht mehr
über einen zwischengeschalteten Videorekordern sonder direkt über den Digitalreceiver an den Fernseher
angeschlossen habe. (Fernseher hat nur einen SCART Eingang).

[Schrauber]

Aha, das ist ja erstaunlich. Es scheint offenbar mit dem Scartanschluss zusammenzuhängen.

Ich habe meinen Digi direkt am TV hängen. So ein Problem gabs noch nie.
Ich hab ihn bisher an zwei verschiedenen TVs gehabt. Der eine ein LCD, der andere ne ältere Röhre.

Du sagst, er hängt an nem Receiver. Wie ist es denn, wenn der Digi direkt am TV hängt? Nur mal testhalber.

Es kann durchaus sein, das der Chipsatz auf die Last am Scart reagiert. Der Receiver ist erstmal keine Last, solange er den Scart nicht durchschaltet.

[Gummibaer]

Der Receiver schaltet im Stand By seinen externen Anschluss durch, das heisst, daß
beim Start des Digitainers der Anschluss eigentlich durchgeschaltet sein sollte.
Ich weiss allerdings nicht, ob die Last des Receivers identisch mit der des Fernsehers
ist.
Die Umschaltung im Receiver zwischen externer (Digitainer) und eigener Signalquelle
(Tuner) wird ja vermutlich über ein entsprechendes Multiplexer IC mit entkoppelten
Eingängen erfolgen.
Soweit ich weiss, sind die Eingangsimpedanzen und Innenwiderstände der SCART Anschlüsse
zwar genormt, aber vielleicht unterscheiden sich die SCART Anschlüsse zwischen TV und Receiver
ja doch.
Mal sehen, wenn ich die Verkabelung auseindergedröselt bekomme, werde ich, wie
von Dir vorgeschlagen, den Digitainer mal direkt anschliessen.

[Gummibaer]

Ich habe jetzt durch folgende

- /boot/grub/menu.lst

--------------------------- schnipp ----------------------------------------------

timeout        5
color white/green black/green
default saved

###splashimage=(hd0,2)/boot/grub/splashimages/debsplash.xpm.gz
splash=verbose

title          Debian GNU/Linux, kernel 2.6.22.1
root            (hd0,2)
savedefault 3
kernel          /boot/vmlinuz-2.6.22.1 root=/dev/hda3 ro acpi=on pci=routeirq

title          Debian GNU/Linux, kernel memtest86
root            (hd0,2)
savedfault 3
kernel          /boot/memtest86.bin

title          PowerOff
root            (hd0,2)
savedefault 3
# kernel                /boot/bzImage.poweroff
halt

title          Reboot
root            (hd0,2)
savedefault 0
reboot

-------------------------- schnapp ----------------------------------------------

erreicht, daß beim Booten des Digitainers ein Reboot durchgeführt wird.
Damit ist, wie schon beschrieben, das Bild ok.
Damit sind zwar die Symptome statt der Ursache behoben aber es
funktioniert.

Der VT1622A und auch andere TVEncoder können durch Messen der
Analogpegel während der vertikalen Austaslücke feststellen, ob 
die DAC Ausgänge durch den angeschlossenen Fernseher impedanzmäßig
korrekt  abgeschlossen werden.
Das Ergebnis kann aus entsprechenden Registern ausgelesen werden.

Da mein Digitainer per zwischen geschaltetem Digitalreceiver angeschlossen
ist, wird möglicherweise der angeschlossene Fernseher nicht richtig erkannt.
Die nötige testweise Umverkabelung werde ich eventuell in den
nächsten Tagen durchführen.
Jedenfalls funktioniert der Digitainer mit dem automatischem Reboot und
ich konnte zwei Fehler des viafb Treibers durch die geänderte Kernel 2.6.22 API
beseitigen.

[japio]

Hallo,

Danke fuer die arbeit!

Ich bin froh dass ich diesen thread hab aufgemacht obwol es am anfang so aussah alsob ich der einzige bin mit diesen problem.

Zu scart belastung kan ich nur sagen dass mein fernseher mit 75Ohm abgeschlossen isst, und der digitainer auch erst nach reboot normalem bild ausgibt.

wenn ich weiter helfen kann (messen usw) sag bitte bescheit.

Gruss,
Jaap

[Schrauber]

@Gummibaer: Wie sahen die Fehler aus, die Du aus dem viafb ausgebaut hast?
Mein VDR hängt nämlich noch unter Kernel 2.6.21. Und wenns mit neueren Kerneln Probleme gibt, dann werd ich von einem Update erstmal Abstand nehmen.

[Gummibaer]

Noch ein Nachtrag:

Nach Einspielen der neuen menu.lst muss noch
- grub-set-default 3
ausgefuehrt werden, damit der Digitainer das nächste Mal
mit dem Reboot Eintrag aus menu.lst startet.

@Schrauber
Der Fehler hat sich nicht im Betrieb sondern beim Kompilieren bemerkbar gemacht.
In der Datei
- ./linux-viafb/linux/drivers/video/cle266/via_fbobj.c

hat sich die API für die Funktionen

- static ssize_t viafb_read(struct file *file, char *buf, size_t count, loff_t *ppos)
- static ssize_t viafb_write(struct file *file, const char *buf, size_t count, loff_t *ppos)

geändert in

- static ssize_t viafb_read(struct fb_info *info, char *buf, size_t count, loff_t *ppos)
- static ssize_t viafb_write(struct fb_info *info, const char *buf, size_t count, loff_t *ppos)

weil sich die Defintion von

- struct fb_ops

geändert hat.

Ab welcher Kernelversion diese Änderung auftritt weiss ich nicht, mir ist beim Kompilieren nur eine
entsprechende Warnung bezüglich inkompatibler Pointer aufgefallen, die die eben beschriebene Ursache hat.

Durch Änderung von

static ssize_t viafb_read(struct file *file, char *buf, size_t count, loff_t *ppos)
{
    unsigned long p = *ppos;
    struct inode *inode = file->f_dentry->d_inode;
    int fbidx = iminor(inode);
    struct fb_info *info = registered_fb[fbidx];
    struct via_par *par = (struct via_par *)info->par;

in

static ssize_t viafb_read(struct fb_info *info, char *buf, size_t count, loff_t *ppos)
{
    unsigned long p = *ppos;
    struct via_par *par = (struct via_par *)info->par;

und bei viafb_write entsprechend war der Fehler behoben.

Beim normalen Betrieb hab ich keine Auswirkung bemerkt, wenn man aber über das
proc Filesystem die Modulparameter auslesen wollte, kam es zu einem Segmentation
Fault.
Ich vermute dies war die Ursache, Gegenprobe habe ich allerdings nicht gemacht.

[uwe]

Hallo,
wenn die Änderungen Allgemeingültig sind, könntest Du bitte die via-Sourcen mal uppen, damit ich sie in die nächste Version mitaufnehmen kann.

Danke und GRuß Uwe

[Gummibaer]

Hallo Uwe,

kein Problem, bloß wie geht das?

[uwe]

Hallo,
also einfach entweder die ganzen sourcen packen und dann hier über "erweiterte optionen" anhängen, oder mir einfach via mail schicken.

Gruß Uwe

[Gummibaer]

Hallo Uwe,

wie gewünscht stelle ich hiermit die geänderten viafb Sourcen für den 2.6.22er Kernel zur Verfügung.
Ich hoffe, das Anhängen der Datei  linux-viafb.tar.bz2 hat geklappt.

Ich beschreibe hier noch mal kurz meine Änderungen, eine davon behebt einen Fehler die andere löst entsprechende Compiler Warnungen.


Das Ändern der Funkionen

- static ssize_t viafb_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
- static ssize_t viafb_read(struct file *file, char *buf, size_t count, loff_t *ppos)

in

- static ssize_t viafb_write(struct fb_info *info, char *buf, size_t count, loff_t *ppos)
- static ssize_t viafb_read(struct fb_info *info, char *buf, size_t count, loff_t *ppos)

verhindert beim Auslesen folgender Dateien des sys Filesystems

- easyVDR:/proc# ls /sys/module/viafb/parameters/
- bpp  memsize  mode  noaccel  refresh  TVon  TVoverscan  TVtype

durch beispielsweise

- easyVDR:/proc# cat /sys/module/viafb/parameters/bpp
- 32

eine Speicherschutzverletzung.
Dieser Fehler führt bei den Originalsourcen  zur Compiler Warnbung:
/home/axel/tmp/digitainer/linux-viafb/linux/drivers/video/cle266/via_fbobj.c:1451:
              warning: initialization from incompatible pointer type
/home/axel/tmp/digitainer/linux-viafb/linux/drivers/video/cle266/via_fbobj.c:1452:
              warning: initialization from incompatible pointer type


Durch Entfernen des __initdata Attributes der Modulparameter werden die Compilewarnungen

a'la


WARNING: /home/axel/tmp/digitainer/linux-viafb/linux/drivers/video/cle266/viafb.o(.text+0x1c19):
Section mismatch: reference to .init.data: (between 'via_pci_probe' and 'WaitIdleCLE266')

vermieden.

Das __initdata Attribut dient dazu, den von den entsprechenden Variablen belegten Speicher, nach Ausführen der Initialisierungsfunktionen, wieder freizugeben.

[jurhart]

Hallo
ich habe auch einen Digitainer der beim Start den Chip nicht richtig erkennt erst nach einem Reboot läuft es richtig. NVRAM geht auch nicht ohne anpassungen andere Biosrelease,
Biosinfo gibt das aus

Following DMI entries found:
- Mainboard vendor:  "MICRO-STAR INTERNATIONAL CO., LTD"
- Mainboard type:    "MS-6723"
- Mainboard revision: ""
- BIOS vendor:        "Phoenix Technologies, LTD"
- BIOS version:      "6.00 PG"
- BIOS release:      "11/24/2005"

ich wollte das ding schon wieder vertickenaber dieser Beitrag hat mir sehr geholfen Danke an Gummibaer

Ich habe jetzt durch folgende

- /boot/grub/menu.lst

--------------------------- schnipp ----------------------------------------------

timeout         5
color white/green black/green
default saved

###splashimage=(hd0,2)/boot/grub/splashimages/debsplash.xpm.gz
splash=verbose

title           Debian GNU/Linux, kernel 2.6.22.1
root            (hd0,2)
savedefault 3
kernel          /boot/vmlinuz-2.6.22.1 root=/dev/hda3 ro acpi=on pci=routeirq

title           Debian GNU/Linux, kernel memtest86
root            (hd0,2)
savedfault 3
kernel          /boot/memtest86.bin

title           PowerOff
root            (hd0,2)
savedefault 3
# kernel                /boot/bzImage.poweroff
halt

title           Reboot
root            (hd0,2)
savedefault 0
reboot

-------------------------- schnapp ----------------------------------------------

erreicht, daß beim Booten des Digitainers ein Reboot durchgeführt wird.
Damit ist, wie schon beschrieben, das Bild ok.
Damit sind zwar die Symptome statt der Ursache behoben aber es
funktioniert.

Der VT1622A und auch andere TVEncoder können durch Messen der
Analogpegel während der vertikalen Austaslücke feststellen, ob 
die DAC Ausgänge durch den angeschlossenen Fernseher impedanzmäßig
korrekt  abgeschlossen werden.
Das Ergebnis kann aus entsprechenden Registern ausgelesen werden.

Da mein Digitainer per zwischen geschaltetem Digitalreceiver angeschlossen
ist, wird möglicherweise der angeschlossene Fernseher nicht richtig erkannt.
Die nötige testweise Umverkabelung werde ich eventuell in den
nächsten Tagen durchführen.
Jedenfalls funktioniert der Digitainer mit dem automatischem Reboot und
ich konnte zwei Fehler des viafb Treibers durch die geänderte Kernel 2.6.22 API
beseitigen.

NVRAM habe ich wie folgt angepasst, ich habe das Bios Releaase Datum der vorhanden NVRAM Wakeup .conf
auf mein Bios Release Datum geändert, alle anderen werte waren identisch.

Gruß Jurhart