Created attachment 71272 [details]
xorg.conf generated by Sax2 - hand edited to remove all but 1280x1024 mode

Hmm, that should be 1280x960, sorry...

Just done some further testing... selecting 1400x900 also displays 1280x960.

Changing to 1280x800 displays 800x600

1024x768 displays 1024x768

Choosing 1280x960 itself causes Sax2 to display a white screen, requiring an alt+ctrl+backspace X reset... (Tip: remember to switch to the right keyboard before hitting a+c+b, otherwise you loose the bugzilla session :-P)

Created attachment 71273 [details]
Xorg.0.log

Interesting, from the log, it looks like 1280x1024 fails the hsync test, even though this is a valid mode and is the native mode of the monitor. Looks like something might be a little fubar with the recognition routines somewhere along the line.

It looks like it is the mode recognition in conjunction with a DVI interface. I swapped to a plain VGA D-SUB analogue interface and it re-booted straight into the correct 1280x1024 mode.

So I would guess something is borked when getting valid frequencies for a monitor connected to the DVI output...

If you don't mind call:


   init 3
   sax2 -r -a

--> send the log file /var/log/SaX.log

   rm -f /var/log/X*
   X

   Ctrl-Alt-BackSpace

--> send the log file /var/log/Xorg.0.log

Thanks

Created attachment 71378 [details]
SaX log per request from Marcus Schaefer 2006-03-06

Results of running sax2 -r -a

Thanks SaX.log looks good to me. So if you now call

  rm -f /var/log/X* 
  X

and send me the second part of the information:

 --> send the log file /var/log/Xorg.0.log

I will be able to see why it doesn't start in 1280x1024

Thanks 

Created attachment 71383 [details]
Xorg.0.log per request from Marcus Schaefer 2006-03-06

OK, finally managed it, the first time I tried X followed by a+c+BS it resulted in a series of vertical black and white stripes and required a hardware reset... I re-did the complete test and the second attempt worked.

sorry forget to ask for the written config file:

 /etc/X11/xorg.conf

Thanks

sorry sorry I need the information from

   hwinfo --monitor

as well

Thanks a lot

Created attachment 71408 [details]
xorg.conf per request from Marcus Schaefer 2006-03-06

As generated by the last request. With this display the PC is using 800x600 when connected to DVI and 1280x1024 when connected to the VGA D-SUB port.

Created attachment 71409 [details]
hwinfo output per request from Marcus Schaefer 2006-03-06

Output from "hwinfo --monitor" when running in theoretical 1280x1024, actual 800x600 whilst connected to the DVI port.

Thanks for the information, two problems here:

1) the DDC specs doesn't contain sync ranges, therefore the sync range
   has to be obtained from the resolution specific settings. This code
   has been added to sysp

2) the DDC resolution specific sync contains only the vsync value which
   requires the hsync value to be estimated. Because I don't want that I
   found in the nvidia log file an enhanced EDID block containing the
   hsync range information. The data has been added to the CDB

bug should be fixed now

Just tried it on Beta 8, the problem is still present :( Works fine with VGA, with DVI it will do a maximum of 1280x960, not the selected, and for monitor default 1280x1024

If it doesn't work with DVI would you provide the information from
comment #5 while your monitor is connected to the DVI port. Thanks

I'm wondering why this happens because I added the following
specs to the CDB

#==============================================
# IQ17 (Digital)
#----------------------------------------------
HYUNDAI:IQ17 (DIGITAL)  {
 DDC=IQT217D
 Option=DPMS
 Hsync=31-63
 Resolution=1280x1024
 Vsync=50-60
}

Created attachment 73915 [details]
SaX.log from Beta 8

Created attachment 73916 [details]
Xorg.0.log from Beta 8

Created attachment 73917 [details]
hwinfo -monitor output from Beta 8

Created attachment 73918 [details]
xorg.conf from Beta 8

Thanks for the information. It seems the nvidia drivers internal
mode pool doesn't have an appropriate modeline for 1280x1024 very
strange. If you don't mind include the following Modeline:

   Modeline "1280x1024" 103.24 1280 1360 1496 1712 1024 1025 1028 1058

into the Modes section of the /etc/X11/xorg.conf file:

   Section "Modes"
    Identifier   "Modes[0]"
    ---> include Modeline here 
   EndSection

now restart the X server. Does it help ?

Thanks

Sorry, doesn't make any difference I'm afraid :-(

*grr* me to. Could you send me the coresponding Xorg.*.log
file ? Thanks

Created attachment 73930 [details]
Xorg.*.log from Beta 8 *after* Modeline insterted

Does it work with the following modeline:

  Modeline "1280x1024" 102 1280 1360 1496 1712 1024 1025 1028 1058

Thanks for testing

Sorry, that doesn't work either :-( And going into Sax2 now says that the configuration is not valid and it tries to create a new version, which leads to a blank screen...

I don't understand what's going on on your system. To debug such a
problem you should be in runlevel 3

   init 3

no other X-Server around no windowmanager system like Gnome or
KDE running. include the Modeline from comment #24 manually
using your favorite editor.

Now remove all X logs

   rm -f /var/log/X*

and start bare X by typing

   X

kill the server with the key combination

   Ctrl-Alt-BackSpace

and finally send the new log /var/log/Xorg.0.log

The Modeline above fits into the range I see no reason why the
X-Server denies to use it. The weird thing is that the log tells
me that exactly 60Hz is required like a fixed clock monitor which
is surely not true, also weird is that calling int10 to obtain the
bios data like hwinfo does didn't provide any range. All this together
points to a really weird hardware (monitor)

let's see what the log said
Thanks

OK, I'll get on doing the test in a moment. The Sax2 configuration problem was just when I had done the changes, gone back into Gnome to test after a reboot and double checked with Sax2 what the configuration said and what it tested as, that was when it went phut.

For most of the testing I am in init 3.

Created attachment 73952 [details]
Xorg.93.log in reference to Comment #26

It didn't create a .0.log, just the .93.log...

I think this is a bug in the nvidia driver. I tells me:

   (II) NVIDIA(0):   VertRefresh : 60.000 Hz

you need a modeline with exactly 60.000 Hz otherwise the mode gets
deleted with "vsync out of range" which is wrong. I think your monitor
doesn't report a valid DDC record which triggers the nvidia problem and
may explain the hwinfo behavior as well.

I'm sorry but I can only offer to add the option

   Option "NoDDC"

into the Section "Device" of your xorg.conf maybe this helps ?

That has done the trick.

The bug with the nVidia driver is new in its interaction with 10.1.

Using Xorg 6.8 and the drivers from YOU under 10.0 the monitor is recognised correctly...

Either the driver I am using in 10.0 is older and doesn't have this bug, or the patch file for 10.1 introduces this problem I would guess...

Anyway, thanks for your patience with this problem.

Hmm, Stefan do you know if there is a change in the nvidia driver
which may cause the mentioned problem ? I'm currently thinking to
enable NoDDC by default... 

Andy R. told me that the NVIDIA driver tries to use the modelines provided in the EDID info block by the monitor. (X --logverbose 5 gives you more informations about the EDID block). NoDDC is an alias for IgnoreEDID and will disable this feature. I think in most cases using EDID is quite helpful.

yes I agree so it is not a good idea to use IgnoreEDID by default
David I will close this now because I think it cannot be solved
in a general way. I'm pretty sure in this case it's needed but it
doesn't affect other systems otherwise I would have received lots
of bug reports concerning this.

I'm hoping it's ok for you to live with the workaround. The mentioned
option can be selected in sax2 as well so there is no need to manually
edit the config file. It is named "IgnoreEDID" in the list of sax2

Thanks