[nvidia-glx] Resolutions lost on upgrade from Edgy to Feisty [nvidia-glx-legacy][nvidia-glx-new]

Bug #91292 reported by Paul McGarry on 2007-03-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.20 (Ubuntu)

Bug Description

Binary package hint: nvidia-glx-legacy

I have a PC with a Nvidia TNT2 card in it.
It was running Dapper and I upgraded it to Edgy without any problems (using update-manager).
I then upgraded (again using update-manager) to Feisty and after the reboot my X came back at a low resolution rather than the 1600x1200 I usually have.
Switching to the nv driver everything worked again.

Looking at the Xorg log files it seems that when using the Feisty binary Nvidia driver it wasn't picking up the Horizontal and Vertical refresh rates from my monitor and was using very low defaults.

I got it to work by taking the refresh rates as discovered by the nv driver and manually defining them in the xorg.conf file in the monitor section, ie:

        HorizSync 30-95
        VertRefresh 50-160

This got things working properly, but presumably the loss of whatever functionality that had it working out of the box in Dapper and Edgy is a regression.

Paul McGarry (paul-paulmcgarry) wrote :
description: updated

i have the same problem
nvidia-legacy worked perfectly on edgy at 1024x768
on feisty only at 800x600
and no way to make it work even by manually editing xorg.conf

VincentRC (vreneco1) wrote :

Exactly the same problem for me too. I have a nvidia Geforce2 Ti

Same problem here with GeForce2 MX100/200.
The resolution can only get up to 800x600 while the "nv" driver can do 1280x1024.

By editing my xorg.conf I got it working again for 1280x1024@75Hz:
Section "Monitor"
        Option "HorizSync" "30-82"
        Option "VertRefresh" "56-76"

These were the values my "nv" driver reported and also seems to work with the "nvidia" driver

I've hit this with a GeForce 1 on a clean Feisty install. I too needed to add HorizSync/VertRefresh lines in order to get the desired resolutions. Confirming.

Changed in linux-restricted-modules-2.6.20:
status: Unconfirmed → Confirmed
Sitsofe Wheeler (sitsofe) wrote :

(I will just note that as with the other reporters the open source nv driver was working correctly. The nvidia binary driver seems to be very weak at deriving the refresh rates for itself)

Ben Hodgetts (enverex) wrote :

What version of the nVidia drivers are you using? The 8776 drivers were always broken because they don't probe for EDID data which is the thing that tells the driver what screen modes your monitor is capable of displaying.

Changing title to something more appropriate as it affects all Feisty installations using the binary nvidia driver(s) rather than just a smaller subset of users who have upgraded, as per comment 7.
(First time I've changed a subject in launchpad, apologies if it doesn't work).

Sitsofe Wheeler (sitsofe) wrote :

I was using the nvidia-glx-legacy drivers (so 71xx) however there are duplicates from people using nvidia-glx and nvidia-glx-new in Feisty which are 96xx and 97xx respectively.

I think you changed the title of your post rather than of this bug. Use "Edit description/tags" at the top left

Medya (medya) wrote :

I have the same problem !

Medya (medya) wrote :

read this blog post about this bug and how to solve the problem :

Sitsofe Wheeler (sitsofe) wrote :

The "composite disables GLX" problem is Bug #91064 (and doesn't really have anything to do with making things faster but that's a different story).

To avoid complicating this bug can folks avoid posting to this particular bug if their problem isn't that of a seeing a low resolution after enabling the nvidida drivers. If the screen is black or you are having problems with desktop effects/beryl/compiz please try searching for other bugs in launchpad (https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=nvidia ) that better fit your issue and filing a new bug report if nothing matches.

Bryce Harrington (bryce) wrote :

This also sounds much like bug 3731, which many people have reported. I don't know if it's driver-specific, but the problem can be traced down to xresprobe, which is not reporting the resolutions correctly.

Also, xresprobe is not installed by default on Feisty, so I wonder if people who upgrade from Edgy->Feisty might be losing xresprobe, and then when x reconfigures it misses the refresh rates? Or else perhaps xresprobe is unable to interpret the EDID data from these nvidia cards?

Sitsofe Wheeler (sitsofe) wrote :

Could you tell me what a metabug is?

Tim Hollen (gyorgy2000) wrote :

With nv my monitor was not detected, so I manually inserted horzsync/vert and got the monitor running at correct resolution.
Upon switching to nvidia drivers I lost the screen resolution in the gui.

I had to manually edit under dapper and edgy but the edited xorg was always enough for both nv and nvidia.
lspci -n | grep 0300
01:08.0 0300: 10de:0110 (rev b2)
02:00.0 0300: 10de:00f3 (rev a2)

lspci | grep VGA
01:08.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
02:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6200] (rev a2)

