fix-anleitung nochmal auf deutsch
so, ich bin wieder zurück.
ich würde mich freuen, wenn sich vielleicht ein/zwei leute mit 1600x1200 displays finden würden, die bereit sind, meinen temporären fix mal auszuprobieren. wenn das auch bei anderen klappt könnt ich das mal an nvidia bzw asrock herantragen.
hier eine verkürzte und überschaubarere anleitung auf deutsch, natürlich alles auf eigenes risiko, also wenn was unklar is lieber fragen oder sein lassen:
1. was wird benötigt?
das display sollte per dvi angeschlossen sein und die xorg.conf so eingestellt, dass die EDID-daten vom display ausgelesen werden (also überprüfen, ob noch sachen wie 'Option "UseEDID" "FALSE"' in der device-section der xorg.conf rumfliegen). es sollte also das display falscher auflösung (1280x1024) angesteuert werden, ein bild hat man ja trotzdem.
dann braucht man am besten einen zweiten rechner, auf jeden fall aber irgendwie eine laufende windoofs installation, um das freeware-tool phoenix benutzen zu können. (der hauptgrund, warum man das programm braucht ist, dass ich nicht weiss, wie die checksumme am ende des binären edid-files berechnet wird und das tool uns das abnimmt. des weiteren ist es einfach übersichtlicher
)
des weiteren braucht man noch einen hex-editor, ob unter windoofs oder linux ist eigentlich egal, hauptsache der editor funktioniert vernünftig.
(wer mir in diesem zusammenhang einen netten hex/binär-editor (kann der vim sowas?) für linux empfehlen kann sei hiermit dazu aufgefordert!)
für windows verwende ich gerne den freien und sehr feinen notepad++ (benötigt noch des hex-editor plugin, das sich auch auf der downloadseite findet). ultraedit z.b. geht aber auch (strg+h schaltet in hex-modus).
2. edid-daten als binärfile speichern
nun den nvidia settings manager öffnen (findet sich bei mir unter ubuntu feisty unter anwendungen -> systemwerkzeuge -> nvidia settings) und dort in der linken spalte im abschnitt 'GPU 0 - (blablabla)' die zeile 'DFP-0 - (displayname)' auswählen. dort findet man rechts unten den button 'Acquire EDID ...', mit dessen betätigung man die aktuellen edid-daten des displays als datei 'myEDID.raw' speichert. diese datei sollte nun genau 128b gross sein.
diese datei öffnet man nun mit dem hex-editor der wahl.
3. ascii-version des edid-files für phoenix basteln
das ist der bescheuerteste teil des ganzen! leider kann der phoenix-editor nichts mit der eben erzeugten binären myEDID.raw anfangen, sondern benötigt das ganze als textfile in folgendem format:
die '99' in feld 0x7f ist die checksumme, die sich mit jeder änderung an irgendeinem wert ändert und die man daher unbedingt am schluss nochmal anpassen muss. die 'FF'-werte in den feldern 0x01 bis 0x04 können auch andere sein und sind nur als beispiel gedacht.
zunächst erstellt man sich eine leere text-datei im editor und kopiert in diese die dummy daten der obenstehenden box. diese datei wird nun im text-modus bearbeitet (also nix hex!) und zwar muss man leider die hex-werte aus der im hex-editor geöffneten myEDID.raw in text übertragen. wichtig ist, dass die textdatei am ende im windows-textformat gespeichert werden muss, also mit CarriageReturn und LineFeed am ende jeder zeile!
man speichert die erzeugte text-datei nun am besten als 'myEDID.dat'.
wenn man die textdatei nun im hex-editor öffnet, muss am ende jeder text(!)-zeile (auch der letzten, also nach der checksumme) ein '0D 0A' stehen, nicht nur ein '0A' (unix-zeilenumbruch). ansonsten lässt sich das file nicht mit dem phoenix-editor öffnen.
4. werte mit phoenix überprüfen/anpassen
nun öffnet man die eben erstellte myEDID.dat mit phoenix und aktiviert dort erstmal den 'byte viewer', worauf sich ein kleines zusätzliches fenster mit einer hex-ansicht öffnet, und dann noch den 'edit-mode' (beides buttons in der werkzeugleiste).
nun in den tab 'standard timings' wechseln. dort sind 2 mal 4 bereiche namens 'timing id', von denen in meinem fall die ersten beiden aktiviert und mit vernünftigen werten gefüllt waren.
im bereich 'timing id #1' war '1600', refresh '60' und aspect ratio '4:3' eingetragen, also die tatsächlichen daten meines monitors, weshalb ich diesen bereich auch unverändert gelassen habe.
im bereich 'timing id #2' war '1280', refresh '60' und ar '5:4' eingetragen, also genau die werte, die fälschlicherweise angenommen werden! wenn man dort nun dieselben werte wie in 'timing id #1' einträgt, sieht man im 'byte-viewer', wie sich die hex-werte der felder 0x28 und 0x29 von '81' '80' in 'A9' '40' ändern und damit den werten aus den beiden vorhergehenden feldern 0x26 und 0x27, die den 'timing id #1'-bereich repräsentieren, angeglichen werden. ferner ändert sich wie bereits erwähnt auch noch die checksumme in 0x7F!
diese 3 änderungen übernimmt man nun in die im hex-editor geöffnete myEDID.raw und speichert diese als 'mynewEDID.raw'.
5. edid-daten aus modifiziertem file laden lassen
nun soll der nvidia-treiber anstelle der daten, die direkt via dvi vom display übertragen werden (und die offensichtlich irgendwo falsch interpretiert werden) die modifizierte 'mynewEDID.raw' verwenden. dies erreicht man, indem man 'mynewEDID.raw' in /etc/X11/ kopiert (evtl leserechte für alle sicherstellen) und in den 'device'-abschnitt der xorg.conf folgende zeilen aufnimmt:
6. testen ob schon alles klappt und debuggen
am besten testet man das nun mit erweiterten verbose-ausgaben des x-servers. das erreicht man, indem man alle geöffneten anwendungen beendet und dann per 'strg + F1' zur konsole wechselt, sich dort unter dem normalen username einloggt und den xserver per
herunterfährt (sudo = ubuntu syntax für als-root-ausführen) und anschliessend (ohne root-rechte!) per
wieder startet.
möglicherweise klappt jetzt schon alles, ansonsten wechselt man wieder (mit 'strg + F1') zur konsole und schaut sich z.b. per
das logfile mit den erweiterten ausgaben an.
in meinem fall tauchte noch folgende fehlermeldung um zeile 460 rum auf:
man sieht da schon, dass immerhin nun die 1600er auflösung aus dem EDID-file bezogen wird, nur gibt es offensichtlich noch ein problem mit dem timing der 'PixelClock'.
den wert von '155' hab ich tatsächlich auch im tab 'detailed timings' (block1) im phoenix-editor gefunden; irgendwie glaube ich aber nicht ganz dass dieser richtig ist. dennoch hab ich mich nicht getraut, den wert einfach auf die in meinem fall nötigen '162' anzuheben, sondern hab mir stattdessen hier eine modeline für einen 'PixelClock'-takt von '155' und die anderen passenden daten für meinen monitor erzeugen lassen und diese dann in den 'monitor'-abschnitt meiner xorg.conf eingetragen.
ich komme damit zwar auf krumme 57,41hz bildwiderholungsrate, aber flackern tut mein display ja eh nicht
.
auf jeden fall geht so bei mir nun alles wie es soll!
viel spass beim ausprobieren, ich freu mich aufs feedback,
euer red
----------------------------------------------------------------------------------------- *snip*
es is zum schreien, aber diese dämliche automatik lässt mich hier keine zwei posts hintereinander machen, auch wenns thematisch irgendwie angebracht wär... dann eben so
die höhenangabe des 'cooler master susurro' von 25mm zweifel ich ehrlich gesagt etwas an, ich hab in der vergangenheit mit zalman-kühlern recht gute erfahrungen gemacht, von daher würde ich dir zu einem der beiden zalmans raten.
für die humane wärmeabgabe der amd-prozzis (mal ausgenommen von solchen schleuder wie dem 6000er ) sollte es zwar auch einer mit einem defaultmässig weniger als 2000 umdrehungen drehenden 120er lüfter tun, aber wenn du ohnehin windows auf dem rechner laufen hast und die temperatursteuerungssoftware verwendest sollte es da lautstärkemässig auch human zugehen.
pwm wär da natürlich schon was schickes, da das bios da ja auch unterstützt.
ich hab da noch den Thermaltake TMG A2 entdeckt. die richtige gesamthöhe ist zwar (laut alternate) 103mm und nicht 32mm, aber das sollte ja passen. gehört hab ich zwar noch nix über das teil, aber schlecht sieht der doch auch nicht aus, oder?
so, ich bin wieder zurück.
ich würde mich freuen, wenn sich vielleicht ein/zwei leute mit 1600x1200 displays finden würden, die bereit sind, meinen temporären fix mal auszuprobieren. wenn das auch bei anderen klappt könnt ich das mal an nvidia bzw asrock herantragen.
hier eine verkürzte und überschaubarere anleitung auf deutsch, natürlich alles auf eigenes risiko, also wenn was unklar is lieber fragen oder sein lassen:
1. was wird benötigt?
das display sollte per dvi angeschlossen sein und die xorg.conf so eingestellt, dass die EDID-daten vom display ausgelesen werden (also überprüfen, ob noch sachen wie 'Option "UseEDID" "FALSE"' in der device-section der xorg.conf rumfliegen). es sollte also das display falscher auflösung (1280x1024) angesteuert werden, ein bild hat man ja trotzdem.
dann braucht man am besten einen zweiten rechner, auf jeden fall aber irgendwie eine laufende windoofs installation, um das freeware-tool phoenix benutzen zu können. (der hauptgrund, warum man das programm braucht ist, dass ich nicht weiss, wie die checksumme am ende des binären edid-files berechnet wird und das tool uns das abnimmt. des weiteren ist es einfach übersichtlicher
)des weiteren braucht man noch einen hex-editor, ob unter windoofs oder linux ist eigentlich egal, hauptsache der editor funktioniert vernünftig.
(wer mir in diesem zusammenhang einen netten hex/binär-editor (kann der vim sowas?) für linux empfehlen kann sei hiermit dazu aufgefordert!)
für windows verwende ich gerne den freien und sehr feinen notepad++ (benötigt noch des hex-editor plugin, das sich auch auf der downloadseite findet). ultraedit z.b. geht aber auch (strg+h schaltet in hex-modus).
2. edid-daten als binärfile speichern
nun den nvidia settings manager öffnen (findet sich bei mir unter ubuntu feisty unter anwendungen -> systemwerkzeuge -> nvidia settings) und dort in der linken spalte im abschnitt 'GPU 0 - (blablabla)' die zeile 'DFP-0 - (displayname)' auswählen. dort findet man rechts unten den button 'Acquire EDID ...', mit dessen betätigung man die aktuellen edid-daten des displays als datei 'myEDID.raw' speichert. diese datei sollte nun genau 128b gross sein.
diese datei öffnet man nun mit dem hex-editor der wahl.
3. ascii-version des edid-files für phoenix basteln
das ist der bescheuerteste teil des ganzen! leider kann der phoenix-editor nichts mit der eben erzeugten binären myEDID.raw anfangen, sondern benötigt das ganze als textfile in folgendem format:
Code:
EDID BYTES:
0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------------------------------------------------
00 | 00 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00
10 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99zunächst erstellt man sich eine leere text-datei im editor und kopiert in diese die dummy daten der obenstehenden box. diese datei wird nun im text-modus bearbeitet (also nix hex!) und zwar muss man leider die hex-werte aus der im hex-editor geöffneten myEDID.raw in text übertragen. wichtig ist, dass die textdatei am ende im windows-textformat gespeichert werden muss, also mit CarriageReturn und LineFeed am ende jeder zeile!
man speichert die erzeugte text-datei nun am besten als 'myEDID.dat'.
wenn man die textdatei nun im hex-editor öffnet, muss am ende jeder text(!)-zeile (auch der letzten, also nach der checksumme) ein '0D 0A' stehen, nicht nur ein '0A' (unix-zeilenumbruch). ansonsten lässt sich das file nicht mit dem phoenix-editor öffnen.
4. werte mit phoenix überprüfen/anpassen
nun öffnet man die eben erstellte myEDID.dat mit phoenix und aktiviert dort erstmal den 'byte viewer', worauf sich ein kleines zusätzliches fenster mit einer hex-ansicht öffnet, und dann noch den 'edit-mode' (beides buttons in der werkzeugleiste).
nun in den tab 'standard timings' wechseln. dort sind 2 mal 4 bereiche namens 'timing id', von denen in meinem fall die ersten beiden aktiviert und mit vernünftigen werten gefüllt waren.
im bereich 'timing id #1' war '1600', refresh '60' und aspect ratio '4:3' eingetragen, also die tatsächlichen daten meines monitors, weshalb ich diesen bereich auch unverändert gelassen habe.
im bereich 'timing id #2' war '1280', refresh '60' und ar '5:4' eingetragen, also genau die werte, die fälschlicherweise angenommen werden! wenn man dort nun dieselben werte wie in 'timing id #1' einträgt, sieht man im 'byte-viewer', wie sich die hex-werte der felder 0x28 und 0x29 von '81' '80' in 'A9' '40' ändern und damit den werten aus den beiden vorhergehenden feldern 0x26 und 0x27, die den 'timing id #1'-bereich repräsentieren, angeglichen werden. ferner ändert sich wie bereits erwähnt auch noch die checksumme in 0x7F!
diese 3 änderungen übernimmt man nun in die im hex-editor geöffnete myEDID.raw und speichert diese als 'mynewEDID.raw'.
5. edid-daten aus modifiziertem file laden lassen
nun soll der nvidia-treiber anstelle der daten, die direkt via dvi vom display übertragen werden (und die offensichtlich irgendwo falsch interpretiert werden) die modifizierte 'mynewEDID.raw' verwenden. dies erreicht man, indem man 'mynewEDID.raw' in /etc/X11/ kopiert (evtl leserechte für alle sicherstellen) und in den 'device'-abschnitt der xorg.conf folgende zeilen aufnimmt:
Code:
Option "AddARGBGLXVisuals" "true"
Option "UseDisplayDevice" "DFP-0"
Option "CustomEDID" "DFP-0:/etc/X11/mynewEDID.raw"6. testen ob schon alles klappt und debuggen
am besten testet man das nun mit erweiterten verbose-ausgaben des x-servers. das erreicht man, indem man alle geöffneten anwendungen beendet und dann per 'strg + F1' zur konsole wechselt, sich dort unter dem normalen username einloggt und den xserver per
Code:
sudo /etc/init.d/gdm stop
Code:
startx -- -logverbose 6möglicherweise klappt jetzt schon alles, ansonsten wechselt man wieder (mit 'strg + F1') zur konsole und schaut sich z.b. per
Code:
cat /var/log/Xorg.0.log | lessin meinem fall tauchte noch folgende fehlermeldung um zeile 460 rum auf:
Code:
(II) NVIDIA(0): Validating Mode "1600x1200":
(II) NVIDIA(0): 1600 x 1200 @ 60 Hz
(II) NVIDIA(0): For use as DFP backend.
(II) NVIDIA(0): Mode Source: EDID
(II) NVIDIA(0): Pixel Clock : 162.00 MHz
(II) NVIDIA(0): HRes, HSyncStart : 1600, 1664
(II) NVIDIA(0): HSyncEnd, HTotal : 1856, 2160
(II) NVIDIA(0): VRes, VSyncStart : 1200, 1201
(II) NVIDIA(0): VSyncEnd, VTotal : 1204, 1250
(II) NVIDIA(0): H/V Polarity : +/+
(WW) NVIDIA(0): Mode is rejected: PixelClock (162.0 MHz) too high for
(WW) NVIDIA(0): Display Device (Max: 155.0 MHz).den wert von '155' hab ich tatsächlich auch im tab 'detailed timings' (block1) im phoenix-editor gefunden; irgendwie glaube ich aber nicht ganz dass dieser richtig ist. dennoch hab ich mich nicht getraut, den wert einfach auf die in meinem fall nötigen '162' anzuheben, sondern hab mir stattdessen hier eine modeline für einen 'PixelClock'-takt von '155' und die anderen passenden daten für meinen monitor erzeugen lassen und diese dann in den 'monitor'-abschnitt meiner xorg.conf eingetragen.
ich komme damit zwar auf krumme 57,41hz bildwiderholungsrate, aber flackern tut mein display ja eh nicht
. auf jeden fall geht so bei mir nun alles wie es soll! viel spass beim ausprobieren, ich freu mich aufs feedback,
euer red
----------------------------------------------------------------------------------------- *snip*
es is zum schreien, aber diese dämliche automatik lässt mich hier keine zwei posts hintereinander machen, auch wenns thematisch irgendwie angebracht wär... dann eben so
prinzipiell sollte ein 120mm cpu-lüfter schon aufs board passen, ob sich das jeweilige modell nun mit irgendwelchen bauteilen in die quere kommt ist schwer zu sagen, das einzige, was im bereich des cpu-sockels etwas höher rausragt sind wie ich beim kurzen nachsehen eben erkennen konnte ein paar elkos in richtung des anschlusspanels.
die höhenangabe des 'cooler master susurro' von 25mm zweifel ich ehrlich gesagt etwas an, ich hab in der vergangenheit mit zalman-kühlern recht gute erfahrungen gemacht, von daher würde ich dir zu einem der beiden zalmans raten.
für die humane wärmeabgabe der amd-prozzis (mal ausgenommen von solchen schleuder wie dem 6000er
) sollte es zwar auch einer mit einem defaultmässig weniger als 2000 umdrehungen drehenden 120er lüfter tun, aber wenn du ohnehin windows auf dem rechner laufen hast und die temperatursteuerungssoftware verwendest sollte es da lautstärkemässig auch human zugehen.pwm wär da natürlich schon was schickes, da das bios da ja auch unterstützt.
ich hab da noch den Thermaltake TMG A2 entdeckt. die richtige gesamthöhe ist zwar (laut alternate) 103mm und nicht 32mm, aber das sollte ja passen. gehört hab ich zwar noch nix über das teil, aber schlecht sieht der doch auch nicht aus, oder?
Zuletzt bearbeitet:
