Nvidia Resolution on Suse 11.3

I’ve tried installing Nvidia drivers on opensuse 11.3 (32 bit) for my graphics card which is a GeForce 250 GTS

Regardless of whether I do it ‘the hard way’ which I’m familiar with, or the Yareg repository way found on this forum I get the same behaviour

Best resolution I can get after installing Nvidia drivers is 640x480, if I rename xorg.conf in an attempt to force auto-detection I get 1024x768

I’ve tried everything I can find on nvidia drivers for 11.3 like adding nomodeset to the menu.lst grub entry, setting no_kms_in_initrd to yes, definitely installing under runlevel 3 etc

Same thing happens, I can run nvidia-settings ok which I think suggests the driver is installed and initialised, nothing I try will let me use better than 1024x768

Any ideas how I can get better resolutions?

Same machine with 11.2 installed handles 1680x1050 perfectly

Hi Ecky

I have the same video card and a dual head setup (1920x1200 / 1680x1050) on 11.3 64bit. I also used the Yareg repo.

This is what worked for me…

1> Installed nvidia driver from repo.
2> Reboot
3> Adjust resolution(s) in krandr
4> Call up nvidia setting manager and ensure resolutions are ok.
5> Under “X Server Display Configuration” use the “Save to C Configuration File” button. De-select the merge function and hit ok.
6> Reboot.

I did nothing with the “nomodeset” parameter. Other than that I have no other ideas. (Not a graphix card guru)

HTH - Cromulent

Cromulent there seems to be a lot of luck involved … I’m not having any

I’ve tried every suggestion I can find on how to make the drivers work, reinstalling the drivers something like a dozen times in the process, nothing seems to resolve my problem

Driver installs and loads ok, just doesn’t give me resolutions any better than if it was windoze 95 I’d installed, I think part of the problem is that my monitor is not being detected correctly and I don’t know what to do about that

The best solution for me I think might be to just reinstall 11.2 and revisit 11.3 later when all these issues people seem to be getting have been ironed out to some degree

It’s a shame really, in a perfect world newer versions of an os would have better hardware support but the changes going on with xorg seem to be throwing a spanner in the works as far as that’s concerned though I’m sure it’ll all come good eventually

Just a darned nuisance in the meantime

I totally feel the same, Ecky. This sucks. I had no success either. SUSE was not ready when the released the version. Seems they haven’t tested it. Actually I tend to move to another distribution. Beside yast, sax2 was one of the main reason I used SUSE at all. Nvidia cards always worked (and that was the main reason I bought this cards) - until now.

Any ideas how I can get better resolutions?

Same machine with 11.2 installed handles 1680x1050 perfectly

Hi Ecky, in order to try to help you, more info is required. I have seen issues with nvidia drivers and monitor EDID not being read correctly.

  1. Do you have your /etc/X11/xorg.conf from openSUSE 11.2 available? (Its often a good idea to back up files such as this befire upgrading).

  2. Can you provide details about the monitor connection? (Eg laptop display, VGA cable, DVI cable)

  3. Can you post your Xorg.0.log output to pastebin (or similar) and just post the link to it here.

cat /var/log/Xorg.0.log

This might be helpful too

xrandr

From that, I’m sure someone may be able to help further with this.

Guess I’ll jump into this. I just tried installing 11.3 yesterday after my 11.1 version croaked. Several problems to work through, but the one bugging me now is that I can’t get a monitor resolution better than 1024x768. I’ve tried copying the old xorg.conf file, but X won’t start up at all with it.

There is no longer a provision to specify which monitor you have. Apparently it assumes that monitor status can be retrieved through DCC protocol, but mine doesn’t support that. Oh and the xorg.conf file is gone, having been replaced with a lot of files in xorg.conf.d. I modified 50-monitor.conf with the stats for my particular monitor (an AMW CM1997PF) but that hasn’t helped.

In the meantime, I’m going to try reinstalling 11.1, which I’ve been holding on to because it is the last version supporting KDE 3 :frowning:

According the xorg.log files, all the better resolution modes are being rejected for (unknown reason) or for (hsync out of range). If I change the monitor horizonal sync range to cover the entire world, all of the (hsync out of range) complaints go away, but the (unknown reason) remain and I still don’t get any better video resolution. Turning up the log verbosity hasn’t added any more useful information.

Kencx, please note that deano_ferrari’s request for more technical information is still valid also in your case … ie please open up the file /var/log/Xorg.0.log with a text editor, and copy its contents and paste it on the web site pastebin](http://pastebin.org), press the SUBMIT on that web site, and then copy/paste here the URL/Website-address where the content is located.

Do the same for the content of the file /home/kencx/.xsession-errors (ie copy to pastebin and post here url/address) and do the same for the output of ‘xrandr’.

That might shed some light on what is exactly happening.

While I’m confident you have looked at this and made an assessment, maybe by providing that information other’s may have some ideas.

Tried some more experimenting. I am way over my level of incompetance here, but I tried using cvt and randr to set up a better resolution and got a curious and possibly significant error.

ken@corbin01:~> cvt --verbose 1400 1050

1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz

Modeline “1400x1050_60.00” 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync
ken@corbin01:~> xrandr --verbose --newmode “1400x1050_60.00” 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync
X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 150 (RANDR)
Minor opcode of failed request: 16 (RRCreateMode)
Serial number of failed request: 23
Current serial number in output stream: 23

What might this mean? Why would xrandr --newmode be needing a named color or font???

@kencx: Please start from the beginning and supply the requested info. Then we may be able to assist. Otherwise we’re playing guessing games. Forget trying to add new display modes via xrandr for the moment.

Sorry, I’m still getting a handle on how pastebin works. Uploading files didn’t seem to work out, but opening the file in a text editor and pasting it from there did.

Since my last post, I’ve tried installing the nvidia proprietary driver. That opened up several new resolutions, but none higher then 1024x678. The Xorg.log file that results no longer lists the nodes that aren’t being accepted.
pastebin - Xorg.0.log - post number 1917852

xrandr output now is
ken@corbin01:~> xrandr
Screen 0: minimum 320 x 175, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
1024x768 50.0 51.0 52.0 53.0 54.0*
832x624 55.0
800x600 56.0 57.0 58.0 59.0 60.0
720x400 61.0
700x525 62.0 63.0
640x480 64.0 65.0 66.0 67.0
640x400 68.0
640x350 69.0
512x384 70.0 71.0 72.0
400x300 73.0
320x240 74.0 75.0
320x175 76.0

I still have some old log files from before I installed the nvidia driver. These look like
pastebin - Mine - post number 1917854

And the latest .xsession-errors looks like…
pastebin - Stuff - post number 1917858

Would this make more sense if I switched back to the open source driver?
Thanks…

Nothing new to add. I wanted to subscribe to this thread and haven’t found a way to do that without submitting another post :frowning:

Ok, your xorg log results show your EDID (from your monitor) is ‘buggy’ in that it doesn’t advertise the native resolution correctly. This causes Xorg to use the wrong display mode.

You can aquire this EDID info via the graphical ‘nvidia-settings’ utility, then save and edit the (128 byte) edid.bin file. This will require a hex editor and some reading to adjust the relevant bytes. This isn’t as hard as it may sound, it just takes some patience and careful editing.

This is a good reference:

Fixing Ugly DVI/HDMI Displays due to EDID bugs on nVidia drivers | analogbit.com

This blog may also be helpful:

freshnewpage blog

If you prefer, you can use this windows utility:

Download Phoenix EDID Designer - Freeware Software - Tucows

The resulting edid.bin file can then be used by adding a line like this to xorg.conf screen section, or 50-screen.conf:

Option "CustomEDID" "DFP-0:/etc/X11/edid.bin"

Your display name might be VGA-1 (based on your xorg log info).

Great post deano_ferrai.

I was curious if Phoenix EDID Designer (PED) worked under wine. A quick surf told me that while PED will run under wine, depending on what one does, in some cases it needs to read the data from the MS-Windows registery (and hence a windows machine is needed for it (like you noted)).

Thanks oldcpu. I’m hoping kencx is confident enough to undertake this exercise, because it will assist others with similar display problems (when problematic EDID is the cause). I will assit where/if I can.

It is an interesting observation though, that most users with incorrect display modes reported, seem to have have nvidia hardware and proprietary drivers.

I’m hoping this will help simplify things, and that I haven’t made any mistakes or incorrect assumptions along the way…

Derived from your Xorg.0.log, the raw edid info:

00 ff ff ff ff ff ff 00 7f ff 10 21 00 00 00 00
30 0d 01 01 0c 23 1a 78 8e 55 97 48 42 73 97 77
7e 7e 80 74 73 97 87 52 84 73 97 77 7e 7e 80 74
81 40 71 4f 61 59 f9 15 20 f8 30 58 1f 20 20 40
13 00 36 e6 10 00 00 1f 00 00 00 fc 00 43 4d 31
39 39 37 50 46 0a 00 00 00 00 00 00 00 ff 00 30
0a 20 20 20 20 20 20 20 20 20 20 20 00 00 00 fd
00 32 96 1e 61 15 00 0a 20 20 20 20 20 20 00 3b

Based on the blog info, the horizontal resolution value is contained as a hex value, with the first character of the 58th byte containing the first hex digit, and the remaining digits contained in the 56th byte. Yours currently reads like 320h (or 800 dec), referring to the ‘20 f8 30’ sequence within 4th line of the edid values. Don’t worry if this seems confusing, it was to me as well :slight_smile:

Anyway, for a horizontal resolution of 1400 (equates to 578 hex), it should be ‘78 f8 50’


00 ff ff ff ff ff ff 00 7f ff 10 21 00 00 00 00
30 0d 01 01 0c 23 1a 78 8e 55 97 48 42 73 97 77
7e 7e 80 74 73 97 87 52 84 73 97 77 7e 7e 80 74
81 40 71 4f 61 59 f9 15 78 f8 50 58 1f 20 20 40
13 00 36 e6 10 00 00 1f 00 00 00 fc 00 43 4d 31
39 39 37 50 46 0a 00 00 00 00 00 00 00 ff 00 30
0a 20 20 20 20 20 20 20 20 20 20 20 00 00 00 fd
00 32 96 1e 61 15 00 0a 20 20 20 20 20 20 00 3b



This info would need to be copied as raw hex to a file, and saved, then referenced from the xorg.conf option like this


Option “CustomEDID” “DFP-0:/path/to/file/custom_edid.bin”



Note: Your nouveau driver seems to refer to VGA-1 for the display device, while your nvidia driver uses CRT-0, so I'm deducing that you're using a VGA (analog) cable connection.

Finally, I wanted to share this thread in case it is also useful:

[Toshiba resolution EDID fix - nV News Forums](http://www.nvnews.net/vbulletin/showthread.php?t=81635)

Interim results. I’ve had some issues retrieving the EDID info. When I run it nvidia-settings doesn’t seem to have an acquire EDID option. Has a GPU 0 option, and a CRT-0 item under that. But the CRT-0 doesn’t have an Acquire EDID button. Just sliders for Digital Vibrance and Overscan.

Running the get-edid utility displays lots of warning messages and apparently was only partially successful. And running parse-edid on the result warns me that the checksum is incorrect.


corbin01:/home/ken # /usr/local/sbin/get-edid >edit.bin
/usr/local/sbin/get-edid: get-edid version 2.0.0

    Performing real mode VBE call
    Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
    Function supported
    Call successful

    VBE version 300
    VBE string at 0x11100 "NVIDIA"

VBE/DDC service about to be called
Report DDC capabilities

    Performing real mode VBE call
    Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
    Function supported
    Call successful

    Monitor and video card combination does not support DDC1 transfers
    Monitor and video card combination supports DDC2 transfers
    0 seconds per 128 byte EDID block transfer
    Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

    Performing real mode VBE call
    Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
    Function supported
    Call failed

But, a hex dump of the edid.bin file shows results that are identical with what you reported from the xorg.log file, so I guess whatever it is getting is the same thing that the nvidia driver is seeing. On that basis, I’m going to proceed on the assumption that that is the correct (but buggy) EDID info that needs to be fixed.

Oh yea, I’ve using the same monitor cable for over a decade, so I’m sure it is a VGA analog cable. I’ve upgraded computers and monitors several times since then, but it never occurred to me that a newer cable might be necessary. Is that something I should think about doing?

More to follow…

Running the get-edid utility displays lots of warning messages and apparently was only partially successful. And running parse-edid on the result warns me that the checksum is incorrect.

Yes, that is also reported in Xorg.0.log, but AFAIK its not important. In fact many of the hacks I’ve seen online do not attempt to correct the last byte which contains the checksum.

But, a hex dump of the edid.bin file shows results that are identical with what you reported from the xorg.log file, so I guess whatever it is getting is the same thing that the nvidia driver is seeing.

Yes, thats right. The other utilities just offer more convenient methods to aquire this data and store in a hex file.

Its important to note, that the data as posted is only text. You need to copy it as a hex file. There is a utility called ‘ghex’ that can help here. (It lets you view data as hex or ASCII characters). Some of the traditional editors eg Midnight Commander (mc) can also be used, but may present another unnecessary level of complexity for you.

Now, yesterday I mentioned the horizontal bytes within the EDID block. Well, the 59th and 61st byte encode the vertical resolution in the same way. Your values are ‘58’ and ‘20’ hex (=> 600). (I’m not sure whether they need changing too, or whether it is sufficient for Xorg to use the horizontal value only). Anyway, if it does need chnaging to allow for a vertical resolution of 1050, then these bytes would need to change to ‘1A’ and ‘40’ respectively.

The parse-edid utility can then be used to check the encoded resolution to make its as intended.

Oh yea, I’ve using the same monitor cable for over a decade, so I’m sure it is a VGA analog cable. I’ve upgraded computers and monitors several times since then, but it never occurred to me that a newer cable might be necessary. Is that something I should think about doing?

No, it isn’t a cable issue. It just reflects the kind of connction, and therefore display name used by driver etc. Newer cards and monitors may offer HDMI or DVI for example.

Have to drop this for now. But wanted to bring you up to date.
No success so far. I can’t get the driver to read the customized (binary) edid.bin file. No matter what I do, it continues to show the results from the original EDIT data.

When I tried bumping the verbosity level up to 9 in an attempt to figure out why, nothing obvious appeared. But I did notice that all of the resolutions that I haven’t been able to get are showing up as valid. Then being dropped at the last minute by the default mode checker. Which kind of implies that they are available if I select them manually. I did a little experimenting and found that I can, in fact, select higher resolutions and have them take effect. But the screen positioning is always off, most or all of the desired window doesn’t appear on the screen, making the resolution useless.

I have some more experimenting to do, hopefully I can get the EDID data accepted and see if that makes a difference. But have to run for now.

Original verbose log file…
pastebin - Untitled - post number 1918485

Thanks,

No success so far. I can’t get the driver to read the customized (binary) edid.bin file.

But I did notice that all of the resolutions that I haven’t been able to get are showing up as valid. Then being dropped at the last minute by the default mode checker. Which kind of implies that they are available if I select them manually. I did a little experimenting and found that I can, in fact, select higher resolutions and have them take effect.

So, does the output of ‘xrandr’ offer higher resolution now? Please post when you have time.

Looks like you’ve made progress. Your Xorg.0.log results look better, and show that ‘1400x1050’ display mode is valid (among others). It may be that you just need to add a preferred mode to xorg.conf (or 50-monitors.conf) as explained here:

(http://forums.opensuse.org/english/get-help-here/hardware/442615-i-cant-change-screen-resolution-suse-11-3-a.html)

The output of the xrandr was unchanged. Not really a surprise, from what I can tell from the logs the default preferred mode was a nvidia default selection that somehow assumed the maximum window size should be 1024x768 and removed all modes that didn’t fit that window.

Based on comments in the nvidia manual, I started out by adding a Display subsection to the xorg.conf screen section, and listed a set of modes that I wanted to be available. That worked in that it got me the desired resolution, but failed because the main Gnome window size never matched the actual display window size. This turned out to be an artifact of the way I was testing it. You get the same effect if you run startx – :2 from a command line shell, or pick a normal session and use cntl alt + to switch to a different node. It does scale the main window correctly if you launch gdm and log on through it. There may be a bug there that should be reported, but its minor and isn’t bothering me.

After reading your last post, I tried backing that change out and adding a Option “Preferred Mode” to the monitor session. That turned out to have the same effect, and was simpler to implement.

So, I now have all of the resolutions my monitor and card will support and am very very happy. I suspect this is a bit of a workaround rather than a fix for the underlying problem, but I am happy with it.

As mentioned before, you don’t get a list of the valid modes out of the nvidia driver at normal logging levels. If you bump the log level up to 9, the valid modes start getting logged which can be useful if you are wondering which mode you should list as the new preferred mode for this monitor. There may be easier ways to do this, but I generate verbose logs by switching to run level 3, then logging on a user session and entering

startx – :1 --logverbose 9

Thanks very much for your help. I’m moving on to the next in a depressing long list of 11.3 issues…