and Xorg.log
(II) NVIDIA(1): NVIDIA GPU GeForce2 MX/MX 400 at PCI:1:8:0 (GPU-1)
(--) NVIDIA(1): Memory: 32768 kBytes
(--) NVIDIA(1): VideoBIOS:
(--) NVIDIA(1): Interlaced video modes are not supported on this GPU
(--) NVIDIA(1): Connected display device(s) on GeForce2 MX/MX 400 at
(--) NVIDIA(1): PCI:1:8:0:
(--) NVIDIA(1): @@@ (CRT-0)
(--) NVIDIA(1): @@@ (CRT-0): 350.0 MHz maximum pixel clock
(II) NVIDIA(1): Assigned Display Device: CRT-0
(WW) NVIDIA(1): No valid modes for "1280x1024"; removing.
(WW) NVIDIA(1): No valid modes for "1152x864"; removing.
(WW) NVIDIA(1): No valid modes for "1024x768"; removing.
(WW) NVIDIA(1): No valid modes for "800x600"; removing.
(WW) NVIDIA(1): No valid modes for "640x480"; removing.
(WW) NVIDIA(1): Unable to validate any modes; falling back to the default mode
(WW) NVIDIA(1): "nvidia-auto-select".
(II) NVIDIA(1): Validated modes:
(II) NVIDIA(1): "nvidia-auto-select"
(II) NVIDIA(1): Virtual screen size determined to be 800 x 600
(**) NVIDIA(1): DPI set to (65, 65); computed from "DisplaySize" Monitor

Sitsofe Wheeler (sitsofe) wrote :

There's not quite enough information in that snippet to work out whether the driver used your xorg.conf sync ranges - it would be helpful to see the complete Xorg.log. There is a variation of this bug which people have solved using a more brutal workaround though. Could you spin off a new bug report and post a link from this bug towards it?

On Sat, Apr 28, 2007 at 07:05:46AM -0000, Sitsofe Wheeler wrote:
> Bryce:
> Could you tell me what a metabug is?

Brian Murray uses that tag for frequently reported bugs.

Download full text (4.8 KiB)

Hi guys,
I have been plagued with the poor EDID stuff on my toshiba from day one. Anyway. I was looking through the docs and trying to get a better idea of why 1024x768 was not valid. The docs point you to running x as follows:

startx -- -verbose 6 -logverbose 6

this resulted in the EDID information in my Xorg log. Here is the stuff which was important:

(--) NVIDIA(0): --- EDID for Nvidia Default Flat Panel (DFP-0) ---
(--) NVIDIA(0): EDID Version : 1.3
(--) NVIDIA(0): Manufacturer : NVD
(--) NVIDIA(0): Monitor Name : Nvidia Default Flat Panel
(--) NVIDIA(0): Product ID : 0
(--) NVIDIA(0): 32-bit Serial Number : 0
(--) NVIDIA(0): Serial Number String :
(--) NVIDIA(0): Manufacture Date : 2002, week 45
(--) NVIDIA(0): DPMS Capabilities : Standby Suspend Active Off
(--) NVIDIA(0): Prefer first detailed timing : Yes
(--) NVIDIA(0): Supports GTF : No
(--) NVIDIA(0): Maximum Image Size : 320mm x 260mm
(--) NVIDIA(0): Valid HSync Range : 29 kHz - 49 kHz
(--) NVIDIA(0): Valid VRefresh Range : 0 Hz - 60 Hz
(--) NVIDIA(0): EDID maximum pixel clock : 70.0 MHz
(--) NVIDIA(0):
(--) NVIDIA(0): Detailed Timings:
(--) NVIDIA(0): 969 x 768 @ 60 Hz
(--) NVIDIA(0): Pixel Clock : 65.00 MHz
(--) NVIDIA(0): HRes, HSyncStart : 969, 1048
(--) NVIDIA(0): HSyncEnd, HTotal : 1184, 1344
(--) NVIDIA(0): VRes, VSyncStart : 768, 771
(--) NVIDIA(0): VSyncEnd, VTotal : 777, 806
(--) NVIDIA(0): H/V Polarity : -/-

Now the thing I notices was that it was under the impression that the DFP was 969 pixels. This was a pain. It's 1024. The 1024 was being reject as it was too big for the DFP. It also explained why there was a black line on the right at lower modes (the scale was to 969, missing the last 55px off. Here clearly was my EDID problem in evidence.

Now the solving - it's nasty but works for me. The drive allows for EDIDs to come from another file:

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

the place to get that EDID file is a dump from nvidia-settings. Now to hunt down 969 and set to 1024. Hexedit for the binary file was used. 969 in Hex = 3C9, 1024 = 400. So I had to change 3C9 to 400 and I was a winner. The edid data from the file is:

