UPLUS-Vision 30" Monitor *Resolution Issues

tredegar · 08-07-2007, 09:45 AM

Some real progress at last.
Trying to edit raw EDID data was doing my head in, what with all those bits, nybbles, bytes, conditional fields and wretched checksums (I computed it manually - it was correct). So I wanted to use the Phoenix editor. Sadly, there's no EDID editor for linux (Yet, any offers, people?

)

It turns out, after a bit of hex-editing, that Phoenix EDID editor does not expect to open a raw, 128 byte EDID file. It expects it as an ASCII / HEX table in a DOS text file. It will not import a raw file

So I copied your monitor's raw EDID data from the X.log in post #26 and manually constructed the table for windows. Here is that table in windows-compatable 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 FF FF 00 56 16 01 00 01 00 00 00
10 | 01 0f 01 01 80 50 2d 78 2A EE 91 A3 54 4C 99 26
20 | 0F 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
30 | 01 01 01 01 01 01 BC 1B 00 A0 50 20 17 30 30 20
40 | 26 00 81 91 21 00 00 18 E2 68 00 A0 A0 40 2E 60
50 | 30 20 26 00 81 91 21 00 00 18 00 00 00 FD 00 3B
60 | 3D 1E 50 0E 00 0A 20 20 20 20 20 20 00 00 00 FC
70 | 00 55 50 2D 4D 33 30 57 31 0a 20 20 20 20 00 50

Note that all lines (in the binary of this file) end in 0D 0A (CarriageReturn and LineFeed, DOS-type end of lines)
The last two characters in the file are 0D 0A.
The file is exactly 553 bytes long.

If you create this file with a linux text editor (copy & paste the above), save it as M30W1.dat Make sure it is exactly 553 bytes long. If not, open it with a hex editor and make sure the end-of-lines are 0D 0A, not just 0A, and that the last two characters of the binary file are 0D 0A. If you can't cope with this, then email me (so I get your email address) and then I'll happily send it to you as a binary attachment.

If you create this file with a windows text editor like notepad (copy & Paste), you'll probably be OK, just make sure the file ends with a <Return> (so the last 2 bytes are 0D 0A), and that the resulting file is exactly 553 bytes long. Windows probably says it is 1Kb long (it did for me) because windows has a crappy filesystem. Look at the filesize from linux.

Now you have your 553-byte windows-format EDID file, you should fire up Phoenix ( Get it here http://www.tucows.com/preview/329441 ), I am told that it runs under linux if you use wine, but I used a winXP computer to run it (Yuk!).
Have it open the M30W1.dat file.

You will see your monitor's EDID file is very strange. You'll need to click the "Read-only/Edit" Icon in Phoenix before you can make any changes.

The EDID data needs playing with and correcting so that the 2560x1600 mode is set as interlaced. There may be other changes necessary as well. It's difficult for me because I do not have your monitor to play with.

Windows timings are different from linux's ModeLines : They are called H Blank and H Sync Offset and H Sync Width etc, you are going to have to do some research before you can convert the valid timings of our Modeline "2560x1600@60i" to their windows equivalents. It looks to me as though linux gives absolute timings, and win uses relative ones, so it may just be a matter of subtracting one modeline value from another to find the win relative value.
You could generate a ModeLine for 1280x800 at whatever refresh rate / clock rate Phoenix says your EDID has for its default 1280x800, and then compare the ModeLine numbers with the windows timings to work out how they relate. Here's a link to a modeline generator:
http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

Other things to look at:
1] Somewhere in all the Phoenix tabs is a box that says "Preferred timing mode", and it is checked. I wonder if this is the cause of your monitor saying its Preferred width/ height is 1280x800? You'll have to experiment.
2] Somewhere it says (Display size) and with your monitor's EDID data, this is mysteriously set to be half the horiz resolution +1 and half the vert resolution +1. This seems very wierd, and may need changing. Again, you'll have to experiment.

Once you think the EDID data looks OK, export it as a raw file (There's a drop-down-box to select this in the Rhoenix Export box), this file should be exactly 128 bytes long. Doing this reset some parts of the EDID, resetting your monitor's manufacture date to 1990, and updating the EDID version to 3, I think, but this doesn't matter, only the timings and resoltion and interlacing and whatnot do.

There may be another (possibly easier) way of getting a corrected EDID file

You'll need a win2k / XP PC which you can plug your monitor into. Boot to windows. Get your monitor working in 2560x1600 (don't ask me how, but you said "It works with windows"!). Then fire up Phoenix. Ask it to "Fetch EDID info from the Registry". You might find that it generates/ fetches a working EDID file for you. Save it as raw file. If this works, you won't have to mess with creating that M30W1.dat like I had to, and then trying to modify it so it is correct.

Now we are getting to the good bit. Once you have made yourself a corrected EDID file, we need to move it over to linux, and then we'll pretty much follow the instructions given in this link:

https://bugs.launchpad.net/ubuntu/+s....15/+bug/33075

Call the file newEDID.raw and save it as /etc/X11/newEDID.raw
Start with our favourite, basic xorg.conf (from post #16), and edit it thus:

In the Device Section (where it lists Driver "nvidia"), you need to add the following 3 lines

Code:

Option "AddARGBGLXVisuals" "true"
Option "UseDisplayDevice" "DFP-0"
Option "CustomEDID" "DFP-0:/etc/X11/newEDID.raw"

You may now not need the ModeLine "2560x1600@60i" that we calculated earlier, because the new EDID file should make it unnecessary, but if you remove it, make sure the Modes line reads "2560x1600", not "2560x1600@60i"

Restart X, look at the logs, here we go again

tredegar · 08-07-2007, 09:53 AM

Thanks for your post #45 (We almost cross-posted) [This is one l-o-n-g thread!], but the link (and the link doesn't work - "Javascrpit Error" with both FFox & Konqueror, I have Sun java jre1.5.0_07, but no matter), but I no longer need it as you'll see from my post #50.

Quote:

It's a nice monitor though

No doubt, but does it work with linux?

andou · 08-08-2007, 07:14 AM

Quote:

Originally Posted by tredegar

No doubt, but does it work with linux?

Eventually, I'm sure it will. Thanks to your help, of course

Post 50 is a little (a lot) above my head. I'm trying to figure it out, but there's a long way to go for me.

First, I've tried copying and pasting and saving as a .dat file. I keep getting 542Kb. I'm not sure that I need to press return (enter) at the end of the text. I tried, then I had a 543kb file, the 553 that you said I needed.

I have no idea what you mean by 0D 0A and don't even see them anywhere in the code. I'll send you an email.

Also, I had a look at the link to Bug #33075, as you said we'll pretty much follow the instructions there. Not sure if it's important, but when I tried the su nvidia-glx-config enable command, I got the message:

Code:

sudo: nvidia-glx-config: command not found

Quote:

Originally Posted by tredegar

[This is one l-o-n-g thread!]

It sure is... I'm surprised (and very thankful) that you've stuck with me this long. Thanks

tredegar · 08-08-2007, 12:25 PM

Quote:

Post 50 is a little (a lot) above my head. I'm trying to figure it out, but there's a long way to go for me.

Sorry, my fault for racing ahead - you have been doing well for a "newbie"!

Quote:

I keep getting 542Kb

Kb!! No, this is just a tiny file. Maybe you mean 542B? This would be the case if you copied & pasted into a linux editor like kate or kwrite, or even vi. Let me explain:
The first line of the file is EDID BYTES: Then there is a new line started, and then more text.
If you look at that file with a hexadecimal editor, you can see the hex ASCII characters that represent E (45), then D (44) etc. The "End of the line", in linux is represented with the "non-printing" (= "nothing shows, but something happens") hex code 0A. But windows and DOS use two codes, one after the other to represent a "Newline". The DOS codes are 0D 0A. Here's a link to the ASCII codes: http://www.asciitable.com/
Your file is too short because it is using linux type newlines, and we need dos type newlines, so we are short of 10 occurrences of the hex character 0D, and one of 0A. If you give the command hd yourEDIDfilename you can see how the characters and newlines of a file are stored as hex, and all will be revealed. No matter, because I have emailed you the file in DOS format.

You now have two options:
1] Find yourself a win2k XP computer. Install the Phoenix EDID editor (just download it from the link (@#46) I gave you, put it on the windows desktop & open it). Have it open the EDID file I sent you for your monitor. Take a look at it, tweak it, save the tweaked version, and then take it back to linux. Try it out. If no better,

and then re-tweak it.

2] Find yourself a win2k or XP computer, which you can plug your big monitor into. Follow the last part of post #46, that starts with "There may be another (possibly easier) way...". This way uses windows to create a valid EDID for your monitor, and then extract it from the windows registry and save it by using Phoenix. You can then move the EDID.raw file to linux, and make 3 little changes to xorg.conf, and all should be well. You do not have to do nvidia-glx-config, in fact it is best not to as we already have your xorg.conf well set up, and your nvidia driver is working, we just need to tell it about your monitors EDID.

Either way, we are going to get the nvidia module to read the EDID data from a file, not your monitor, because your monitor's EDID file is wrong!

The relevant part of that external thread is L. Martin's last post on 2007-4-22, and I have included the necessary steps in my post #46, just in case that thread/board disappeared overnight.

Quote:

I'm surprised (and very thankful) that you've stuck with me this long. Thanks

No problem: I must like solving puzzles (and linux beats the cr@p out of sudoku and crosswords), and you are easier to help than some: you have common sense, don't whine, are prepared to do some work yourself and experiment, and very importantly, don't give up too easily. You have the makings of a happy linux user

ShellyCat · 08-08-2007, 07:07 PM

I am by no means an expert and it seems you guys are trying a lot of things I know nothing about. But one thing I found interesting was the discussion on modes and virtual terminals. I have a Toshiba laptop with Intel 945 GM Express chipset (on-board graphics with hardware acceleration), but still, many of your errors were very similar to mine. Incorrect resolution detection seems to be an issue with laptops.

Just regarding the Modeline, you should write down the info given in any section of "/var/log/Xorg.0.log" that looks like this:

Quote:

Supported additional Video Mode:
clock: 71.0 MHz Image Size: 304 x 190 mm
h_active: 1280 h_sync: 1328 h_sync_end: 1360 h_blank_end: 1440 h_border:0
v_active: 800 v_sync: 803 v_sync_end: 809 v_blanking: 823 v-border:0

The only thing that does not seem to be needed in your modeline are "Image Size", "h_border", and "v_border". What are used are "clock" and all the other things starting with "h_" or "v_".

Notice at the end of my modeline I have "-hsync -vsync". I got mine from the Intel drivers site. I don't know if you need these flags or if they should be on or off. How the above translates to a modeline:

Code:

Modeline "1280x800" 71.00 1280 1328 1360 1440 800 803 809 823 -hsync -vsync

The above is the "Modeline" keyword, the name of the mode in quotes, the clock (71.00), then all the "h_" numbers in order, then all the "v_" numbers in order -- except borders! (Apparently not needed, or maybe not needed if they are "0".)

As someone said, the font errors get sorted out when you start X, but if you want to get rid of the errors, write down the invalid paths, then comment them out of your "xorg.conf":

Code:

# FontPath "/usr/share/fonts/local/"
# FontPath "/usr/share/fonts/CID/"

Edit: I also commented out any modes and modelines I do not want to use.

andou · 08-11-2007, 03:48 AM

Quote:

Originally Posted by tredegar

You now have two options:
1] Find yourself a win2k XP computer. Install the Phoenix EDID editor (just download it from the link (@#46) I gave you, put it on the windows desktop & open it). Have it open the EDID file I sent you for your monitor. Take a look at it, tweak it, save the tweaked version, and then take it back to linux. Try it out. If no better,

and then re-tweak it.

2] Find yourself a win2k or XP computer, which you can plug your big monitor into. Follow the last part of post #46, that starts with "There may be another (possibly easier) way...". This way uses windows to create a valid EDID for your monitor, and then extract it from the windows registry and save it by using Phoenix. You can then move the EDID.raw file to linux, and make 3 little changes to xorg.conf, and all should be well. You do not have to do nvidia-glx-config, in fact it is best not to as we already have your xorg.conf well set up, and your nvidia driver is working, we just need to tell it about your monitors EDID.

That's interesting that both of the two option would actually require Windows...

Anyway, I haven't been able to get this going. First, I've tried downloading and opening on a computer with Win XP - The problem... Phoenix EDID Designer gives me the error message: Invalid EDID when I try to open either of the EDID files you sent.

Also, when I download and check the size in Linux, they both show that they are 542Bytes (And, yes you were right, of course, Bytes and not KB - not used to byte size files).

Anyway, I am having a lot of trouble understanding what to do. I am currently working a lot and getting very little sleep - I'm trying to keep up, but this whole ASCII codes and Hexadecimal stuff is pretty technical for my current level of understanding. I'll try to keep up.

tredegar · 08-12-2007, 02:52 AM

Sorry for the delay - I've been busy.

@ShellyCat: Thanks, but because andou's EDID file is bad, or X is misinterpreting it, he doesn't get a list of suitable modes in his Xorg.0.log, so we are trying to fix his monitor's EDID.

@andou:

Quote:

That's interesting that both of the two option would actually require Windows...

Well, the second one requires windows, because we are getting windows to mend the broken EDID (I hope!), and then using Phoenix to extract the mended EDID from the Registry, and then save it as a raw (binary, not text-mode like windows expects) file that linux can use.

Strictly speaking, the first doesn't - we could edit the EDID by hand (in binary, without even the "convenience" of Hex), but the format is a nightmare, so I wanted to use the (windows only) Phoenix editor.

Quote:

they both show that they are 542Bytes

Whoops! You are right - something somewhere in the mail-transport has treated the attachments as text files and messed with the CR/LF / LF codes.
So I have zipped the files and resent them to you. When you unzip them, they'll be the correct 553 byte size, and although the text will look exactly the same, the files are different, and Phoenix will be happy.

Apologies for this extra layer of confusion.

Please try again

Quote:

I'll try to keep up.

You are doing fine.

andou · 08-13-2007, 01:02 AM

Quote:

Originally Posted by tredegar

Sorry for the delay - I've been busy.

No problem at all. I've been busy too... and I definitely know what it's like.

Quote:

Originally Posted by tredegar

Strictly speaking, the first doesn't - we could edit the EDID by hand (in binary, without even the "convenience" of Hex), but the format is a nightmare, so I wanted to use the (windows only) Phoenix editor.

That makes sense. I've got XP on my MacBook for some work applications that are "windows only" - there are, surprisingly or not, a lot of them in Korea, so that's not a problem.

Quote:

Originally Posted by tredegar

Whoops! You are right - something somewhere in the mail-transport has treated the attachments as text files and messed with the CR/LF / LF codes.
So I have zipped the files and resent them to you. When you unzip them, they'll be the correct 553 byte size, and although the text will look exactly the same, the files are different, and Phoenix will be happy.

That is great news! I somehow feel less confused now

I'm at the office, but as soon as I get home (in about 6 hours from now), I'll check try it out.

Quote:

Originally Posted by tredegar

You are doing fine.

Thanks to you

antiplex · 08-17-2007, 04:23 PM

hi there!

i just finished assembling my new computer and am now facing the same troubles as andou is. i followed your path (things andou tried so far) with the mostly exact same results, but my hardware is different:
i use the nvidia geforce 7050 (nforce 630a) onboard graphics of the asrock aliveNF7G-HDReady motherboard with my fujitsu-siemens p20-2 tft-panel (native resolution of 1600x1200) connected through dvi, but the nvidia-driver (or whatever generates the EDID data) thinks that the native resolution would be 1280x1024.

'nvidia-xconfig --query-gpu-info' correctly returns the following:

Code:

Number of GPUs: 1

GPU #0:
  Name      : GeForce 7050 PV / NVIDIA nForce 630a
  PCI BusID : PCI:0:18:0

  Number of Display Devices: 1

  Display Device 0 (DFP-0):
     EDID Name             : FUS P20-2
     Minimum HorizSync     : 30.000 kHz
     Maximum HorizSync     : 82.000 kHz
     Minimum VertRefresh   : 51 Hz
     Maximum VertRefresh   : 75 Hz
     Maximum PixelClock    : 170.000 MHz
     Maximum Width         : 1600 pixels
     Maximum Height        : 1200 pixels
     Preferred Width       : 1600 pixels
     Preferred Height      : 1200 pixels
     Preferred VertRefresh : 60 Hz
     Physical Width        : 410 mm
     Physical Height       : 310 mm

the nvidia driver-version i use is 100.14.11 .

what i tried latest and i guess thats also how far you guys got as i can see is to create a modeline that uses a correct pixelclock value and the mode gets accepted (like andou's does):

Code:

(II) NVIDIA(0):   Validating Mode "1600x1200":
(II) NVIDIA(0):     1600 x 1200 @ 56 Hz
(II) NVIDIA(0):     Mode Source: X Configuration file ModeLine
(II) NVIDIA(0):        Pixel Clock      : 155.00 MHz
(II) NVIDIA(0):        HRes, HSyncStart : 1600, 1680
(II) NVIDIA(0):        HSyncEnd, HTotal : 1872, 2224
(II) NVIDIA(0):        VRes, VSyncStart : 1200, 1200
(II) NVIDIA(0):        VSyncEnd, VTotal : 1203, 1241
(II) NVIDIA(0):        H/V Polarity     : +/+
(II) NVIDIA(0):     Mode is valid.

i also tried various options in my xorg.conf, all with the more or less same results as described here, lately i used the options

Code:

Option    "UseEDID" "FALSE"
Option    "ModeValidation" "NoDFPNativeResolutionCheck"

but still my Xorg.0.log tells me

Code:

(WW) NVIDIA(0): Unable to use mode "1600x1200" for DFP-0; cannot compute
(WW) NVIDIA(0):     backend DFP timings (mode is larger than native backend
(WW) NVIDIA(0):     640 x 480).

so i guess that since the NoDFPNativeResolutionCheck-Option is set, somewhere a native resolution of 640 x 480 is chosen.
so if there would be a chance to also set this manually, i suppose it all could work, but who knows...

so well, if anyone has any suggestions or hints... please let me know...

maybe you guys already found a solution to this whole thing but continued your conversation via email or so?!?
you were posting so much but then a few days ago it all stopped... wonder what happened...

anyway, greetings, antiplex

tredegar · 08-18-2007, 02:49 AM

Antiplex,
Welcome to LQ!
I am surprised you have followed this long thread to the end.

Quote:

maybe you guys already found a solution to this whole thing but continued
your conversation via email or so?!?
you were posting so much but then a few days ago it all stopped... wonder what happened...

I don't know what happened. No emails (apart from sending the EDID file) as mods frown on this for obvious reasons. Maybe he fixed it, but I would have expected him to have said how. Hope he is OK and returns here sometime.

Your problem seems very similar, but your monitor's EDID file looks sensible. Andou's is strange. Please post your xorg.conf file. We do not need all of it, but Sections Monitor Device and Screen (With Subsection Display) would be useful.

antiplex · 08-18-2007, 03:42 AM

tredegar, how good to hear from you and thanks for that warm welcome!
well yeah, i guess one has to follow long threads in order to find a possible solution to a tricky and sort of uncommon problem... i also read the thread on ubuntuforums andou linked to in his first post here, but since the things you guys tried here seem to bring us closer to a solution and this hazzle seems not necessarily to be an ubuntu-specific problem i thought continuing here might be a good idea

.
so here are some parts of my xorg.conf:

Code:

Section "Monitor"
    Identifier     "P20-2"
    HorizSync       30.0 - 82.0
    VertRefresh     51.0 - 75.0
    ModeLine       "1600x1200" 155.0 1600 1680 1872 2224 1200 1200 1203 1241
    Option         "DPMS"
EndSection

Code:

Section "Device"
    Identifier     "Nvidia_7050"
    Driver         "nvidia"
    Option    "UseEDID" "FALSE"
    Option    "ModeValidation" "NoDFPNativeResolutionCheck"
EndSection

Code:

Section "Screen"
    Identifier     "Default Screen"
    Device         "Nvidia_7050"
    Monitor        "P20-2"
    DefaultDepth    24
    SubSection     "Display"
        Depth       1
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       8
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       16
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       24
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

i guess this all should be correct so far...
oh, btw, i found at least some temporary solution; when i connect my tft-panel by analog d-sub instead by dvi then the 1600x1200 resoltuion works fine but unfortunately the quality is nowhere as good (more blurry) as it is when connecting through the dvi cable, so this is not a permanent solution for me...
but i learned that the whole EDID-data seems to come through the dvi interface from my display but somehow seems to get interpreted incorrectly at some point (xserver? nvidia-driver? anywhere else?).
oh right, and as i stated in my first thread, i for sure already tried stuff like 'dpkg-reconfigure -phigh xserver-xorg' and other things people have suggested here and on the other thread.

tredegar · 08-18-2007, 07:55 AM

Your xorg.conf looks OK - but was this a version when you had 1600x1200 working, or not?

The problem seems to be narrowing down to how the EDID file is used / read / interpreted when the monitor is connected with the dvi interface.

Some things to try:
Try to stop running nvidia-configure scripts - they are complicating things, and not helping at the moment. Just keep making (small) changes to xorg.conf and restarting X

Get it working with analog d-sub at 1600x1200 (like you did before). Take a copy of your xorg.conf, call it xorg.conf.1600x1200.dsub
Try using that same xorg.conf with the dvi interface. It probably won't work, so ...
Construct an EDID file for your monitor, from the data that is read by X (see andou's post #26) when you startx with xorg.conf.1600x1200.dsub and are using the analog d-sub connection (because this works).
You may need to use a hex editor to do this,(eg khexedit), ask if you need help constructing this (binary / hex) file. Note we do not want a windows ASCII-type file.

Modify a copy of xorg.conf.1600x1200.dsub , so there is the option to read the EDID data from a file, rather than the monitor itself, pointing it at the binary EDID file you have created (which worked with the d-sub connection).
Startx using the dvi interface (but reading the EDID data from the file).
Any better?
Verbose logging will help here.
Hope you can see what I am trying to do here.

antiplex · 09-02-2007, 08:48 PM

tredegar, you won't believe it but i finally made it! i came across some more stones but finally managed to get things working! sorry for not posting back for some time now, but i was just too busy with various things like exams, work etc. a big amount of what came out as a solution was inspired by the hints and ideas and bits of information you and andou provided in this threas and i would probably never have found this without your very appreciated help! so let this be a big 'THANK YOU'!

let me tell you what i found out, it might be helpful for others that have the same problem:
first of all, in my case it seems not to be an issue of my display that is reporting the wrong data to the graphics adapter!
i saved my EDID (in the wrong 1280x1024 mode) just the way you described by using the nvidia settings tool's 'acquire EDID...' button, copied this file to my windows machine and made this stupid transformation from the binary edid to that crappy ascii pseudo-hex edid that the phoenix tool is capable to open.

i couldn't get an edid-file while connected via the sub-d cable because there simply is no edid file when one is not connected with the dvi-cable so you can't save it then with that nice 'acquire EDID...' button (or any other tool IMHO).

but anyways, when i openend the edid file with the phoenix tool, i was astonished to see that the native resolution (and also all other values i checked there) seems to be perfectly correct in my freshly extracted edid!

what i had found out though in the meantime through some research on the internet was, that there seems to be a bug in the current nvidia-driver when used with the recently released nforce 630a chipset (geforce 7050 onboard graphics) and a dvi-connected display with a resolution of 1600x1200 pixels.

so i thought we were in my case more or less on the wrong track but tonight i thought i'd give it another try and experimented a bit further with editing the edid file. well and finally, i got it working! there were loads of trial and error rounds and planty of frustration involved but finally (after going through like 10 xorg-logfiles) there was this combination that worked!

not everything might be necessary to get this working but i am way too tired to go back and forth again and 'refine' my results but still would like to share what i've done here.
again, please everybody be aware that by messing around with the edid-file and doing something wrong, your expensive 1600x1200 tft or any other components involved might get damaged! so do all this at your own risk!!!

so well, once you are able to open your extracted edid-file with phoenix you have done a big step and luckily you don't need to reverse the whole thing since there are only single hex-values that need to get changed depending on whats wrong according to Xorg.0.log and this can be done quickly by directly editing on the originally extracted edid-file (did i mention that you should keep a backup of every file before you change it?!?).

in the phoenix-editor we need to activate the 'edit-mode' that allows us to change values and the so called 'byte viewer' which saves us a lot of work by displaying all hex data i an small seperate window. both can be activated through the corresponding buttons in the programs toolbar. open a copy of the original extracted edid-file in any hex-editor and change the values described soon.

switch to the tab called 'standard timings'. in my case, only the first two timing id's were enabled and filled with useful data but this may depend on your specific model (in my case a fujitsu-siemens p20-2). interstingly timing id #1 contained what would be the correct data (1600, refresh 60, ar 4:3) while timing id #2 came up with the values that were finally choosen by the nvidia driver (1280, refresh 60, ar 5:4). my thought here was/is that some nvidia developer may simply access some array which holds these values incorrectly (classic!) so i changed timing id #2 to the exactly same values as timing id #1.
with the 'byte viewer' opened one can see that only single hex-fields change, namely the values '81' '80' in line 0x20 in column 0x08 and 0x09 become 'A9' '40' (so they are the same as the two values in the two preceding fields (evident)) and the very last hex-field changes as well. the last hex-field in line 0x70 column 0x0F is some checksum that needs to be correct, so don't forget this to change as well!

when i tried to apply this altered edid-file, the 1600x1200-resolution still got rejected with the entry in the Xorg.0.log :

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).

i found a pixel clock value of 155 (this may be a different value with different displays) defined in the 'timings'-section of the 'detailed timings'-tab (block 1), but found to change this to be a not so good idea. on the other hand, the phoenix-editor does not allow one to change the value of the 'refresh'-field right in the 'timing id #2'.
the solution to this is to generate a modeline (i used this online generator) and insert it into your xorg.conf into the 'monitor'-section.

so save the edited hex-file (you need the raw-hex-file, not what phoenix uses or outputs!) as newEDID.raw, make sure everybody has read-rights on it and copy it into /etc/X11/. in order to get this edid-file used instead of what comes directly from the display we further need to add the following lines in the 'device' section:

Code:

Option "AddARGBGLXVisuals" "true"
Option "UseDisplayDevice" "DFP-0"
Option "CustomEDID" "DFP-0:/etc/X11/newEDID.raw"

i am very unsure if the 'AddARGBGLXVisuals'-options is really needed, but i'll test this somewhen else i guess

. no other options like 'UseEDID' or whatever else we came across during the run of this thread are needed!

save everything and restart the xserver (or the whole machine) and welcome to the wonderful world of having your desktop at full resolution in some excellent dvi-quality!

hope i didn't forget anything and i further hope this helps some folks maybe!

good luck & cheers,
antiplex

tredegar · 09-03-2007, 11:21 AM

antiplex,
I am delighted that you managed to get your monitor working, especially as the ideas andou & I were bouncing back and forth have helped

.
At the moment, the bottom line seems to be that there's a bug somewhere, and the workaround is to get X to read the EDID data from a file, not the monitor itself, and this EDID file may need to be modified as you described.
In the interest of "completeness", could you please post the "Monitor" "Device" and "Screen" sections of your working xorg.conf. (The parts referring to your fonts, mouse, etc. are irrelevant to this problem).

Please also file a bug report with NVIDIA, if they are not already aware of the problem.

Thanks for posting your solution.

antiplex · 09-03-2007, 12:12 PM

your summary is correct.

i further agree that posting the relevant parts of my xorg.conf might be useful, so here we go:

Code:

Section "Monitor"
    Identifier     "P20-2"
    HorizSync       30.0 - 82.0   #possibly unneeded
    VertRefresh     51.0 - 75.0   #possibly unneeded
    Option         "DPMS"
    Modeline       "1600x1200" 155.00 1600 1632 2216 2248 1200 1225 1236 1261
EndSection

Code:

Section "Device"
    Identifier     "Nvidia_7050"
    Driver         "nvidia"
    Option	   "AddARGBGLXVisuals" "true"
    Option         "UseDisplayDevice" "DFP-0"
    Option         "CustomEDID" "DFP-0:/etc/X11/newEDID.raw"
EndSection

Code:

Section "Screen"
    Identifier     "Default Screen"
    Device         "Nvidia_7050"
    Monitor        "P20-2"
    DefaultDepth    24
    SubSection     "Display"
        Depth       1
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       8
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       16
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection     "Display"
        Depth       24
        Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

i am very sure that nvidia already knows about this problem, at least the support of my mainboard-manufacturer (asrock) said so. it seems to be specific to the nforce 630a chipset and occurs only with displays with a native resolution of 1600x1200 pixels.
i am currently waiting for some ppl with the same issue (*) to re-test what i described and will then link to here from the nvnews.net-forum which seems to be some sort of almost official support forum of nvidia.

* there is this nice german forum all about hardware where a big thread about my motherboard (asrock aliveNF7G-hdready) exists and where the problem with the not working 1600x1200 resolution is also discussed.
there i posted a similar guide to the solution i found (in german, post number 337 and 339) and i am sure someone will re-test the whole thing soon.

EDIT: not that important but i just realized this whole thread is in the 'linux - software' subforum; wouldn't it maybe make sense to move it to the 'linux - hardware' subforum?