Hallo Jürgen,
>> Was für Probleme?
also wenn ich das auch andernorts vernommene Gegrummel richtig interpretiere, dann bin ich mit meiner Beobachtung nicht ganz allein... Aber nun mal zu meinen eigenen, diversen Problemen:
(i) Beim Booten hängt das System ÜBER 1 MINUTE bevor das GUI kommt. Vorher wusste gab es wenigstens noch ein Anzeige von SciTech (und dauerte einen Bruchteil der Zeit). Jetzt blinkt nur der Cursor und beim allerersten Mal habe ich doch den Rechner abgeschaltet weil ich dachte der hängt....
(ii) dto bei der Hardware-Erkennung im Systemnotizbuch: OS/2 steht still im > Minutenbereich (um dann wahlweise Erfolg oder Nichterfolg der Erkennung zu melden). Das war mal ein Blinzeln lang. Ist es auch auch auf meinem Eizo F77S.
(iii) Mal wird mein TFT erkannt (Sony SDM-X72) und mal nicht. Je nach Laune verschwindet der Monitor auch mal aus der Listbox.
(iv) Wenn man nach Neuinstallationen (ich mache derzeit ziemlich viele um UPDCD zu testen) den Initialen VGA-Modus (natürlich nach Reboot) gleich auf volle TFT-Grösse mit 16 Millionen Farben hochstellt, dann verschwinden häufig alle Einstell-Optionen ausser 640x480 und der Monitor zeigt auch nur VGA an. Dann bleibt nur Rücksetzen auf VGA, komplettes (!!) Entfernen von SNAP und Neuinstallation.
(v) Screen-Redraw bei diversen Fenstern ist eine Katastrophe. Da überlagert sich plötzlich alles Mögliche und einzig ALT-F10 -> ALT-F5 bringt dann wieder eine korrekte Anzeige. Aber wahrscheinlich liegt das an der Software. Denn SDD/SNAP war ja NOCH NIE für seine Macken verantworlich.
(vi) Mein geliebtes UDESKTOP ist jetzt unbrauchbar geworden; alle restarurierten Fenster landen jetzt minimisiert in der linken unteren Ecke. Aber wahrscheinlich hat auch da der Autor einen alten (nach SciTech-Meinung) API-Aufruf verwendet und deshalb wurde die Software von SciTech funktionell entsorgt. Es soll aber Leute geben, die OS/2 auch ohne ODIN und anderen Krimskrams benutzen wollen. Die einzige vernünftige Software, die es schliesslich für OS/2 gibt, ist halt schon Jahre alt und dann sollte diese wenigstens anständig laufen. Sonst wird die ganz Übung einfach unsinning.
(vii) in irgend einem Status-Menu / Report (kann mich nicht mher genau erinnern) wird meine Karte statt DVI als DFP gelistet.
(viii) Für die weiteren Macken muss ich erst nochmal nachdenken. Ich habe es aufgegeben, sie alle aufzulisten.
(ix) Die unzähligen anderen Programme, die mit SDD/SNAP SEIT JAHREN ANZEIGEFEHLER haben, will ich an dieser Stelle gar nicht erst auflisten.... Natürlich waren auch in diesen Fällen immer die anderen die Idioten, die nicht programmieren können ("veraltete" API-Aufrufe einsetzen, etc pp): an dem Tag an dem SciTech mal eine eigene Fehlleistuing eingesteht, stifte ich eine grosse Kerze....
>>> Das einzige was jetzt immer mehr zum Problem wird, wo SciTech aber nur wenig Einfluß hat, sind die WideScreen Displays (jedenfalls wenn digital angesteuert).
Na das wollen sie uns auch mal glauben machen. Wenn ich nicht im letzten Jahr immens viel Zeit damit zugebracht hätte, mich wg Eigenbedarfs über TFT auf der CeBIT zu informieren und dabei auch wirklich lange (!) mit einem Techniker von NEC gesprochen hätte, dann würde ich das vielleicht auch noch glauben. Manchmal hat es auch Vorteile wenn man vor Ort ist und häufiger vorbeischauen kann....
Alles über 1280x1024 ist bei digitalen Monitoren (noch) nicht normiert. Bis 1600x1200 (oder waren es 1920x1200; das habe ich nicht mehr im Kopf - weil es mich nicht interessiert hat) geht es via DVI-D. Darüber geht es digital nicht weil die Kabel nicht voll belegt sind! Genau - die Norm erlaubt zwar höhere Auflösungen - aber dann müssten die DVI-D Kabel mehr Leitungen enthalten und weil das teurer ist macht das niemand. Mit dieser Info geht natürlich kleiner hausieren.... Deshalb werden praktisch alle TFTs mit höheren Auflösungen (d.h. auch Wide-Screens) über zwei getrennte DVI-D Leitungen versorgt: im Prinzip also eine Zwei-Bildschirmlösung in einem Kasten. Da SNAP aber Mehrbildschirmlösungen unterstützt, müsste das Problem bei SciTech mit endlichem Aufwand zu lösen sein (so man denn überhaupt will).
Problematisch ist es tatsächlich für die 1600x1200 Auflösung. Aber auch da meint der Fachmann könne man die notwendigen Informationen bekommen - sofern man sich Mühe gibt. Umgekehrt sind auch die Monitorhersteller an unahängigen Lösungen interessiert. Mein Hinweis auf SciTech wurde negierig aufgenommen....
Konkret aber wundert es mich, dass ich immrr nur lese, dass >1280x1024 für digitale Panels nicht gehen solle, weil.... Was soll der Stuss. Mich interessiert doch schlicht und einfach: gibt es denn ÜBERHAUPT eine Grafikkarte unter OS/2 die ein digitales Panel digital mit 1600x1200 erfolgreich ansteuert? Und falls ja, welcher Karte ist das? Und im Zweifelsfall mit welchem Monitor? Das kann doch nicht so schwer sein, in die Readme zu schreiben. Dann weiss ich was ich im Bedarfsfalle kaufen muss. So aber liest man seit Jahren dasselbe Gesalbadere.... Klaro - SciTech war nie für nix verantwortlich.
>> Das letzte Problem das ich hatte war der Parhelia Bug, das DIVE Fenster falsch positioniert wurden, das wurde halbwegs schnell gefixt.
Schön für Dich. So was wie DIVE habe ich mit den neuen Treibern noch gar nicht ausprobiert.....
Grüsse
Martin
PS: Damit die Frage des Testsystems nicht offen bleiben muss: WSA SMP mit FP43/44 auf diversen Maschinen. Um es gleich vorwergzunehmen - SNAP ist ausdrücklich für Warp3 "zugelassen". ... Grafikkarte ist immer eine Matrox G400. Für die Digitale Ansteuerung ist eine der Karten mit dem "raren" digitalen (DVI) Tochterboard für die G400 ausgerüstet. Monitore sind ein Sony X72 Panel (getestet @ DVI-D und SUB-D) und ein Eizo F77S.
[ Leser: 157 ] |
![[Forum]](../../../images.os2.org/de/forum.gif){kind=small}
![[Forum]](../../../images.os2.org/de/forum2.gif){kind=small}