(--) NVIDIA(0): Raw EDID bytes:
(--) NVIDIA(0):
(--) NVIDIA(0): 00 ff ff ff ff ff ff 00 3a c4 00 00 00 00 00 00
(--) NVIDIA(0): 2d 0c 01 03 80 20 1a 00 ea a8 e0 99 57 4b 92 25
(--) NVIDIA(0): 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
(--) NVIDIA(0): 01 01 01 01 01 01 64 19 c9 77 31 00 26 30 4f 88
(--) NVIDIA(0): 36 00 42 ff 10 00 00 18 00 00 00 fc 00 4e 76 69
(--) NVIDIA(0): 64 69 61 20 44 65 66 61 75 6c 00 00 00 fc 00 74
(--) NVIDIA(0): 20 46 6c 61 74 20 50 61 6e 65 6c 00 00 00 00 fd
(--) NVIDIA(0): 00 00 3c 1d 31 07 00 00 20 20 20 20 20 00 00 06
(--) NVIDIA(0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(--) NVIDIA(0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(--) NVIDIA(0): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(--) NVIDIA(0)...


Sitsofe Wheeler (sitsofe) wrote :

An easier way to override EDID data reported (since you were able to deduce that it was that preventing your resolution) is to use Option "UseEDID" "False" as described in Bug #105957 . Do you know if the nv driver was able to get correct EDID information?

Jonathan Lozinski (j-lozinski) wrote :

Sorry, I neglected to mention that UseEDID causes massive corruption on the screen. This is why I needed to debug the EDID data and give a propper fix. The EDID thing used to work in earlier drivers, but not any more..

I know the nv driver worked at 1024, however not sure about the EDID data. I suppose if I debuged would it show it like the nvidia? Do you suppose there is a way to have the nv driver dump the edid.bin data, and then force the nvidia driver to use that, possibly optionally, to create a more robust fix for others?

Sitsofe Wheeler (sitsofe) wrote :

Hmm the fact that UseEDID causes massive corruption is practically worth a bug of its own. Could you spin that off into a new bug and post a link to the newly created bug here?

As for being able to dump the edid from the nv driver - I doubt it. It might be interesting to see the Xorg.0.log that the nv driver makes in your new bug though.

Sitsofe Wheeler (sitsofe) wrote :

Jonathan's new bug is Bug #123820.

syncomm (syncomm) wrote :

The edit of the edid.bin fixed the issue for me with a Toshiba Tecra (GeForce4 420 Go) -- I still can't understand why the NV driver gets:

(--) NV(0): Panel size is 1024 x 768

and the nvidia driver only sees 969 (verified via nvidia-settings)

I posted some attachments related to this in Bug #123820

kklaine (kklaine) wrote :

This is still an issue with Hardy Heron apparently.

I'm using:
nVidia Corporation NV15DDR [GeForce2 Ti] (10de:0151)

And using Marcel's instruction's from post #6 enabled my max resolution.

  • unnamed Edit (1.1 KiB, text/html; charset=ISO-8859-1)

I actually downloaded the latest version and unrared it to my C drive. I
installed it directly from the C drive and everything works perfectly, even
after I activated the restricted NVidia driver.


On 5/20/08, kklaine <email address hidden> wrote:
> This is still an issue with Hardy Heron apparently.
> I'm using:
> nVidia Corporation NV15DDR [GeForce2 Ti] (10de:0151)
> And using Marcel's instruction's from post #6 enabled my max resolution.
> --
> [nvidia-glx] Resolutions lost on upgrade from Edgy to Feisty
> [nvidia-glx-legacy][nvidia-glx-new]
> https://bugs.launchpad.net/bugs/91292
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

There is still an issue in getting full resolution with nvidia-glx in Ubuntu 8.04 "Hardy Heron":

I found the following minimum entries (highlighted as most indented) need to be added to /etc/X11/xorg.conf as attached to be able to use 1920*1200 (WUXGA):

Section "Device"
        Driver "nvidia"
                Option "ModeValidation" "NoMaxPClkCheck"
                Option "UseEdidFreqs" "on"

Section "Monitor"
        Identifier "Configured Monitor"
        Modeline "1920x1200_60.00" 154.0 1920 1968 2000 2080 1200 1203 1209 1235 +Hsync -Vsync
                Option "DPMS"

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/111894 and https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/94671 seem related as regards the resolution, but given the number of bugs reported regarding nvidia-glx, I am not sure which are the "primary" ones being worked on.

The DPMS entry does not seem to be present by default, preventing the monitor from ever going into power-saving mode, hence I also list it among the required additions, while not knowing exactly where to report its absence as a separate issue.

Sitsofe Wheeler (sitsofe) wrote :

(linking to posted bugs in a more convenient format)
Bug #3731, Bug #94671, Bug #97069, Bug #111894 .

This package has become obsolete so we're closing out the bug report as WONTFIX.
Thanks for reporting it though!

Changed in linux-restricted-modules-2.6.20:
status: Confirmed → Won't Fix
Mesbah Uddin (mesbah-04) wrote :

I'm having problems with the configuration of my resolution. Graphic card GeForce FX 52000 and SyncMaster 551s monitor. Plz help me

Sitsofe Wheeler (sitsofe) wrote :

Your comment is asking for the wrong type of help in the wrong place unfortunately.
a) There is not enough information in your message to begin to help you.
b) You are asking for support in a _bug report_.
c) You are asking for support in an _expired_ (read that as closed) bug report.

Your query is a support question so you need to ask in it the appropriate place - a bug tracker is NOT an appropriate place (so don't follow up here!). I recommend asking that question over on https://answers.launchpad.net/ , on the mailing lists/forums or in IRC (there is a list of places to get support on http://www.ubuntu.com/support/CommunitySupport ). There are no guarantees but you are far more likely to succeed in getting support from those other places than here. I hope this helps...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers